Vladimir Gordeev @vladimir_vg@qoto.org

There is an animal inside each of us. You can allow it to take over, you can fight it.

I was playing with this metaphor for a while and decided to write down a short article on it: https://telegra.ph/Animal-inside-04-11

It always felt wrong to start a programming language design already having a type system in mind. I couldn't put my finger on it before, but now I think I understand why.

There is well known tradeoff between exploration and exploitation when it comes to solution search.

During *exploration* you try to open undiscovered areas. Something that might not be very viable at the beginning but in the long run could lead to outstanding results. During *exploitation* you try to find best solutions in selected area, relying on already accumulated assets.

Eventually exploration and exploitation would be in conflict, since resources are limited. You can resolve this conflict differently depending on the task you're trying to accomplish.

If you want to design a PL that is more convenient for humans, starting with a type system in mind would pull you away from exploration too early. There might be a brilliant solution that is incompatible with that type system.

You can always think how to limit flexibility and reduce space for errors later.

When I was about 17 to 20 years old I rejected everything external. I believed that value was within. I thought that your appearance doesn't matter as long as there's something valuable inside.

I would walk with long and greasy hair, wear dirty shit-kicking boots and ripped jeans. Ripped not due to sense of style, but due to rusty nail I caught somewhere.

Changing yourself to please someone outside -- isn't it a self betrayal? I am who I am right now, take it or leave it. That's what I thought back then.

Artificially making yourself look better is a reality distortion, sounds like something not that far from lying. If people can't recognize something valuable inside me with this appearance, then they shouldn't see anything valuable in more pleasantly looking version of me.

I had quite a radical monk-like attitude back then. Years have passed and my position changed.

These days I am trying to dress well, keep my body attractive, and see nothing wrong in it.

I still believe that value within dominates the appearance. I still don't give much credit to external things. I just realized that appearance is a form of communication.

I've learned that it is very hard to see value inside other person. Pretty much all the time we only see a heavily distorted version of that person. When one tries to look better he replaces one distorted image with another, that tells who he is inside more efficiently.

Striving to pleasant appearance is akin to selecting most understandable words in dialogue. You modify your initial thought to make communication more efficient.

It seems like it is okay to distort reality in eyes of others, as long as you do it honestly, without pretending to be someone you are not.

As long as you're staying yourself.

Copy of my twitter post of May 30, 2020:

Programming languages are secondary.

From Jef Raskin I learned that most of the time people rely on habits, basically work on autopilot. The key to human productivity is to make possible to form habits and capitalize on them.

Humans don't merely write code in a PL. We work with a system: text editor, terminal, test reports, running app, logs viewer, doc viewer. We develop habits, train our fingers and eyes to navigate between these tools. This composition becomes ONE thing is our mental map.

Paths between these tools do not allow to develop habits and work on autopilot. Finding correct version of doc for a particular function in the lib takes conscious effort every time. Reconstruction of possible execution path from log entries is also done manually, consciously.

Finally, there is no universal "undo" for many actions that happen in-between of these tools. It forces human to be aware of possible risks of these actions, make conscious decisions most of the time. This is fact denies capitalization on habit.

It seems that integrated development environments are really not that integrated.

I think we should design most efficient/convenient programming environment first, and only having done that think about adopting/creating a programming language that would fit into it. Programming environment is primary, programming languages are secondary.

Copy of my twitter post of May 30, 2019:

God is an abstraction. Pretty much like quaternions, lambda-expressions or ideal sphere.

Ideal sphere does not exist, yet this abstraction is accurate enough to be useful in daily life. Similar things with God abstraction.

There are certain patterns that people observed for a long time: helping others usually pays back in future, being unfaithful to partners usually ends badly. People discovered many little patterns, that are grounded in structure of society, biology, nature.

People also noticed that environment often punishes them without any reason. No righteous man is safe from volcano eruption or plague. Perfect morals are not enough in unpredictable world.

These observations gradually formed an abstraction -- a heavenly father. He is capricious and may punish you with no reason. He sets an example of proper behavior, divergence from which will lead to problems in long term.

Does his heavenly father exist? Answer to this question won't change much.

What's important is that this abstraction is sufficient enough to describe complexities of the world. This abstraction is a useful tool that help to make decisions in daily life.

Just like idea of sphere.

Copy of my twitter post of Aug 31, 2018:

A bit about programming languages.

It feels like there are two distinct programming languages that PL designers habitually mix into one.

1) Calculating language. It's code lives inside box with explicitly specified inputs and outputs. There is no IO, nor time inside the box. Program might be executed lazily or eagerly. Instructions might be executed sequentially, or may remind some kind of graph, in which exact path of execution is not clear. The main thing is that there are inputs and expected outputs. Reminds code in Prolog or Haskell.

2) Managing language. It's code runs inside loop-ring, instructions always executed eagerly and sequentially. Unlike boxes, there is a time inside ring, and it flows into one direction. Programs written in this language do all IO: receive data, process it using boxes from the first language, save state, send data outside. This language also describes components of the system and their dependencies.

Reminds Erlang with it's receive-after-end and send. Reminds supervisor config, kubernetes service config.

If we split these languages yet use them together, it may lead to something interesting. It may produce more powerful abstractions specific for tasks of each language. It may lead to something more convenient, more effective in terms of computer-human interface.

Just realized that Realtalk in DynamicLand does exactly that. It has Managing Language with its Claim, When and Wish IO instructions. It has Lua as a Calculating Language, which code can be treated as a pure function by Managing Language.