- Rich Hickey: Simple Made Easy
This is a feature not a bug! And it's INTENTIONAL for both Unix and HTTP.
The Uniform Interface Constraint, the Perlis-Thompson Principle, and LAYERING structure on top of "flat / featureless" mechanisms.
---
It's also the reason for their success!
I'll refer to my recent comment on this - https://news.ycombinator.com/item?id=39925798
> So the reason that shell/Unix and HTTP are so common is a MATHEMATICAL property of software growth.
> How do you make a Zig program talk to a Mojo program? Probably with a byte stream.
> What about a Clojure program and a Common Lisp program? Probably a byte stream. (Ironically, S-expressions have no commonly used "exterior" interchange format)
and the follow-up with EDN - https://news.ycombinator.com/item?id=39931919
Do Common Lisp users have EDN libraries? Do Clojure users parse Common Lisp s-expressions?
---
Also, Oils adds parsers to Unix shell like JSON, so you don't have to write your own!
Shell was not a powerful enough language to be a real shell :) To interoperate between heterogeneous and diverse runtimes, to glue things together when their creators wanted monoliths (e.g. like Go and the JVM have problems interoperating with C)
---
I'm a big fan of Hickey, and have watched almost all his talks. I often refer to his explanations of programming with maps, which explains why protobufs work - https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey
(something many protobuf users apparently don't understand)
I do recall this comment, but I don't recall him saying much else about Unix.
I think if you can live within the JVM, OK you can do everything in Clojure and avoid parsing. And even Datomic takes it to the next level -- he really walked the walk.
---
But I'd claim you can't build Google or LLMs on Clojure and Datomic. The bigger the software system, the more heterogeneous it is.
Bigger codebases are written in more languages. And they have more formats on the wire.
I even see startups of like 10 people using Rust AND Go now (and JavaScript), which is a little odd to me. I'm all about language diversity, but even I see the value of using ONE language for smaller or more homogeneous problems.
But even tiny software projects now use many different languages.
See the previous post The Internet Was Designed With a Narrow Waist, especially the appendix with some history
https://www.oilshell.org/blog/2022/02/diagrams.html
The name was apparently coined by Jon Postel in the late 1970's, but this fact is not well known. There are some misattributions in the appendix
I apparently learned the term from a talk by Van Jacobsen on Named Data Networking at Google in 2006, but I forgot that I learned it that way!
After I wrote the post, a reader Caleb Malchik reminded me about Van Jacobsen's talk, and then I went back and watched it, and realized that's where I got the term from! I then updated the appendix.
---
I have searched Hacker News for "narrow waist", and it surprised me that it's not a very well known idea, despite being old and important. (And again - I wrote these articles specifically to gather related material from others, so I welcome any updates or corrections.)
One place you can see it in passing is in a 2013 paper from Steven Kell - The operating system: should there be one?
https://www.humprog.org/~stephen/research/papers/kell13opera...
Search for "waist in the hourglass"
---
If you think about it, it is not surprising that the "narrow waist" concept from networking is becoming more important to software. Software has become more and more networked for the last 2 decades, and I don't think that trend has even topped out.
It is hard to find any kind of software that is not networked. As an example, in 2002 I worked at EA on shrink wrapped video games. They were completely offline embedded systems. But 2004 was the first year we added networking to the game, and now pretty much all games are networked in some way.
Also, the Internet is the probably the biggest and most successful thing ever engineered ... (not sure what you would compare it to, maybe nuclear reactors or aircraft carriers).
It would be surprising if there weren't some lessons to learn from its engineering!