I think there is an argument there, but the lines aren’t clear, and it’s mixed in with a whole lot of other things
removing the ability to write empty strings – I dunno it seems like a big stretch to relate this to Plan 9 / Smalltalk
OpenSSL – “I would rather use a library where only correct things are possible”. I would say this is because OpenSSL has a lot of features, not necessarily because the interface is too general. I think the interface is more or less encrypting a stream.
Remote vs. local I/O is different – I agree with this. It could be a flaw of Plan 9, but I would like to see it fleshed out more
And I explicitly point out that narrow waists are NOT optimal; they are compromises. And I even show some bugs
It’s a big tradeoff. The downside of specialized interfaces is that you end up writing quadratic amounts of glue code – that’s what most programming jobs are IME.
So I would like to see the tradeoffs more explicit – the conclusion is a little weak. So it’s not surprising that we end up with specialized rather than uniform interfaces, and it’s not bad either.
One counterexample I have in my blog drafts is Scheme/Racket vs. Clojure/Python. In Scheme (and pretty sure Racket) everything is a list basically. You get a lot of power for that uniformity, treating code as data, etc.
But I think it’s too weak, and language design has moved on – Clojure specifically added maps and vectors, and Python is “an acceptable Lisp” (very dynamic and garbage collected)
However the tradeoff of having maps and vectors, dicts and lists, is that then you also need “bridges” for them to compose. In Python/Clojure this is the iterator protocol – the for loop doesn’t need to know precisely what it’s iterating over. Or the map/filter, etc.
I also recall the Racket authors said that one mistake is being based on concrete data structures, rather than abstract protocols like Python/Clojure
Another big example is “should everything be an HTTP resource identified by URL?” To a first approximation the whole world is wired together that way – e.g. Google Maps API, Stripe/Paypal payments, Github, etc.
Anyone who has worked with such APIs will notice how suboptimal they are, and all the compromises. But you also get a lot of reuse and composition, across multiple languages, across multiple domains, and scales
But then you also have web sockets, which kind of break the uniform model. Arguably you need that for certain apps. It breaks some important properties of the web, but it’s also useful
Hm I’d like to see this fleshed out a little more
I think there is an argument there, but the lines aren’t clear, and it’s mixed in with a whole lot of other things
The way I think of the Plan 9 uniformity is a narrow waist which enables interoperability and composition (NOT really abstraction) – https://www.oilshell.org/blog/2022/03/backlog-arch.html
And I explicitly point out that narrow waists are NOT optimal; they are compromises. And I even show some bugs
It’s a big tradeoff. The downside of specialized interfaces is that you end up writing quadratic amounts of glue code – that’s what most programming jobs are IME.
So I would like to see the tradeoffs more explicit – the conclusion is a little weak. So it’s not surprising that we end up with specialized rather than uniform interfaces, and it’s not bad either.
One counterexample I have in my blog drafts is Scheme/Racket vs. Clojure/Python. In Scheme (and pretty sure Racket) everything is a list basically. You get a lot of power for that uniformity, treating code as data, etc.
But I think it’s too weak, and language design has moved on – Clojure specifically added maps and vectors, and Python is “an acceptable Lisp” (very dynamic and garbage collected)
However the tradeoff of having maps and vectors, dicts and lists, is that then you also need “bridges” for them to compose. In Python/Clojure this is the iterator protocol – the for loop doesn’t need to know precisely what it’s iterating over. Or the map/filter, etc.
I also recall the Racket authors said that one mistake is being based on concrete data structures, rather than abstract protocols like Python/Clojure
Another big example is “should everything be an HTTP resource identified by URL?” To a first approximation the whole world is wired together that way – e.g. Google Maps API, Stripe/Paypal payments, Github, etc.
Anyone who has worked with such APIs will notice how suboptimal they are, and all the compromises. But you also get a lot of reuse and composition, across multiple languages, across multiple domains, and scales
But then you also have web sockets, which kind of break the uniform model. Arguably you need that for certain apps. It breaks some important properties of the web, but it’s also useful