This has probably been posted before but reposting because this always impresses me. I believe this note is from Alan Kay:

This system --including everything -- "OS", SDK, Media, GUI, Tools, and the content -- is about 10,000 lines of Smalltalk-78 code sitting on top of about 6K bytes of machine code (the latter was emulated to get the whole system going).

The software mentioned has a windowing system, multiple desktops, IDE/code editing and running, paint, animation, document editing/viewing, gesture recognition). 16K lines on top of hardware.. how is this possible? (What am I missing?) Source: https://news.ycombinator.com/item?id=19722205 Link to demo:

It's possible because the level of accidental complexity was low. When you build all the systems across all levels of the stack you can ensure each of them do their jobs well and there are no inefficiencies. If there are, you can change it. I'm not a fan of Apple but this is one of reasons they do so well technically (design, latency, etc) - their technology is vertically integrated. Here are some talks about the complexity crisis in software today and why it seems baffling that you could develop complex systems in a few thousand lines of code:

C Code on MC6809 was 40% the size of the same C code on MC68000. MC6809 was an 8-bit cpu, MC6800 was 16-bit. Code size for 16-bit cpus is larger than for 8-bit cpus (MC6809, Smalltalk-78 8-bit VM). Probably another big step from 8-bit to 64-bit. Some early Burroughs machine used Huffman encoding for instructions. Smallest instruction was 2-bits (?).

I’m not sure I want to buy into the sentiment that “things are just more complex today than they had been in the past”. I mean, yes, sure, but they are because we made them so. That applies to hardware as much as to software. We’re just generally bad at cleaning up and getting rid of things. And so we keep old stuff around forever, because, hey, it still works and software is difficult to get right so let’s better not touch it and build new stuff on top of it instead. It takes courage to change the infrastructure and throw away the old that still works, but overall just introduces complexity we no longer need. It’s a dumb and risky thing to do. You’ll break a lot of things and really piss off a lot of people who’ve gotten used to the old ways of doing things. You’d have to be crazy to think that the long-term benefits of reducing that complexity will outweigh the short-term hassle of new bugs, missing features, and annoyed customers. I’m glad there are still a few people crazy enough to keep doing it.

Exactly - We added a ton of complexity and legacy through time, which wasn’t always written by great developers and was often times written to be as generic as possible and it’s all below the surface of your application. For example, look at Android - so much code that was written long time ago and focused at the time of it’s development (32mb RAM smartphones, while they have 8GB now), but it’s still alive and the team is just deciding to rewrite the whole UI layer because the early decisions screwed it up so hard that they’ve been trying to fix those mistakes by throwing more libraries on it and just adding more and more complexity.

I don’t disagree with all that has been said, but I’d like to point out the complexity of the real world vs. a demo as another aspect. An address book good enough for all of planet Earth is probably as complex as à windowing system, because of the complexity of street addresses. Dates are another can of worms. Add domain-specific complexities that few people are even aware of.

Some things missing from Smalltalk '78: Unicode support (character set, fonts, text rendering). Hi res 24bit RGB display, compositing window manager, ability to display and edit photos, play videos. 3D graphics. Internet (TCP/IP, HTTP, etc). A web browser (HTML, JS, CSS). This is maybe 10M loc today? libFFMPEG alone is 1.4M loc just dealing with all the video formats.

STEPS (http://www.vpri.org/pdf/tr2012001_steps.pdf) would be a better benchmark than Smalltalk-78, as that research was designed with the goal of how much of a “multimedia system” could you design in 20k LOCs and it included a 2D compositing engine, networking, web browser and sort of like an office suite (although it still lacked many other things).

Great responses. Some themes I see are: Vertical integration:

When you build all the systems across all levels of the stack you can ensure each of them do their jobs well and there are no inefficiencies.

a ton of complexity and legacy... it’s all below the surface of your application

More essential complexity

the complexity of the real world vs. a demo

Unicode support (character set, fonts, text rendering). Hi res 24bit RGB display, compositing window manager, ability to display and edit photos, play videos

'inertia'

bad at cleaning up and getting rid of things. And so we keep old stuff around forever, because, hey, it still works and software is difficult to get right so let’s better not touch it and build new stuff on top of it instead.

they’ve been trying to fix those mistakes by throwing more libraries on it and just adding more and more complexity.

'compatibility'

...HTTP, etc). A web browser (HTML, JS, CSS).

Perhaps it's also the interaction between all of these dimensions that produces a combinatorial explosion in complexity and 'software material' all around. Specifically wrt 'compatibility', I think we want to look at the end goals rather than the specific implementations. E.g. what services does the web browser/HTTP system provide? Some kind of a UI kit for distributed information/computation systems. Is a browser an efficient model for this goal? What other system could provide the same service? The 'vertical integration' aspect is particularly appealing to me. It seems so much effort is spent just building bridges between layers that have different models. There definitely is much more essential complexity than exists in the ST system. I believe STEPS implemented the compositing engine, basic TCP/IP networking and font rendering. TCP/IP specifically was ~200 LOC (http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html).

Just reading through all three parts of the article you just linked. This is a great quote from number 2 of 3 http://www.moserware.com/2008/04/towards-moores-law-software-part-2-of-3.html:

modern software is typically designed by accretion, much like a pyramid. That is, we design by adding around the edges rather than being willing to do a radical top to bottom design like the Empire State Building which was built in about a year with great engineering precision. We keep adding to systems rather than look back at their core assumptions to see if they’re still meeting our needs.

I don’t think the “dimensions” you extracted are creating “a combinatorial explosion of complexity”, and rather see them as an incentive structure pushing us to “add around the edges” instead of redesign radically: 1. Most projects or organizations are not vertically integrated and don’t control the whole stack, and if you’re dependent on things you don’t control you can’t touch them. 2. The world hasn’t changed much, but we decided we want to model it more closely and with higher fidelity. That’s a design decision (and a good one) that certainly causes more complexity, but not all of that complexity is essential and choosing to leave existing solutions behind also works higher up the ladder of abstraction — do we really need all those different image compression algorithms or should we just keep one of them? Which leads nicely into… 3. Compatibility — of course we want to still access all the JPEGs and GIFs scattered all over the web, even though we have so much better compression algorithms now. Huge incentive towards keeping the old stuff around. We could attempt to convert everything but that’s obviously more difficult than to just keep a few extra LOCs around to still be able to read JPEGs. All that provides pretty strong incentives to not break what already works, avoid the heat of people complaining that legacy will be removed, and so we just keep adding. It's the totally reasonable thing to do. And it’s a viscious cycle as we keep adding more and more things people and other things start to rely on and don’t want to go away.

Choice of programming language is also a consideration. Co-dfns is a 20 pass optimizing APL compiler in 750 lines of code. https://github.com/Co-dfns/Co-dfns The Steps project included Gezira, 2D vector graphics in <400loc, written in Nile, equivalent to 10,000 loc in C (Cairo), even though the Nile code is far less compact than the APL/Co-dfns code. https://raw.githubusercontent.com/wiki/damelang/nile/socal.pdf

i really think that apl could benefit from a game-style visualization: when it was invented this kind of thing was a pipe dream—but the functions and operators were designed to be super evocative (“suggestive”) among other things and expose a lot at the heart of math that lead to an actual textbook for math being developed that used the same notation

You get a lot done by avoiding fiddly bits. If a subsystem isn't carrying its weight, throw it out and everything it does. An example. Back long while now, we had some specific XML we needed to parse in an environment with no proper XML parser. So we wrote a parser for the 5% of XML that we did need. It wan't especially domain specific: it amounted to 95% of the XML that people generally use.

On the topic of vertical integration and complexity, I wrote an article about this a while ago which was a lot of fun to write (so I hope it's the same for reading!). "A Dream of Simplicity: Scientific Computing on Turing Machines" https://hal.archives-ouvertes.fr/hal-02117720

And even standards evolve and — although backwards compatibility is often considered for newer iterations of such standards — every now and then incompatible changes are introduced and the expectation is that indeed everything will be upgraded eventually. Of course, neither does that ever happen for 100% of all content, nor does anybody seriously argue to just stop inventing new and better things in hope of replacing old and worse ones. That's the continuum we operate in and our own tough design decision of what to break and when to break it. And this is a fundamental issue all over our industry: floppy disk/optical drives/networking/streaming, serial and parallel ports/USB-A/USB-C, VGA/HDMI/USB-C, x68 architecture (still supports 8086 instructions). win32/MFC/.net/UWP, Carbon/Cocoa, Obj-C/Swift, HTML/XHTML/HTML5, etc. What's interesting is that in surprisingly many cases these transitions are absolutely unfathomable before the new technology appears, then totally never happening when a new technology is presented as a potential successor, then grudgingly adopted through forcing mechanisms or because of market dynamics, and then absolutely obvious and logical looking back. I cannot think of another industry with such a schizophrenic obsession for both preserving the status quo and radically changing it at the same time.

I wonder if at some fundamental level the kinds of things new standards do is similar to old standards. (e.g. all cpus are 'equivalent' to a Turing machine). And if we are able to define the standards by mapping them to the same thing then moving to newer ones is 'automatic' to a large degree.

@Stefan What makes computing special is that it’s a technology that is at the same time immature and essential for modern life. Hence the need to improve and the wish for stability.