That's Martin Fowler's job :)

Oh, yeah, more names for the same old thing in order to fragment the ecosystem and write more books that could be a mechanical translation of old books (search and replace old-word -> new-word).

That's definitely what the world needs.

I first heard about this concept in the early 1990s from netpbm (then called pbmtools). The exact language seems to have been removed from the current manual[1] but the basic idea was that if you have N image formats, you can either write NxN tools to convert between them, or you can have a few common image formats (ie. pbm - bitmap, pgm - greyscale and ppm - fullcolour) and then write 2xN tools to convert between the universe of all image formats and the common formats. You then use Unix pipes to connect the tools together.

[1] https://netpbm.sourceforge.net/doc/

Except in that case you're converting to and from an uncompressed buffer... that could be in ram and not use a file format at all?

It's much more useful to have a real file format.

For example, you can generate images from your own code by doing this (with a bit more shell quoting and error checking in the real code):

  fp = popen ("ppmtojpeg > output.jpg", "w");
  fprintf (fp, "P3 1024 1024 255\n");
  for (y = 0; y < 1024; ++y)
    for (x = 0; x < 1024; ++x)
      fprintf (fp, "%d %d %d\n", 255*r[y][x], 255*g[y][x], 255*b[y][x]);
  fclose (fp);

This is the first time I have seen anyone popen’ing a pipeline like that, and writing to its stdin.

Bravo.

I miss a bit some of the old `xxx2yyy` programs. It's tempting to consider:

     FILE.csv.html.pdf.zip

...`csv2html | html2pdf | pdf2zip`, and vice-versa... how possible is it to make the pipeline reversible, eg: `zip2pdf | pdf2html | html2csv`, or in the absence of "reversibility", could you simply shortcut and get straight back to the original `*.csv`?

Other names for the same idea: "modularization", "loose coupling and strong cohesion", "program to interfaces, not implementations", ...

Parsimony

(author here) I will probably write more about this, but it's not just modularity, or interfaces. Or at least those words are clouded by associations with specific mechanisms in whatever programming languages one has used

One additional distinction that's relevant is strong vs. weak modules in the sense here:

https://thunderseethe.dev/posts/whats-in-a-module/#strong-vs...

Some of my comments here - https://lobste.rs/s/eccv1g/what_s_module

and here - https://lobste.rs/s/u7y4lk/modules_matter_most_for_masses

Harper doesn't use the term "strong modularity", but he says that REAL modularity is M x N, and that's closer to what I'm getting at:

https://existentialtype.wordpress.com/2011/04/16/modules-mat...

To be most useful, it is important that the relationship between M and A be many-to-many, and not many-to-one or one-to-one.

(Although I disagree with the assertions about static types -- I think he is making a very domain specific argument, nonetheless we agree on strong modularity)

It needs more analysis, but I'd claim there are at least two kinds of modularity and programming to interfaces, but the difference is not clear to most people

The interior vs. exterior distinction is a big one -- is the interface "owned by" one party, or does it stand alone?

Are you able to do "interior" refactorings that change the interface, or is it fixed, outside the project? This is a big difference in practice

parsimonius interfaces must have been taken

(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.