Bicycles for the mind have to be see-through [pdf]

The original idea of encapsulation was not to rely on arbitrary internal knowledge but provide stable procedures. One of real-world examples was not to rely on Dorothy in marketing putting the red copy into the blue folder because next month Dorothy may be on vacation, red copies become yellow, and the blue folder is replaced with a green one. Instead the procedure should refer to Senior Marketing assistant, marketing copy, and folder for the current year. No excessive hiding, just stability.

I think it's more like confusing people who just want to cook by expecting them to learn hob design and maintenance. The Jobs "bicycle for the mind" line was about the user experience, not the developer experience.

So the fallacy in the argument is that implementation details are relevant to everyone.

They aren't. They're relevant to system builders and people who like tinkering because that is a separate domain to the user domain.

Most users just want an appliance, because a good appliance - like Hypercard, Excel, and maybe VBA - allows them to concentrate on the things that interest them, not on the things that interested the appliance designer when they were building their product.

This is fine for products in the the app store - it's a mark of good design that it reveals exactly as much complexity as it needs to, but no more - but it breaks down when the user domain and the tinkerer domain overlap, as they do in professional software development.

The reason it breaks down is because there is no general solution. No library is ever going to be a perfect snap-in tool that solves your problem for you, no language is going to hide OS-level and library-level abstractions with perfect elegance, and no OS is ever going to have perfectly elegant abstractions for file and network operations, simultaneous and synchronous operations, and so on.

Everyone has opinions about how software should be designed, the problems are essentially open-ended, tinkerers have a tendency to turn everything into an excuse for tinkering instead of a streamlined product/service pipeline, and the result is the mess we have today.

And this is probably how it has to be, given the limitations of human reason.

It is weird, this made me immidiately think about Rust: when they tried to solve a "hard problem" in the language, instead of hiding it away, they make it front and center and try to give you a comfortable way of dealing with it — but you cannot ignore it.

A good example would be that functions of the Std library that deal with the Filesystem often return an OsStr instead of the Str/String Rust uses elsewhere. This means you cannot ignore the fact that the stuff the OS gives you might not be valid UTF-8 bytes. All functions that can be interrupted from the outside or fail, return their values wrapped in a Result Type and make you handle it.

I think this is an example of good encapsulation — when something is a hard problem, it doesn't get easy suddenly, there are just clean ways of dealing with it. I learned a lot just by looking at how they did things and reading their explainations why they did it differently than other languages. In fact Rust teaches me so much about programming that it would've been worth to learn for these lessons alone..

Being curious about internals and giving users the means to understand them doesn't conflict with the goal of a) putting them behind a hiding layer that reduces the aspects a user needs to keep track of and b) avoiding dependence on those internals staying the same.

You can still teach people how things work or you can still have a list of potential implementations of an interface.

Where the internals matter you would either define very strict contracts or not use abstraction mechanisms that hide internals. But where it matters is not everywhere.

Abstraction to me, just makes it easy to delay implementation. There are sometimes when I need to use an interface now but it won't actually be implemented until next week, when the client gets us our API key, or someone else finds time to do it. Using an abstraction means that I don't have to change any of the code that uses the interface, I just have to change the interface. This is also a good way to make a prototype that is easy to optimize, for example by abstracting a very costly computation, you can just focus on making that computation run faster without having to refactor every line of code where that computation is used.

I’m looking forward to reading this paper. I feel like I’ve found my kind of people. I’ve had this half baked idea about how people should be able to see what’s going on in their computer, and trying to picture what that would look like. At the simplest level it’s the difference between seeing a trace of what the computer is doing when it boots up vs being shown a pretty screen which freezes up. Another is just the way so many software products are like “let us worry about the details”. I want to be able see everything from the bytes in memory to what’s going on in every level of the system and want a user interface that lets people do that.

No, I use functions: https://github.com/akkartik/mu#readme

I just propose to not maintain 3 levels of functions where one will suffice, just to preserve some "interface" for "backwards compatibility".

You aren't forced to understand internals. But it is an explicit design goal to make the internals comprehensible against the day you want to learn about them.

These are good questions! It may well be that there's an architectural breakthrough out there that will obsolete this whole approach. It's one of very many ways it can fail. Think of it as a hedge, at a societal level. What if we aren't able to come up with a technological breakthrough? After all, software has lagged Moore's law for decades now. I think there's a very real danger in the next few decades that software will get regulated like other fields before it, killing the intrinsically motivated aspect of it entirely. That would be a huge loss to society.

We'll have to see how higher levels of the stack develop. I started on this quest building a Lisp, so believe me when I say I can't wait to get to the high-level side of things. There doesn't seem any reason to imagine that we can't have good primitives, grammar and visual representation. My claim is merely that in addition to these interface properties the implementation for them is also important. And it gets short shrift in the conventional narrative.

That said, let's imagine that there's a strong case that we need to give up parser generators (or something similarly high-level) in order to give everybody the ability to understand their computers. I'd take that trade in a heartbeat.

I wrote it for an academic conference (https://2020.programming-conference.org/home/salon-2020) which had as its theme an essay by Ivan Illich (http://akkartik.name/illich.pdf, pdf, 67 pages)

But in the end, your BS radar is your own.

Software does suffer from obvious defects. Though you may not get total agreement on what those obvious defects are, you would get some substantial agreement at the same time.

One of the major effects in software right now is that we pour such a staggering amount of effort into our current forms and patterns that it can create an overwhelming barrier to "better ideas", because there's just no way that even a much better idea can come out of the gate and compete against the behemoth of all the work done with the current paradigms. So we're stuck with patterns written into our systems from 40-50 years ago that can only very slowly change.

As a more concrete example, while my criticism of some things like "visual programming" as "the brand new paradigm that is going to revolutionize programming because nobody has thought of it before" has gotten down to the point I can virtually just copy & paste them to almost anyone who tries them (in the spirit of [1]), the flip side of my polished criticism is that comparing software platforms with literally billions of person-hours poured into them to some guy's hobby project, itself by necessity mostly built on the platform that embodies the wrong paradigm and tends to force itself on to the new project in various ways if it want to come out of the gate able to deal with real problems like "parsing XML" or whathaveyou, isn't necessarily a fair representation of what the project could be if it also had billions of hours poured into it. Unfortunately, as is the way of these things, if it's going to "revolutionize programming" it's got to actually be able to beat the current systems in some useful manner, fairly conclusively, right out of the gate.

As another example, no points for guessing that in a hundred years, computer CPUs aren't going to look much like a modern CPU. Perhaps there won't even be a "Central" processing unit anymore. But I promise you the current architecture will probably hang on longer than you'd guess (I wanted to say "50 years" and honestly got a bit gunshy about that... for all their orders of magnitude more transistors modern CPUs are clearly related to what we had 50 years ago today!). It's going to be hard for that new paradigm to compete with something with so much effort poured into it.

[1]: https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wo...

It's ironic that the presentation is not very see-through.