evnu

For me, if it's worth thinking about it, it's worth writing it down. Doesn't matter if it's a todo list I just came up with, a system diagram, whatever I am currently working on, or thoughts on a human interaction I just witnessed. The act of writing it down guides me in my thinking.

"perhaps even why it was necessary at all" not being asked anymore is what I fear as well. Stumbling over problems repeatedly gets attention to architectural defects. Papering over the faults with a non-complaining AI buries the defects even deeper, as the pain of the defects isn't felt anymore.

Uiua is the first one that made array languages "click" for me due to the formatter.

Sometimes it works to find a solution which makes the life of teams easier and comes with an additional gain in security. That can potentially be sold more easily to the team then, as you are solving a problem the team actually experiences.

I wondered about that as well while looking into the http handler. I think a missing space between method and path overruns the buffer (haven't tried running it though).

Maybe because aging is non-linear.

Some years ago, I started to use FIXME to indicate that something is blocking the PR and needs to be done before merging, and TODO if something can be done at a later point in time. Then, CI only needs to grep for FIXME to block merging the PR, which works for practically any language. Works pretty well for me, maybe that tip can help others as well.

> Instead you should use high quality sources, then ask the LLM to summarize them for you to start with (NotebookLM does this very well for instance, but so can others).

How do you determine if the LLM accurately reflects what the high-quality source contains, if you haven't read the source? When learning from humans, we put trust on them to teach us based on a web-of-trust. How do you determine the level of trust with an LLM?

We found Erlang to be the right choice at small scale. Namely, we used it in iot applications, where the self-healing property of proper supervision trees resulted in a very stable implementation. We also saw the same benefits in the cloud part of our application. No complicated k8s setup, just simple supervisor trees.

> I think it will spawn a lot more code that was as bad as it was before.

And that makes it even harder for seniors to teach: it was always hard to figure out where someone has misconceptions, but now you need to work through more code. You don't even know if the misconceptions are just the AI misbehaving, the junior doing junior things, or if the junior should read up on certain design principles that may not be known to the junior yet. So, you end up with another blackbox component that you need to debug :)

More frequent attention is a solved problem: a server walks around with a tray of filled glasses and always replaces empty glasses, except if they are covered. That way, the communication overhead is reduced, and a roundtrip per table back to the bar is no longer required. With that, the number of servers can also be kept to an efficient minimum.

Obviously, this works only if a very small selection of beverages are served.

As usual, there are exceptions as well. For example some streets in Berlin use a "horseshoe" numbering system. I tend to look for the house numbers of opposing houses when I enter a street I don't know to check if it is horseshoe or even-odd numbering.

> For example: I wonder if it wouldn't be more "erlangy"/"elixiry" to model the mutable ops behind a genserver that you send messages to.

It depends on the use case. For example, when creating a resource (basically a refcounted datastructure), it might make sense to allow mutable access only through a process as the "owner" of the resource. But if you have only read-only data behind that resource, sharing the resource similar to ETS might be what you want.