I have ~100 repos on github and only a few of them with LLM assistance. Aside from a few comments and a PR here and there throughout the years nobody cares about them. I have to assume it's the same for the majority of developers.
There's a reason we have expressions like "train of thought". Going from one idea to another is pretty much how we think. Much like going from one token to another.
1. "Eureka moments" often pop up almost out of nowhere, this suggests that there's processing going on at a non-verbal, non-token level.
2. The fact that we think in language is an evolutionarily new phenomenon. Plenty of "smart" animals are capable of complex behaviors and learning without any kind of language "tokens". There's no reason to think that human reasoning is different and somehow confined to "tokens" instead of being a broader system. Consider language itself. The human species created it somehow out of nothing. We "tokenized" our cognition to be able to communicate. But I would argue this was driven by our social needs, not our cognitive needs and the human ability to think does not require tokens at all.
Edit:
Finally, consider how limited language really is. Even for something simple, like pain, we don't even have a way to communicate objective reality to another person. We can say "it hurts" and use metaphors: "stabbing pain", "dull pain", etc. But the experience of pain can't really be communicated to another person. It's even worse once you remove non-verbal cues like facial expressions and body language - pain just becomes a vague concept on the page.
Meanwhile, our brain is perfectly capable of perceiving the slightest changes in pain and altering our behavior accordingly. Now extend this to other human experience.
I think the best analogy here is that treating human cognition as a problem of processing "tokens" is confusing the map for the territory.
According to some benchmarks has the coding capability of Opus at the price of Sonnet, supposedly will be open weights and is not subject to random trade wars with allied states.
As someone with very little knowledge of economics, I played with the idea of writing a kind of wealth simulator, where money acts as voltage and keeps the economy running. It would allow you to eliminate jobs and replace them with AI and see how the circuit starves population groups which in turn cascade to other segments of the economy.
I never got to design a good representation of the entire ecosystem to simulate (external pressure, debt, military and technological advancements, international soft power, etc.).
Money as voltage is an interesting idea. I've determined that "wealth" is really just low entropy (both in terms of energy and information), and economics is really just thermodynamics underneath it all.
"Technological advancement" could just be a decrease in the amount of thermodynamic waste created by an economy (or a particular company) as it converts oil/uranium and calories into useful work.
There's another layer of thermodynamics where wealth acts like heat. Moving jobs from a rich (hot) country to a poor (cold) one is like attaching a thermal conductor. Eventually, the two countries reach equal temperature and it's no longer possible to extract useful work (profit) from the heat transfer. AI is probably like an infinitely cold heat sink that can absorb all the heat you pour into it until your heat source reaches absolute zero.
> Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust.
Yeah, but that makes sense: if you want "hidden everything", which they appear to want due to now having a code base that has never been read by a human, then a subset of "want everything hidden" is "want control flow hidden".
Honestly I am pretty sure AI would be better at zig than rust since zig has no hidden control flow which means that AI has the full context of any given function without having to find traits. The rewrite to rust from bun is as much of as PR stunt as fustration with DX of zig.
Every time I want to interact with zig code I just have the AI do it since I honestly can't be asked to change 3 lines and around 3 to 5 characters when it's a single keybind in every other language which in turn has lead me to experiment quite a lot 'writing' in zig. It's rather pleasant to look at, however, I wouldn't want to write code myself.
Rust is by far the most enjoyable dx experience since everything usually 'just works' across machines and even architectures while having a strong sense of assurance that compiled applications will work as expected before ever running them once. node/bun/whatever is probably the worst here since compilation means nothing for runtime as undefined symbols will happily 'compile' (transpile?).
> Honestly I am pretty sure AI would be better at zig than rust since zig has no hidden control flow which means that AI has the full context of any given function without having to find traits.
You say that as if having to find traits was a problem ... for a bot.
Traits are harder to find since multiple traits can apply, but the one strictest one wins. They also have to be followed from generic types which adds a whole other layer of complexity, without an LSP it's a lost cause.
1 read vs realizing that lsp exists and using it correctly, even if ai is smart that's more token burn and it is slower making zig 'better'.
It also has to realize that "Drop" exists and know what it does since there's nothing in code that clearly says "this object is automatically dropped by the compiler on scope end.
That tells you more about the people writing Bun than it does Zig or what's "needed" for people actually writing and reading code. Bun dev is not just hiding the control flow, their goal is to hide all of the code so that no human reads it, ever.
Obviously most GUIs are not nearly that complex so immediate mode can get you quite far. Its biggest limitation is that it makes it hard to do some layouts. Your GUI layout becomes dictated by your data dependencies which is quite awkward.
Absolutely zero difficulty redoing this in a react style renderer. The only complexity is being careful with your data dependencies so as to not needlessly rerender.
Each pane is easily isolated, can share data with a view model scoped properly, etc. Writing it in an imperative toolkit is a "oops I forgot to update my data here" kind of hell. Data binding makes it slightly less worse
> Absolutely zero difficulty redoing this in a react style renderer
I would not classify a react style renderer as "immediate mode". It has aesthetic similarities with IM GUIs, but ultimately there is a fully retained tree under the hood, that gets diffed/mutated on every update
