Comment by jerf

One of the things I've taken to doing on the semi-annual "Hey HN I've Fixed All Programming Problems Forever with $THIS" posts is encouraging people to head straight at these hard problems. I've also been encouraging the commenters writing the writing the "dear lord it's so obvious that we just need to drop everything and use $THIS" to be thinking more about the hard problems.

I believe I've now issued my challenge to the Visual Language of the Day developers to three different people to not show me how to add 1 over a list, but to implement Quicksort (or an equivalently complex algorithm of your choice) in your new graphical language and show me how it's at least as easy to understand as the current paradigm. I chose that one on purpose on the grounds that it's actually not that understandable in normal notation, so I didn't choose that to be difficult exactly, I chose it as something that has some space for improvement, and, like I said, I'll accept any other non-trivial algorithm that you can make a decent case for being easier. I think only one of them actually drew it out, and it wasn't terribly nice; the others have ignored me.

Bret Victor's "live views of the variables updating" stuff looks amazeballs in a crafted demo where only a couple of entities have their X+Y positions displayed in real time, with real-time modification. But it's actually not as new as some people think; I've used debuggers with that capability for a while now. It gets a lot less "ooo.... aaaa..." when you've got hundreds of live-updating values on the screen, and when you've got structured values being manipulated, like, something is adding values to a list as you go, or adding entries to a hash or something. It's actually still really useful and perhaps underused by some people (debuggers, people, I'm down with claims you shouldn't live in them but you need to learn how to use them when you need them!), but it's been around for a long time actually and in practice it isn't quite as game-changing as it looks, because it doesn't solve the problem of finding the important data. Figuring out which parts of a log are important and figuring out which of the hundreds of changing, complicated variables are important aren't that different in terms of effort.

In a nutshell, it's scale. A lot of these alternate "Solutions to Everything" don't scale. For all the faults of "text based programming" (instead of a richer manipulation system, or a visual system, or whatever) and our documentation schemes and the way we debug and how we write our code guarantees and so on and so on... they work. We build large systems with them at scale, routinely. The large systems are perhaps ugly, prone to failures, coughing smoke out of many orifices, and often built of complete garbage, but they work. These "Solutions to Everything" tend to break down at scales multiple orders of magnitude smaller than the current-practice competition.

By no means does that mean nobody should be working on new ideas, be they revolutionary rewrites of the entire status quo, or small improvements to make a lot of people's code a little better. My point is more that especially if you want to rewrite the status quo, you have got to focus above all else on how your solution is going to scale. Your cute little demo that fits on a screen is still going to be necessary to introduce people to your idea, but show me how your system looks with several thousand of whatever it is you are doing, at the very least. I also tell you that my standard isn't "does that look good", because honestly, at that scale nothing looks good because it no longer fits in human cognition; my standard is that you need to have something better than the current standard, which also doesn't fit into human cognition. You don't need to propose something that we can rewrite operating systems or office suites in, there's plenty of other niches, but you do need to propose something that can go beyond a single screen.

The main function programming languages face is not serving up bite-size bits of functionality in comprehensible ways, it's providing ways to slice things into bite-sized bits that fit into my pathetically limited human cognition in the first place. I don't need a better way to understand that this bit of code adds one to everything in the list, I need better ways of breaking problems down into smaller pieces without incurring disadvantages in system organization, performance, composability, etc.