Comment by chubot | Hacker News Reader

Comment by chubot | Hacker News Reader

Parent Full thread

(author here) It's an old name for an old concept :)

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!

Aircraft carriers and nuclear reactors are exactly not anything like internet. Huge physical engineering projects are like a huge jigsaw puzzle. Take one piece and picture is not complete. Internet is network, most physical thing to compare with is electric grid. But then again whole electric grid hums with one single frequency.

I would compare Internet to the intermodal shipping container system, the international post, and not much else.

> Are we all not glad we don’t use the Unix method of communicating on the web? Right? Any arbitrary command string can be the argument list for your program, and any arbitrary set of characters can come out the other end. Let’s all write parsers.

- Rich Hickey: Simple Made Easy

I do remember this quote, but it's a little odd because Unix and the web have a very similar structure. HTTP has more metadata like Content-Type, but it's still fundamentally uniform bytes/text.

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.

Reply on news.ycombinator.com