As usual, this paean to deductive reasoning (“formal methods”) leaves out its fundamental limit: how closely do the postulates and definitions fit the domain they purport to map? (“In theory, there is no difference between theory and practice. In practice ...”) My guess is that Jane Street maintains large code bodies where the mapping is 1:1, because the purpose of the code is to implement a deterministic algorithm. Many other coders work in such areas. But millions of us don’t: most UIs, most exploratory work, etc.
There is a movement parallel to formal methods to define acceptance criteria at high resolution but not logico-mathematically, which at least grapples with the mapping problem but can’t resolve it where the map isn’t the territory, which is most places. Has Google’s results page, with its extremely evolved internal optimization frameworks really hit an optimum? Could that prototype you whipped up to capture a hazy idea have better illustrated it? These questions are best answered by looking outside the system to what the system serves.
Many HNers will enjoy this book about the company’s maturation from a hardware startup founded by one difficult genius to an institution that had to be rebuilt as it scaled: https://bookpeople.com/book/9781615199563
1. Free Software / Open Source are Good and True by assertion. There is no God but source code, and Stallman is its prophet.
2. Questions whose answers tend to contradict point 1., such as “Gee, the world runs on Python — as wonderful as job as Guido and his inner circle have done, is it time to ask what an ideal management structure for a technology worth (tens? hundreds? of) billions of dollars might be?” are not welcome — are largely not asked.
Fantastic piece: shows how fundamental dynamics (queuing) generate practical problems AND what to do about them. This essay is better than 95% of tech blog posts I read via HN. Kudos!
An original sin of Free Software which carried through to Open Source and infects HN via its many Open Source believers is a reluctance to take project management seriously. OP shows that Jellyfin’s dictat... er, maintainer is not effectively managing the project. Open Source has no adequate answers (“fork” is not adequate).
“... when I was 7. I'm 50 now and the thing I loved has changed”
Welcome to the human condition, my friend. The good news is that a plurality of novels, TV shows, country songs, etc. can provide empathy for and insight into your experience.
“Finally, Bucciarelli is right that systems like telephony are so inherently complex, have been built on top of so many different layers in so many different places, that no one person can ever actually understand how the whole thing works. This is the fundamental nature of complex technologies: our knowledge of these systems will always be partial, at best. Yes, AI will make this situation worse. But it’s a situation that we’ve been in for a long time.”
This perspective dates to at least 1940, when the population was a fraction of the current size. The fantastic Charles C. Mann wrote an excellent book, The Wizard and the Prophet, about it.
Regarding water specifically, we now have multiple desalination projects of 1MM m^3/day, enough to support a city of 4MM people. They are expensive, but getting cheaper, and real (rich) polities in the Middle East are relying on them.
I can't stop thinking about this. WRT Perl specifically, it’s fascinating how the two competitors adopted Unix shell patterns. Python is handicapped to this day by not automagically snarfing up environment variables, etc. But Perl leaned hard into TECO-style gibberish and the meta-syntax that is regular expressions, confronting beginners with arbitrary complexity. It feels like Wall embraced the system administrator side of coding — the side that has an enormous capacity for tracking corner cases and managing impedance mismatches. Wall was trained, perhaps not coincidentally, as a linguist, a field where continent facts really matter. Guido, on the other hand, was an accomplished mathematician. (This is the Dwarf / Elf distinction from Cryptonomicon.)
9. Python got lucky that its inevitable screwups (Python3) didn’t quite kill it.
10. Swift and Kotlin both define programming as serving the compiler (specifically LLVM) rather than serving the coder’s problem. (I haven’t discussed Rust so far since it isn’t attempting to compete with 98% of Python use cases, but if you squint you can see it as going one step further than Swift and Kotlin and in effect forcing the coder to be a sort of human compiler who thinks in types and memory management. This is not a criticism of Rust, BTW.)
0. And behind all of this is Moore’s Law and the demographic explosion of programmers. Python was an implicit, perhaps unconscious bet that if you served people thoughtfully, the tradeoffs with serving the needs of contemporary silicon wouldn’t matter as much.
1. Python was designed by testing syntax with novice users to see what they could adopt easily.[1] > 90% of current Python users weren’t born when it was created. They all had to learn, and Python is the easiest language to learn because Guido and his teammates, unlike $LANGUAGE_DESIGN_GOD, approach the problem as experimental scientists rather than auteurs.
2. Python is conceptually compact, dominated by hash tables with string keys. The initial leader in the ecosystem, Perl, is conceptually sprawling and difficult to reason about.
3. Python also took lessons from the Unix shell, a mature environment for accommodating beginners and experts.
4. Python had a formal process for integrating C modules from early on.
5. Python’s management has an elegant shearing layer structure, where ideas can diffuse in from anywhere.
6. $NEXT_GENERAL_PURPOSE_LANG (Ruby, Go) weren’t enough better to displace Python. Both were heavily influenced by Python’s syntax, but ignored the community-centric design process that had created that syntax in favor of We Know Best.
7. Speaking of open source entrepreneurialism, JavaScript has become a real rival thanks to the Web (and node), but it is handicapped by the inverse failure mode: where Go is dominated by a handful of Googlers, JavaScript was effectively unmanaged at the STDLIB level for a crucial decade, and now it can’t recover. (I’d also guess that having to write a module system that works well in the chaos that is Web clients and simultaneously the Unix world is a daunting design problem.)
The Big Question:
How did Earth become a planet with oceans and life, when it formed so close to the hot Sun?
What Scientists Did:
- They used a "radioactive clock" made from two elements: manganese and chromium
- Manganese-53 breaks down into chromium-53 over time (like ice melting at a steady rate)
- By measuring these elements in meteorites and Earth rocks, they figured out WHEN Earth's basic chemistry was locked in
Key Finding:
Earth's chemical recipe was set within just 3 million years after the Solar System formed (that's super fast in space terms!)
The Problem:
At that point, early Earth was missing the ingredients for life—especially water, carbon, and other "volatile elements" (stuff that evaporates easily when hot)
Why Earth Was Dry:
Close to the Sun, it was too hot for water and other volatile stuff to stick to the rocks that built Earth—they stayed as gas and floated away
The Solution:
About 70 million years later, another planet called Theia (which formed farther from the Sun where it was cooler) crashed into Earth:
This collision created our Moon
It also delivered water and other life-essential ingredients to Earth
The Big Takeaway:
Earth needed a cosmic accident to become livable. Without that lucky collision bringing water from the outer Solar System, we wouldn't be here!
Why This Matters:
If Earth needed such specific, lucky events to support life, habitable planets like ours might be much rarer in the universe than we thought.
Look at your examples. Translation is a closed domain; the LLM is loaded with all the data and can traverse it. Book and music album covers _don't matter_ and have always been arbitrary reworkings of previous ideas. (Not sure what “ebook reading” means in this context.) Math, where LLMs also excel, is a domain full of internal mappings.
I found your post “Coding with LLMs in the summer of 2025 (an update)” very insightful. LLMs are memory extensions and cognitive aides which provide several valuable primitives: finding connections adjacent to your understanding, filling in boilerplate, and offloading your mental mapping needs. But there remains a chasm between those abilities and much work.
So many articles should prepend “My experience with ...” to their title. Here is OP's first sentence: “I spent the past ~4 weeks trying out all the new and fancy AI tools for software development.” Dude, you have had some experiences and they are worth writing up and sharing. But your experiences are not a stand-in for "the current state." This point applies to a significant fraction of HN articles, to the point that I wish the headlines were flagged “blog”.
Some headlines, such as this one, are catnip to up-voters* despite the article's contributing nothing to the established discussion c. 2015, let alone 2025. I don't know how you disrupt this dynamic and redirect to "go read X", where X is _Team Topologies_ or whatever, but it would improve HN.
* (not a criticism; the topic is important to hackers)
There is a movement parallel to formal methods to define acceptance criteria at high resolution but not logico-mathematically, which at least grapples with the mapping problem but can’t resolve it where the map isn’t the territory, which is most places. Has Google’s results page, with its extremely evolved internal optimization frameworks really hit an optimum? Could that prototype you whipped up to capture a hazy idea have better illustrated it? These questions are best answered by looking outside the system to what the system serves.