Even though there were some benefits to the modularity of Multics (apparently you could unload and replace hardware in Multics servers without reboot, which was unheard of at the time), it was also its downfall. Multics was eventually deemed over-engineered and too difficult to work with. It couldn't evolve fast enough with the changing technological landscape. Bell Labs' conclusion after the project was shelved was that OSs were too costly and too difficult to design. They told engineers that no one should work on OSs.
Ken Thompson wanted a modern OS so he disregarded these instructions. He used some of the expertise he gained while working on Multics and wrote Unix for himself (in three weeks, in assembly). People started looking over Thompson's shoulder being like "Hey what OS are you using there, can I get a copy?" and the rest is history.
Brian Kernighan described Unix as "one of" whatever Multics was "multiple of". Linux eventually adopted a similar architecture.
If you click on the link, I mention other competing attempts and architectures, like Multics, Hurd, MacOS and even early Windows that either failed or started adopting Unix patterns.
So which base style and tone simply gives you less sycophancy? It's not clear from their names and description. I'm looking for the "Truthful" personality.
Yeah, the example with the eggs isn't great because an LLM would indeed get the correct interpretation but the thing is, this is based on LLMs having been trained on the context.
When and LLM has the context, it is usually able to correctly fill the gaps of vague English specifications.
But if you are operating at the bleeding edge of innovation or in depths of industry expertise that LLMs didn't train on, it won't be in a position to fill those blanks correctly.
And domains with less training data openly available are areas where innovation and differentiation and business moats live.
Oftentimes, only programming languages are precise enough to specify this type of knowledge.
A CLI might be the most information theoretically efficient form of API, significantly more succinct than eg. JSON based APIs. It's fitting that it would be optimal for Claude Code given the origin of the name "Claude".
To add to this, there are fundamental information-theoretic principles that support inlining code and components. It's about reducing code entropy, reducing length and referential distances. https://benoitessiambre.com/entropy.html
The good thing is LLMs try to optimize for information theoretic measures of language so they naturally generate better scoped more inline code. LLMs might help us win this battle :-)
To add to this. There's fundamental theoretical reasons why microservices or bad. They increase the entropy of code (https://benoitessiambre.com/entropy.html) by increasing globally scoped dependencies. They are the global variables or architecture. Having lots of interconnected global variables makes for an unpredictable chaotic system.
Asynchronous queues make your data out of sync (hence the name) and inconsistent one of the main downsides of microservices. Their use should be minimized to cases where they are really necessary. A functional transactional layer like postgres is the solution to make your state of truth accessed in a synchronized, atomic, consistent way.
Functions and handlers should not care where data comes from, just that they have data, and a queue is the abstraction of that very idea. Yes, you lose atomicity but atomicity is generally slow and more problematic has a high amount of coupling.
I don’t agree that being out of sync is the main downside of microservices; the main downside is that anything hitting the network is terrible. Latency is high, computers crash, you have to pay a cost of serialization and deserialization, libraries can be inconsistent, and zombie processes that screw up queues. Having stuff in-process being non-synchronized wouldn’t even hit my top five.
ETA:
I should be clear; obviously there are times where you want or need synchronization, and in those cases you should use some kind of synchronization mechanism, like a mutex (or mutex-backed store e.g. ConcurrentHashMap) for in-process stuff or a SQL DB for distributed stuff, but I fundamentally disagree with the idea that this should be the default, and if you design your application around the idea of data flow, then explicit synchronization is the exception.
I'll agree that the network layer adds more problems to microservices, but even with a perfect network, they are problematic. Everything being out of sync, (if they are stateful microservices which queues imply), is one big issue. Things being interconnected in broad global scopes instead of more locally scoped is the other big issue.
The more you have globally interconnected and out of sync states, the less predictable your system is.
The solution is to be as hierarchical, as tightly scoped, as functional and as transactional as you can.
Exactly. I think of them as Markov Chains in grammar space or in Abstract Syntax Tree space instead of n-gram chain-of-words space. The attention mechanism likely plays a role in identifying the parent in the grammar tree or identifying other types of back references like pronouns or if it's for programming languages, variable back references.
There was a time when people would estimate n-gram probabilities with feed-forward neural networks [1,2]. We just improved that with the (multilayer) attention mechanism which allows for better factoring over individual tokens. It also allowed for much larger n.
Unix was an effort to take Multics, an operating system that had gotten too modular, and integrate the good parts into a more unified whole (book recommendation: https://www.amazon.com/UNIX-History-Memoir-Brian-Kernighan/d...).
Even though there were some benefits to the modularity of Multics (apparently you could unload and replace hardware in Multics servers without reboot, which was unheard of at the time), it was also its downfall. Multics was eventually deemed over-engineered and too difficult to work with. It couldn't evolve fast enough with the changing technological landscape. Bell Labs' conclusion after the project was shelved was that OSs were too costly and too difficult to design. They told engineers that no one should work on OSs.
Ken Thompson wanted a modern OS so he disregarded these instructions. He used some of the expertise he gained while working on Multics and wrote Unix for himself (in three weeks, in assembly). People started looking over Thompson's shoulder being like "Hey what OS are you using there, can I get a copy?" and the rest is history.
Brian Kernighan described Unix as "one of" whatever Multics was "multiple of". Linux eventually adopted a similar architecture.
More here: https://benoitessiambre.com/integration.html
reply