Criticizing Computers | Hacker News Reader

Criticizing Computers

annasofia.xyz

206 pointsbzogrammer163 comments

[caution old man yells at clouds] There are so many comments I started to write, re-wrote, deleted, etc. I have largely the same view of the complexity hell-scape we're creating.

I can't access the vendor binary blob software that has to run to bring up my CPU and system devices. I can't comprehend the 20 million+ lines of kernel running on it. I can't comprehend what instructions I'm running because the ISA spans several volumes. It's not like the 6502 - which you could keep in your head. I know there are all sorts of subsystems that can take over at any time, like the BMC. The drive firmware is free to ignore some of my requests, or lie to me about completing status. When I do write code in C, I can't guarantee that the disassembled code resembles my actual code (I got schooled in that by clang, again, recently). And the CPU isn't obligated to run it in that order. All this was in pursuit of slightly more performance.

And what do we do with that computing substrate? We add layer upon layer of abstraction. To the point where we can talk about server consolidation for a hot 5 minutes after a new generation comes out. But then, five minutes later, we need even more servers. C is too slow to write in. Let's move to Java. Java's too slow. Let's move to Node... but that's not good, let's have a whole infrastructure to transpile JavaScript to JavaScript. Only 12 gigs of dependencies from 53,000 random repos in Github. Write the back end in Java... no Python... no whole programs are too slow... go with web functions. Then a whole other virtualized infrastructure so we can tolerate the loss of a data center, availability zone, or even a Geo. Can we run it in space??? What if the earth blows up? How can we track peoples' browsing if all the world's data centers are destroyed, unless we also run it in space?

Sigh...

the 6502 was not perfect but great for its time. If we were to design it today we could probably leave stuff out. Use multiple bytes per instruction to address the large memory, a few more accumulators and it wil do just fine.

Then we bake x of them onto a chip with y custom roms besides it and write everything from scratch.

Some operations will be more complicated than ever, some things will be slow but most complexity is gone.

As a bonus it will be absurdly cheap to make.

> it will be absurdly cheap to make

Being cheap was one of the key reasons why the 6502, despite its faults†, was great for its time. It was much cheaper to buy than the similar competition (8600, 8080), IIRC by a factor of five in common cases.

----

[†] single true register‡ (plus a pair of more limited indexing registers, three if you count the stack pointer), and a few notable bugs like off-spec wrapping if indirect jump reads from a location at a page end (xxff) which I once banged my head against.

[‡] mitigated a bit by rapid access to page 0

The part where you wrote something and it would run on any c64 exactly the same way. A few hacks aside, you could get some work done and it was done! Today the update circus feels like jenga.

Layers of abstraction aren’t automatically bad. Sometimes abstraction even adds performance. There do seem to be a few layers that are responsible for more performance loss and complexity than others, however. For example, Python is great but runs anywhere from 100-100,000 slower than C, depending on where you look. Investment in some of these layers has outsized importance.

100% agree. As long as the trade off between performance and new failure states is tractable to analyze. My worry is with enough layering, that analysis becomes intractable. Not that you need to account for every imaginable failure (what happens if magic is real and a wizard casts a spell on DIMM 3?). But when things go south, and as a stint as an SRE I have come to realize we are all on a giant South-bound train, you have to perform that analysis.

If each layer is well built and cleanly separated, in theory you can just raise or lower to the appropriate layer. The trick, however, becomes acquiring visibility to the layer of interest.

Layers are not as cleanly isolated as we like to think. Take buffered IO as an example. With unbuffered IO with a dumb drive, a lot of programs run slower. However, what unbuffered IO does is give you immediate feedback about the completion of the IO. I said write 64 bytes. It either writes 64 bytes, or fails.

When I add buffering, I now have a new possible failure state where my request to write data completed, but the data is sitting in the buffer. If the data were really important (say a database) I add a write barrier like a 'sync' call. It's one more thing I need to be aware of. Bufferring adds more ways to fail.

Then we add an additional twist. Our disk controller is really clever and has its own local cache so I can write 64 bytes, send it to the controller, have the controller say "we're good", but not have to wait for the data to be written to the platter. With the dumb drive, that wasn't the case. I had immediate feedback. But now we have a new failure state and I have to account for that as well. Maybe I have to put battery backup on the controller. Maybe I need a new primitive to really flush the data. And I might also have new errors where the controller accepts the data, attempts to write it to disk, but the disk is dying and fails to write. So my program lost data and the only way I know about it is to look in an unrelated log for drive failures. Unfortunately no one thought to check or change the card's battery backup in 3 years...

This isn't just a caching problem. Let's say you take some functionality and move it from a library to a service on the network. Now you have to account for all sorts of other issues related to network failures that just weren't part of the base case for local resources. I can no longer just make a call, I have to think about things like retries, or what I need to do if the service is unavailable. Possibly, I need to percolate up new errors to drive my code into behaviors like caching the data locally until I can send it. My debugging also gets more complicated, like 1) is the server alive (ping is often blocked so we use Test-NetConnection to do an NS lookup, ping, and TCP connection test), 2) Is the address routable? 3) Is my network connection still valid (e.g. did my local switch meet its maker)? 4) Do I have correct certificates (e.g. we can't complete the SSL handshake)? 5) Was there a protocol change (e.g. Team A is sending {"foo": 1} but Team B is expecting {"foo": "1"}, and so on.

It isn't a layering thing like well constructed, SOLID code, it's changing the assumptions and conditions you have for all sorts of states you could be in. It's even further compounded with complex services where service A depends on B, C, and D, and D is failing. But now the data in B and C don't reflect what's in D, which failed to update. Your code becomes much more complex to handle these additional failure scenarios. Your search space for possible failures is orders of magnitude larger.

You’re completely right, of course- in my thread of reasoning I argue that the buffered disk controller you’ve identified is a leaky abstraction layer. Battery backup and RAID are forms of hardening that abstraction.

In practice, we’ve allowed that particular layer to leak persistently because it’s ultimately cheaper to handle the leaks than to harden the abstraction.

This is very similar to another article posted recently[0].

I both agree and disagree with what the author is saying. Like, they claim:

“The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster.”

I wrote this in the linked thread:

“It really does seem to be dependent on the type of work you’re doing. In 2000, I started writing plugins for Final Cut Pro. You could write “real time” plugins for it! That meant you were working in YCbCr 4:2:2 at 320x240 and 30 frames per second (so quarter-sized frame, with 2/3rds the data that an RGB frame would carry and half as often). 22 years later, I’m still writing such plugins, but on the top-end systems you get multiple streams of 8K uncompressed RGB video at 60fps and you can play back in real time.”

And I forgot to mention that that video is also processed in floating point (usually 16-bit half float). According to my calculations, that’s about 862x more data being processed in the 8k case.

But some of the other points I think are way off. They talk about piping data from one command to another. That’s not how typical users work, and I don’t think it’s how they want to work. I don’t want to pipe data from /dev/MIDI into one command that stores it, and pipe /dev/microphone into another command, and use a third command to mash them together and compress the result so I can listen to it on my phone. I want to use a DAW that records tracks (which are not textual data and would be very inefficient to represent as such) and sometimes I want to render the result to an audio file I can put on my phone.

[0] https://news.ycombinator.com/item?id=31798580

> “The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster..

If I had a choice to swap from the current paradigm of running the programs we have now at the speed we have now or running things 1000x faster but only being able to run programs that were programmed 30 years ago, I don't think I'd take that swap.

> but only being able to run programs that were programmed 30 years ago

Take the swap. I don't think you'll loose much. Most programs are doing pretty much the same thing as 30 years ago, but with hi-res graphics

30 years ago was Windows 3.1. People still listened to music on CDs commonly until the smartphone era.

Using a computer was kind of scary even 10 years ago. They were way buggier and had more exploits. Clicking the wrong link in the WinXP era was not advisable.

Programs do the same thing, but they do it more reliably.

At least in the GUI world. I don't know what's changed as far as the command line experience.

You know what? I think I might.

https://en.wikipedia.org/wiki/Amiga_productivity_software

https://en.wikipedia.org/wiki/Oberon_(programming_language)

That was my first thought too, but .. I honestly don't think I'd take that bet.

I still have an A1200, and I struggle to think of anything that'd be genuinely improved by having, eg 7GHz instead of 7MHz (to take the article's 1000x figure) processor. 1000x the serial speed would be useful once or twice a year. 1000x the disk access speeds would be a marginal quality of life improvement (I mean I wouldn't say no, but I wouldn't give my modern machine up for it). But making the whole system 1000x faster would realistically achieve what? A hilarious SysInfo screenshot and little else.

Half the argument is not what you would do with it. The hook is that literally everything you could do back then would be instant. I would very much like that.

Given that Oberon existed, any green-field development I would have to do in that environment, would be completely feasible and comparable to any advanced environment today. The only thing I would maybe miss is a modern IDE, but on the other hand I was a late-comer to that and used (and still use) Emacs for a long time.

Better yet:

https://plan9.io/wiki/plan9/plan_9_wiki/

http://9front.org/releases/

Most applications we use really aren't doing very much more useful than their equivalents did thirty years ago, but they are several orders of magnitude slower anyway.

I don’t agree with this at all. It used to be that, for example, if you wanted to spell-check your word processing document, you had to select “Check Spelling” from a menu, and it would analyze the document and give you the results. Now it happens as I’m typing. There are numerous things like this that we rely on but have forgotten didn’t happen even a short time ago. File search is another. The metadata and contents of files is constantly being indexed so that when you search for something, you get results within seconds if not faster. I remember waiting for Windows search to find a file on a “large” hard drive. It was excruciating sometimes.

None of which can explain why launching an Explorer window takes a perceptible amount of time, or this: https://youtu.be/GC-0tCy4P1U?t=1767 , or any of thousands of similar atrocities of wasting everyone's computing resources and time to accomplish nothing of note.

Because people spouted crap about premature optimization any time someone wanted to do anything like lazy load an uncommonly used feature?

In general, I'd agree. But one of the most productive word processing programs I ever used was WordPerfect 5.1 for DOS. (Not only because while using it you couldn't do anything else that distracted you.)

Okay, you couldn't do page layout for the company newsletter in it very well, but based on the .docx files I've gotten over the years, people can't do that now either.

> That’s not how typical users work, and I don’t think it’s how they want to work.

This hits the nail on the head: most users are not programmers. While the unix philosophy works well for programmers it is not suitable for non-programming users. A small collection of single-use tools that can be orchestrated is a programming interface.

One might argue that the unix philosophy doesn’t work well for programmers either. Do I really have to parse one command’s output to do anything meaningful with it?

These small commands, piped together make it possible to build, boot and run systems that are in everyone’s pocket and run software that does work the way users want.

> That’s not how typical users work, and I don’t think it’s how they want to work.

That's true. But if people were routinely offered convenient ways to automate, build pipes, or whatever the technique, then perhaps normal people would learn and use it.

I think "piping" was meant as a general metaphor for interoperability. We often hear regular folks say "why doesn't X just work with Y"

EDIT: sorry I misposted this reply

Amiga had "AREXX ports" which meant you could script desktop software together in ways not possible even today, on any OS.

It's not enough that there must exist technically, a possibility. The app vendors much themselves go to the trouble of adding such "scriptability" into their apps.

Instead everything is very slick, but very siloed and nowadays tied to a cloud offering, which is great, but it's more often than not locked to that vendor.

It's most obvious with video, but that's not the only change. Thirty years ago you couldn't:

    * Run games that approach photorealism at 4K resolution
    * Emulate a recording studio with virtual instruments/FX in your laptop
    * Watch video streamed at 4K
    * Stream video from home and add live video FX
    * Record and edit video at 4K using a pocket device
    * Download files from a global communication network at hundreds of Mb/s
    * Search that network and get results almost instantly
    * Take usable speech recognition and automatic translation more or less for granted

The OP is poorly argued. Presumably they're trying to ask why software isn't 1000X better.

In some ways it is. Phone apps particularly are much more usable and intuitive than desktop apps from 1992.

In other ways, especially on the web, there's a lot of cruft floating on top of a sea of bloat. But there's a conscious tradeoff between abstraction/development time and runtime performance. The web would not suddenly become more usable if everything was written in machine code.

Elsewhere there's a lot of drag because of backward compatibility. Office is still a thing because nothing better has replaced it. It's ugly and stupid but it fills a niche that needs to be filled and - for all their efforts - FOSS isn't a realistic alternative for mainstream, professional use. This also applies to a lot of other industry-standard apps like Photoshop.

The limiting factor isn't CPU, it's the user. Most of these apps spend vast aeons of time in an idle loop waiting for the human to do something.

You'd need to invent new kinds of assistive apps to get around this, and we're beginning to see those with AI. But they'll be disruptors, not replacements, and it's not obvious how that's going to work out.

In addition, the engineering skill required for writing basic desktop software is much lower than it used to be, while the skill required to write code for a game engine, audio/video processing, low-level network stacks, or any of the other problems on your list is just as high as it used to be, if not higher.

Back in the day, anyone writing even a simple desktop app needed to know about algorithmic complexity and low-level optimizations, or their code would be intolerably slow (if it even ran at all). Today, if all you’re developing is a simple productivity app, high-level abstractions have eliminated the need for such low-level knowledge, dramatically lowering the barrier of entry for developers, at the expense of software efficiency. In other words, if the problem you’re solving is inherently easy, it is easy to write (inefficient but fast enough) code to solve it. This used to not be the case: even easy problems required difficult code to solve.

However, all of the problems on your list are inherently difficult and complex, and thus still require difficult and complex code to solve. The barrier of entry for developers remains high, ensuring that those who work on said problems still have thorough knowledge of how to write performant code.

> The processors in our laptops are over 1,000 times faster than they were thirty years ago. So it’s natural to ask, as Joe Armstrong does, why our programs don’t run 1,000 times faster.

I think the simple answer is that processing is only a small part of running anything, data fetching is what you're typically waiting for. Sure cache and RAM speeds have increased, but HDDs are still about as horribly slow as they always were. Only the jump to SSDs made a considerable difference in "general" speed recently.

But on the other hand I suppose we can in fact run the original Doom (released almost exactly 30 years ago) at about a quadrillion FPS these days so maybe I'm wrong.

The question could be steel-manned when restated as: why does today's average app, in order to complete an ordinary task - like displaying a series of characters on the screen - need to run 1000x more CPU instructions than yesterday's? Replace "1000" with whatever that multiplier, result of the proliferation of intermediary abstraction layers, actually is. I wouldn't be surprised if it is even more than one thousand, at least extrapolating from this article, which was also posted on this site today: https://danluu.com/input-lag/

Well aside from the usual Wirth's law answer, the key is high abstraction on all levels, which brings bloat with it.

Eventually that bloat will get optimized, as that chart interestingly shows iphone responsiveness being somewhat corelated with increasing years. Same with Windows, where there was a sizable abstraction jump with Vista, which then got slowly optimized over 7, 8 and 10.

There's even abstraction in memory management now, with 64 bit virtual address mapping. I've recently stumbled upon these ARM benchmarks https://github.com/ThomasKaiser/sbc-bench/blob/master/Result... and was surprised that the Pi 4 runs 10-50% slower in 64 bit mode compared to 32 bit. I'd expect there was also a notable speed decrease when going from 8 to 16 and 32 bit systems, since there's twice as much address data to fetch and process.

like displaying a series of characters on the screen - need to run 1000x more CPU instructions than yesterday's?

Because the users want those characters displayed in the font, size and colour of their choosing at a very high dpi, anti-aliased, in a semi-translucent terminal. They might also want the text parsed in real time so that it can be coloured, formatted and checked for spelling and grammar.

Other than the high dpi you could do that in 1995 microsoft word.

And because the programmers want to write it in an interpreted virtual machine ran language with dynamic typing.

True, that as well.

Don't forget they want full Unicode support with all the complicated layout and composition rules.

I would add the momentum of resources has not only made programmers lazy, but has produced a cultural momentum for inefficiency in almost every aspect of computing. Personally I've watched the amount of information and functionality in a given amount of screen space plummet in my lifetime. Pull down the quick settings menu in Android 13 and it uses a three inch by five inch rectangle to show...eight buttons. Windows 11 won't show you the names of the windows you have open unless you edit the registry. What the hell is happening to us?

that's a shoddy metric though. I'm not an aircraft pilot or a lover of 90s teletext, measuring efficiency in terms of number of buttons per square inch makes no sense on a medium that has infinite scrolling surface.

Empty space is very much a good thing, we crammed things together in the past because we had no other choice, not because it was very legible.

It's not just about the visible buttons (and scrolling is not a "free action"), keyboard shortcut support has been going down.

Even merely finite scroll can cause UI issues.

Today, with invisible scroll bars, it's not at all unreasonable for someone to be oblivious to the offscreen content; but even making them always-visible isn't enough, as my dad demonstrated by taking 3 years of home internet to realise Google search results were not just limited to the first three that just happened to be at the top of the page.

He'd retired a few years earlier, having been working as a software developer since approximately when that became a new idea in the UK private sector, back when punched cards wasn't a cute retro reconstruction.

Most of the decisions about the direction of UIs weren't made by "programmers" acting on their own but by companies - mostly Apple and Microsoft with Google and others involved at different points. I think the decisions were made for the same reasons companies like to dumb down everything - least common denominator is good for sales and dumbed-down means users have less power and are more dependent.

Extra tragedy here is that people now live in software and so most people have to live in this stupidity.

UI changes are the perfect example of "change for the sake of change". I am sure these people don't even consider the fact that over time the UI of a software becomes part of the user's subconscious and it just fades away and let the user do the job as quickly as possible, changing this UI to something completely different is just a mental torture for your users.

> UI changes are the perfect example of "change for the sake of change".

Exactly. It's just making changes to comply with whatever is fashionable at the time. Utterly pointless and annoying crap.

My mom, cause of her eyesight, constantly increases default font size and every single simple action on her phone is like solving a sudoku puzzle.

My theory is these designers dont have family members or they dont care about them.

> My theory is these designers dont have family members or they dont care about them.

Or they don't have family members with bad eyesight.

Or they actually do have family members with bad eyesight, but those are not active smartphone users.

Or they actually do have family members that both have bad eyesight and are active smartphone users, but they take the advice to simply buy a device a mobile device with a larger screen.

Some of this is rose-tinted nostalgia. The bit about "five nines" reliability... big expensive servers and workstations got there but computers the average schmo could afford never did. Frequent BSODs and system freezes were the norm. Now that we've moved on to proper multitasking OSes - which I admit are more complex and resource-intensive than their predecessors - crashes like that have become far rarer.

On the other hand, this is clearly gesturing at something real. Computers and network connections are so much faster than they used to be, and yet webpages feel like they load just as slowly as they did in the dial-up days. Oh but we have so much better ad-tech and telemetry now! Because that's what I go on the internet for, the ads. Sure you gotta pay the bills, but how much of those bills are just for maintaining the advertising bloat versus the actual content?

Well it's not like things were any better in the past. They were just a different kind of crummy.

The five-nines was a commonly used marketing claim used by companies about the product/service/system they were selling, it wasn't and isn't being applied to a general context. I think the point being made there is not that all the computers/software used to be better/perfect but that the fact that such claims were used and became so prevalent shows that reliability was a feature and even an expectation.

I really resent Blow's talk, because while his points are mostly valid, the "facts" he presents to support his claims are poorly selected; some of them are outright lies.

Five nines refers to overall system availability and it's not a lost metric, it still exists within the same sphere it's always existed: banking mainframes, data centers, hospital systems, emergency dispatch switchboards etc.

It's never been used to market personal computers or software for them.

> computers the average schmo could afford never did.

No they really did.

Personal computers from the 80s will still boot (instantly) and perform perfectly today. I put modest servers together in the late 90s and they were still chugging away a decade into the next century. Uptimes of 3, 4 even 5 years were not unusual.

We live in a disposable culture now. I think many of the people disputing that simply haven't lived long enough to experience high quality engineering.

I don’t know, if anything OSs were quite unstable (I can’t speak for the 80s, but slightly later). When was the last kernel crash you’ve seen? We definitely have less of those now than we had in the 2000s.

I had to reboot my Windows PC at least once every few days back in the XP and Vista era. BSODs were common especially while gaming. I think moving GPU drivers out of the kernel into userspace made a big difference as GPU driver crashes are now recoverable. Nowadays I can go weeks or months without rebooting, only rebooting for forced security updates.

I agree that this is good, but was it worth all the extra expenditure in energy, resources, and environmental damage that it took to achieve? Rebooting my XP machine every few days (or, really, just getting in the habit of shutting it down when I was done for the day) didn't seem like a huge burden at the time.

I had a Windows XP machine that was pretty stable. I did reboot it sometimes. I now have a Windows 10 machine that is very stable, if you ignore the fact that it reboots itself All The Time. I have a dual-boot set up with linux as default. If I ignore the machine for more than a day or two it will have rebooted itself away from Windows into Ubuntu. Maybe this is a feature after all.

I’m fairly sure that’s just the idiot “shutdown is replaced by hibernate” of Windows doing something hard to explain. In short, if you press on the shutdown option in Windows it will instead hibernate by default to make “boots” faster. You have to shift-+click on the poweroff option on the menu for the behavior you want.

What probably happens is that it assumes it is the only OS and goes into another mode if not used for a few days? (This part I’m not sure about but the previous paragraph is true). But perhaps Ubuntu is your default in the boot order? Nonetheless, try to poweroff your windows with this shift+click and check if that solves the problem.

Biweekly on my 2018 ipad pro

It's not required that people rely on data centers and cloud computing, those are just choices that people make. It's a matter of convenience and economics - it's now cheaper and easier to host a site at a server farm, than to manage your own server. You can still choose to set up a server in your basement, and maybe have a failover cloud strategy in place if traffic gets busy. It's just more work and moeny.

You don't have to rely on programming paradigms involving a great many dependencies and lots of computing overhead, which are hidden by fast CPUs and GPUs. You can write code carefully in low-level compiled languages, knowing bugs will be a problem, but creating small compact binaries. It's just more time and effort.

There's a real trend towards what one might call retro-computing - having a RPi server on your LAN that you back everything up to, maybe some long-term encrypted cloud storage (or just an encrypted USB drive in a safety deposit box) for disaster recovery, but not for regular usage - and only using applications with local client-side data storage, and so on. Never pay for Saas, never lease proprietary software, pass laws that make it illegal for your personal data to be stored in some corporate database for marketing and advertising purposes, etc.

You don't have to buy what the corporate computing world is trying to sell you, in other words.

One of the main problems is marketing. Adding more bells and whistles to something makes it more marketable. And so we invariably trend towards more complexity, even when it doesn't really provide any "real" return. This also drives constant changes just for the sake of change - to feel like what you have is genuinely new as opposed to a fundamentally identical rehashing of what you already had. Operating systems being the obvious culprit there.

And the most frustrating part of it all is that often the more marketable concepts are often just worse. Flat design is one obvious example. It looks sleek and sexy in marketing especially compared to the janky pseudo-3d effects of times past, but not being able to determine at a glance which parts of your UI are interactable is objectively less functional. But functionality < marketing.

The one other thing I'd add is that this is not limited to software/hardware. Movies face the exact same issue. Explosions, effects, and "loudness" are highly marketable, people standing around talking isn't. So we went from movies focusing on personal interactions to movies focusing on people running around in spandex in front of green screens screaming and battling other people in spandex, all while stuff explodes around them and special effects zip and zap about, while music with all the emotional subtlety of a hammer to the head blares. Progress!

Software was slow, crashes were common, interfaces sucked, UX was horrible. That’s my memory of the olden days.

Sure, maybe it’s not 1000x faster, but many programs nowadays are very fast, very stable, and have a usable interface. Almost every program I regularly use has a search for its settings, back then I’d be happy if it even had all settings in a single location.

A big part of that was paid by hardware improvements. And that’s okay with me. There are exceptions, like electron which (in almost all cases, a notable exception to the exception is VS Code with discord as a distant 2nd) is slow even on a very fast PC, but generally developing got easier and software got faster and better.

But hey, I’m only 36, so maybe it was in the 80s when everything was as awesome as those articles paint it, and by the 90s everything already sucked.

It largely depended on what computers you had access to in the 90's, DOS and Windows PCs indeed felt medieval in the early and mid-90's compared to the Amigas, Ataris, Acorns, Apples, SGIs, Suns and NeXTs.

> Apples

I dunno about that, I had a Performa 5200 in the late 90s[0], and I think I was getting at least one "System Error Type 11 [Restart]" per week.

I think I still prefer the Classic MacOS UI over modern styles, but I'm not sure how much of that is "greymuzzle has rose-tinted memory of childhood" vs. "skeumorphism is genuinely useful as it makes it clear what things are buttons vs. labels".

[0] bought with a combination of pocket money, skipping lunch to save the school lunch money, and even then only affordable because PC World discounted it by more than 50% as an ex-demo model

Let's take the c64 as an example.

First, you had to pull the right diskette from your shelf that contains the program you wanted to use, because all the programs weren't in the same place. Let's hope you know where you put it.

Then, enter one or more commands to load the program that, for purely technical reasons and lack of standardization, are different for each program (load first directory entry vs. load specific directory entry vs. load directory+list directory + load entry). Wait 10-20 seconds to load. Sometimes it was faster, IIRC because by default the 8-bit-parallel line to the drive had 7 lines unused and pushed bits in serial so there were "fast loaders" that just moved bits in parallel.

Then, after loading the program, you had to start it (unless it was autostarting), again with an application-specific command (typically "run", but could be by calling a specific memory address like "sys 4096"). Many programs hat to load other stuff again and again because, well, 64k memory isn't a lot.

Sometimes you had to flip the diskette over or swap it with another one.

Let's face it: While today's software is sometimes ridiculously slow given the hardware it runs on, claiming that the 80s were better is pure nostalgia. Consoles of the time were better (I think the NES had 0,5 seconds from power switch to the game's first splash / title screen), but they used more costly ROMs instead of diskettes and were seriously hardware-feature-limited.

I remember playing the Hitchhiker's Guide text adventure on C64 where everything you typed took like 20 seconds to get a response.

> Good hardware is masking really bad software.

If you did not know, the new Pokémon games on Nintendo switch run abysmal - low resolution, even lower frame rate, pop-in, aliasing, etc.

Some people claim the "aging hardware" of the Nintendo Switch is to blame because the games looks just fine on overclocked systems and emulators.

Meanwhile older, probably better coded games like Breath of the Wild run without problem on the so called "aging hardware".

Mm.

Was thinking similar thoughts recently about Civ 6, and how much longer it takes to load saved games than Civ 2 ever did.

(What's Civ 6 even doing? Deleting and reloading all the textures and/or recompiling all the shaders each time?)

> Was thinking similar thoughts recently about Civ 6, and how much longer it takes to load saved games than Civ 2 ever did.

Original Civ opens with a dramatic intro sequence:

In the beginning

the earth was without form

and void.

But the sun shone upon the sleeping Earth

and deep inside the brittle crust

massive forces waited to be unleashed

(It goes on for quite a while after that. The unofficial guidebook to Civilization, Rome on 640K a Day, notes that there's a text file containing the intro lines, and suggests replacing them with Douglas Adams' popular quote "In the beginning, the universe was created. This has made a lot of people very angry, and been widely regarded as a bad move. [...]")

You can press escape to skip the intro, except that that won't work on computers contemporary to the game.

I eventually realized that the intro sequence is there to mask the time the computer takes to create the world at the beginning of the game. Skipping won't work until the world has been laid out in the background.

Loading is quick though.

I mean, we can also bring up examples for great games that make efficient use of the underlying hardware, e.g. Teardown (if I’m not mistaken that’s the one with voxels where you have fire effects, proper physics, real damage to volumetric objects for the whole world), which would have been unthinkable without today’s hardware.

It’s funny that people choose Breath of the Wild as their example of a game that runs without problem, seeing as it had major frame pacing and frame rate issues when it came out and still struggles to hit a consistent 30FPS on occasion.

"Of course, it wasn’t always this way. Computers used to be small and straight forward. They used to be cute! Now they are big and scary and mind boggling."

You're kidding right? Having a desktop PC in the pre-internet days was a scary experience. My smartphone and iPad are both cute and work unblinkingly every time all the time.

I think that was a reference to dark sprawling data centers.

(A computer that boots to) BASIC is small and cute compared to DOS. Windows 2K is small and cute compared to Windows XP compared to Vista to 7.

What was scary about having a desktop PC in the pre-internet days? I often use my desktop PC without the internet to this day. A lot of modern software expects you to be permanently online, however.

The difference is that your smartphone and iPad are hiding a ton of complexity from you, whereas an Apple ][ or a Commodore 64 hid almost nothing from you -- it did less, but was much more transparent about it.

> You're kidding right? Having a desktop PC in the pre-internet days was a scary experience. My smartphone and iPad are both cute and work unblinkingly every time all the time.

I beg to differ:

- no scary golden cage

- no fear of being surveilled

- it was possible (DOS) if you were seriously to understand at least huge parts of the whole OS that ran on your PC

- it was possible to understand the bare-metal software interface to the hardware; you had to, because if you were writing, say, games for DOS, you typically accessed the hardware (e.g. your sound card) directly.

I'd love to redesign computing from from the ground up. With deliberate decisions that focus on clarity and elimimation of redundant layers. I suspect you could even obsolete pieces like the IOMMU, relying instead on robust static analysis and sensible data transfer primitives. And tackle latency at the same time (less steps = faster response).

While not exactly what I have in mind, Propeller seemed like a shot at re-envisioning things from a hardware level. At least, it made me go 'huh, there's an elegant alternative to the status quo'. Singularity was another ambitious attempt to do some substantial innovation, that time around plumbing of the OS.

Me too! I started http://civboot.org and have been working on it's language fngi. It's been a blast so far!

It's a little ironic to me that even rants about how programming has gotten worse recycle the same points from 30 years ago. Read https://391.org/manifestos/1991-manifesto-futurist-programme... and spot the difference.

so it all just gets worse

The intro is so full of hyperbole I couldn't make it past. Which arguments were recycled?

On the pipability front of software, I think a lot of that happens through APIs now, either directly linked or through various network APIs. The gotcha is that few APIs can handle the kind of asynchronicity that a pipe can. With pipes I can so something like:

    oaktree | nutgrinder | cookiemaker | cookieeater

and as soon as each nut is ready from the oaktree, it can be consumed by the nutgrinder and it can send nut flour to the cookiemaker as its ready and when the cookiemaker has enough nut flour to make a cookie, it can send a cookie to the cookieeater. Four processes, acting in parallel¹ with little friction to make it happen.

Now, try to architect this in your favorite programming language.² I did see where Google proposed something (almost a decade ago) for C++ to allow this https://isocpp.org/files/papers/n3534.html although I don’t know where it stands now. I’ve been thinking along something similar for finl for each of its stages so that, e.g., parsing and tokenization doesn’t need to be complete to start formatting, but it would be nice if there were a simple language facility to allow this.

REST APIs also fail at this insofar as you need to wait for a whole request to complete before you get a response rather than being able to send the request and get each chunk of data back as appropriate. We seem to have forgotten so much that we knew thirty years ago.

⸻

1. Although not necessarily. IIRC, good old fashioned DOS pipes would wait until each process was done before opening the next application in the chain.

2. Assuming, of course, that shell scripting isn’t your favorite programming language.

Tangential but just curious, do people make cookies out of acorns? Beside squirrel people that is.

Native Americans as well as others have used acorns for flour and such https://en.m.wikipedia.org/wiki/Acorn

>REST APIs also fail at this insofar as you need to wait for a whole request to complete before you get a response

This isn't a restriction from REST. Nothing stops you from implementing an API that starts responding before your request is finished.

The main problem I imagine is that you do not have a real way to deal with errors; you need to reply with 200 OK before you send anything else. There's also no separate channel for errors analogous to stderr.

> Now, try to architect this in your favorite programming language.

Isn't this trivial in java with streams? Or in C# with linq? Maybe I'm missing something.

Or in C++20 with range adaptors.

  for (const auto &nut: oaktree
       | std::views::transform(nutgrinder)
       | std::views::transform(cookiemaker)
       | std::views::transform(cookieeater))
  {
    // do something
  }

...or in Python with generators/iterators. Or in Lua with coroutines. Or in Rust with iterators...

I guess most higher-ish languages at some point gain support/framework for something like this. But the point stands: there's something both simple and powerful with pipeline abstraction. I think of pipeline as a way of thought. Something that bridges the gap between "user" and "programmer". It's no wonder some of that "way of thinking" was implemented into programming languages (with obvious and non-obvious implications, not limited to memory requirements).

These are all syntax though (except perhaps Lua’s coroutines—I don’t know enough to say about those). It’s not the syntax that’s the wonderful part about pipes, it’s the parallelism. See my other post with some Java code in this thread.

The individual steps in a java stream don’t run in separate threads/processes. So, for example. given the following code:

        IntStream.of(1,2,3,4,5,6,7,8,9)
                .peek(System.out::println)
                .boxed()
                .map(val -> {
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                    return "a" + val;
                })
                .peek(System.out::println)
                .map(val -> {
                    try {
                        Thread.sleep(3000);
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                    return "b" + val;
                })
                .forEach(System.out::println);

the forEach essentially acts as the driver for each step so that you’ll see everything happening in sequence. The equivalent shell script version of this would output in the order (approximately) of 1, 2, 3, 4, 5, 6, 7, 8, 9, a1, a2, a3, ab1, a4, a5, a6, ab2, a7, a8, a9, ab3, ab4, ab5, ab6, ab7, ab8, ab9 and finish in roughly 28 seconds instead of the 36 seconds that the streams version does. Streams are syntactic sugar and do not provide parallelism on their own.¹

⸻

1. And don’t get me started on the hot mess that’s the Java parallelStream

But don't pipes also block when the buffer (~1-4kb) is filled until the output can be consumed? So as I understand it's still sequential in the bash version, only there's a bit of buffering at play.

Go handles this very cleanly with channels and goroutines.

I literally read this chapter in The Go Programming Language last night after posting this and thought to myself, well, shit, there it is.

Bring up the circa 1985 Amiga (or Macintosh) OS in emulation and marvel at how responsive it is given the unbelievably primitive (by today's standards) technology. The entire memory of the machine was less than it takes to store a smallish JPEG image (and decoding even a GIF was a major undertaking on the order of 1 minute runtime) and the whole OS fit on an 880KB floppy with plenty of room left over for your files (plus 256KB ROM of course).

And then marvel at how much stuff you take for granted these days that just doesn't exist, from antialiased fonts to any kind of network connectivity to, of course, instant decoding of highly compressed sound and graphics assets.

The fact is we got to all the modern conveniences by the path of least resistance. You take it for granted that a good smartphone costs less than a floppy drive - just the drive, no "brains") would have cost in the mid 80s and that all the software functionality on it comes essentially for free. In the alternate universe, your phone would be 1/10 as powerful, run software that's 1000x as efficient... and probably cost 10x as much.

> The fact is we got to all the modern conveniences by the path of least resistance

This is pithy and raises a broader question: once we have started down the path of least resistance and identified (or already tripped over) hazards on it, how can we switch tracks, as it were? Not only will this necessarily involve some hill-climbing but tech accumulates inertia too

The downside of how they did it is a complete lack of memory protection. So not only can processes corrupt one another, but all of the coprocessors that are used to offload tasks have access to the entire memory space. The result is certainly responsive, but also quite unstable.

Sturgeons law (1950’s) states that 90% of everything is garbage. I see no reason why computers and software should be exempt.

I also do find myself chuckling at posts like this being upvoted on a website which also leans to new shiny things so heavily.

The problem will solve itself when folks start ignoring products that are half baked. I’m not holding my breath that will be anytime soon..

I have a corollary to Sturgeon's Law: "Most people are wrong, most of the time, and the people that are right, are usually right by accident."

I thought of this after listening to someone smugly quote one dead economist after another, while we both knew full well that all those economists were mostly wrong about everything.

A (structurally similar) variation of Gorgias 'On Non-Existence' argument!

Another famous one being Lem's law:

> No one reads; if someone does read, he doesn’t understand; if he understands, he immediately forgets.

There's also

It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It.

(Upton Sinclair)

Simplified:

Reason serves desire

The issue is not that nobody can hold these systems in their head, they can - they're just not paid to.

Your average developer will be working in a new job, on a brand new tech stack, in 2 years. Is two years enough time to understand the intricacies of doing serious work with that set of tools?

The additional bit is that operating system kernels and hardware have gotten really, really, really good - so very much of the programming paradigm is to spend as little effort as possible to write the stupid thing, because most work is boring and stupid and doesn't get you a competitive edge, eventually the compiler, the operating system, or better hardware will fix it for you. However, if you spend a lot of time working through something and doing it right, the timeliness gets you put on performance review.

> The issue is not that nobody can hold these systems in their head, they can - they're just not paid to.

As of 2022, the largest transistor count in a commercially available microprocessor is 114 billion transistors[0]

According to cloc run against 3.13, Linux is about 12 million lines of code.[1]

Anyone that tells you they can keep this much information in their head is lying to you. And this doesn't even include how many lines of code are in a modern browser, which is still before we even get to a modern web dev stack. The total culmination of layers of code is impossible for any one person to hold in their head.

[0]: https://en.m.wikipedia.org/wiki/Transistor_count

[1]: https://unix.stackexchange.com/questions/223746/why-is-the-l...

I agree. In fact, many open source (and closed source) codebases are understood by only a handful of developers with deep understanding of the design and code (e.g. the original developer or a developer with many contributions). The rest of us (including me) have a superficial understanding of the code at best. There's even a word that developers use to describe popular open source frameworks: 'magic'. A euphemistic way to say: 'I have no-idea how the code fit together, but this code library or framework is popular and it all works'.

For newly developed software, most of it these days is SaaS. I think this is not stressed enough as the major architectural chokepoint.

For decade-old accumulating code, IMO, AI may offer solutions. Many will sneer that AI is an even worse epitome of the opaqueness that is our problem in the first place. Agreed! maybe we can make it less so?

The real incoming disaster, I believe, is that we are pushing tens of billions into developing and marketing new immature computing paradigms like AR/VR/IVA that will put our "information machines" exponentially more behind an impenetrable wall.

But do Hackers truly believe most people should be code-literate? The irony is that, for example, a lot of them would not even consider the idea of cooking their own food (let alone grow it).

I might be creating a no true Scotsman here, but it seems to me that a True Hacker (tm) probably does cook a lot of their own food.

Not that I’m disagreeing with you; just picking nits in the spirit of yesterday’s parody.

> Computers are telling me what to do, but I can’t tell them what to do.

This absolutely infuriates me, I feel like I have zero control over my computer these days and it has gotten far, far worse in only the last few years.

The computer does things I didn’t ask it to do, things I don’t want it to do, and it refuses to listen when I say otherwise.

It legitimately angers me when something unexpected and unpredictable happens because someone else somewhere decided it needed to “for my own good”, and I don’t have the power to stop it.

I have strongly “rebelled” against this on my personal computers and it has heavily influenced the operating systems and software on top of them I am willing to use.

But if the fellow with his foot on your neck really does know better, and is only strangling you for your own good, then isn't it just your own foolishness that leads you to protest?

She's right and I hate it. I used to love programming and now all I can think whenever I see 99% of software is, you don't need this. It exists to prop up capital.

I can't even think of anything useful to code. All the useful stuff has been done.

I just want to play board games with my friends, lift weights, read books, and never use any piece of technology more complex than SMS ever again. I am 25. If the internet weren't responsible for my coming out I'd say burn it all down.

This is very much how I felt around 2005-2007, just prior to the iPhone. It's incredible how quickly this feeling of stagnation fell away in the face of the New. Have faith that something New will come again, and you'll be there to break that new ground!

Until then, I guess we can just grit our teeth and take solace in our own art - and of course, in weights, books, and friends.

> feeling of stagnation fell away in the face of the New.

Not to get too deep or philosophical, but that feeling of stagnation many times is a sign that you're lacking a true purpose in life. That shiny new thing is, sadly, a false God that is by it's very nature temporary, and the feeling of purpose brought out by it fleeting.

Personally I think putting your hopes in The Next New Thing is a bad idea, long term.

Take that all with as many grains of salt as needed.

As I stare at this comment on my magical handheld slab of light I can't help but wonder how many layers of virtual machines, or other abstractions, are between the pixels and the source data they represent. I can think of more than I care to admit.

Lately I've been shopping for a PS/2 or equivalent; it has something to do with this.

I am older than you and have gone through the same. Let me share a few thoughts. I am not trying to change your mind, just riffing.

Thought #1: You don't have to use technology. I have a laptop, but I do not use much software aside from what's required to interact with people and do my work. I have some other technology in my house, such as various home-built robots, but they are only used when I am actively working.

Thought #2: There is still a lot of software that is making the world a better place. My mother was in a serious car accident and never really got her mobility back. I am not a fan of car culture, but it's the world we live in. ADAS systems are saving people from life-altering car accidents every day.

Thought #3: There is a lot of very positive technology that is totally impossible without software. Genetics is the elephant in the room, of course, since basically everything about the field is totally impossible without good software. But basically every natural science is similar at this point. Even ecology.

Thought #4 is about this quote:

> If the internet weren't responsible for my coming out I'd say burn it all down.

Even with marriage equality and other progress, I do not think the modern transgender rights movement would have been at all possible without the internet.

My final thought is a different perspective on the final thought of the essay:

> No one knows what they’re doing, and it’s a civilizational problem.

There is a lot of essential complexity that we absolutely need in order to make the world a better place -- in biotechnology, energy, and materials in particular. Without modern information retrieval systems, I think our civilization would stop making progress and rapidly collapse.

> Even with marriage equality and other progress, I do not think the modern transgender rights movement would have been at all possible without the internet.

This is what kills me, because it's absolutely right. I'm trans and my people are all I have. I would love to have just a dumbphone, but being alone again, searching desperately for anyone who gets it, whom I can see and know knows me --- that is soul-rendingly painful. We are a diaspora connected by wires and lights on a screen. The knowledge that I'm not alone, I'm not crazy, I'm not broken saved my life. I can't go back now.

We should totally have nice things. I hundred percent agree. But I have this nightmare that one day a cloud provider goes bankrupt because they can't understand why half their fleet won't boot. And as the go through the entire process, from the initial PXE boot to the full boot and so on, there are just too many ways things can break. They fix one 'issue' only to realize it wasn't the issue. Then the next, issue, and so on, but not coming up for days.

And the issue might even be completely out of their control in the proprietary, CPU vendor supplied blob, or the network OEM supplied blob, or the storage supplied blob, or the TPM blob, or the way they rolled certs (because everyone screws that up at some point), etc. etc. And the complexity isn't essential. It's a byproduct of short-term choices, compromises, lowest common denominator thinking, and a lack of risk taking on new approaches to the problem. This leads to systems we cannot reason over. Companies like 0xide computer are taking a stab at these kinds of problems.

I do not have this worry about the biggest cloud providers, actually. I do have this worry about basically everything outside of the IT sector -- particularly the industrial and agricultural sectors.

I 100% agree with you when it comes to software meant for me. But there's a lot of software that doesn't exist for people who can't prop up capital like we can.

Where I live, you have to pay a lawyer something like $1,200 to clear an old arrest off your record and good luck affording that if you can't get a job or housing because of an arrest that happened a decade ago. I'm currently working to automate as much of the process as possible to bring the cost down to closer to what I think it should be ($0).

If you want to find things to program that are useful to someone, it might be worth your time to go looking for things.

https://brigade.codeforamerica.org/ This is one organization that's focused on that sort of thing. The local group in my area is more focused on data analysis, but maybe yours will be more up your alley.

Heh, as someone who moved around the world I'm relying on technology for half of that. I can only boardgame with my friends thanks to TTS (even those in my new country aren't meeting up in-person an the moment). And the selection of books available in my native languages would be very limited and expensive if ebooks weren't an option.

> I am 25.

I am very interested in your generation and the phenomenon of nascent tech rejection. I think it may be a great hope for us finally solving many problems in software engineering that are more to do with culture and society than bits and bytes.

There's a famous Douglas Adams witticism:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.

He was absolutely spot-on for my generation. But this doesn't hold any longer, and I've been pondering why.

I think my generation saw tech as a hope, as rebellious and progressive, and exciting from the get-go. We were raised on mostly optimistic sci-fi and ideas of space exploration etc.

Today, kids are born into a world where tech represents a threat. It's systems of control and stuff that makes their parents unavailable, frustrated and sick. They inutially accept that until reaching teens when they become rebellious and independent thinkers who reject that way of suffering and subjugation.

Am I close to the mark?

I was very bullish on tech for a long time. What turned me off was the bad patterns that crop up all over social networks (see Twitter/Facebook culture in re: performative activism) and, more than anything, actually writing code in the year 202X.

An awful lot of this seems spot on to me. The final point (from Wirth) seems the weakest - we do build many systems whose multiple layers no one person cam fully understand outside of the domain of computing. I don't see a great reason for computer tech to be that different. But that these systems are over complex, built on fragile layers of crumbling abstractions, and grossly inefficient, is hard to dispute.

What to do about it is another matter. There's a lot of momentum built in.

>The semiconductor guys don’t know much about computers

and you'd expect an opposite huh. Can anyone comment on how accurate this statement is?

Hopefully one day I'll finally get to the point of being able to design my own circuits.

This quote seems to be referring to 90s mainframe silicon, which absolutely had an architecture which didn’t match the current direction in software. They were built for batch-processing in COBOL when those same systems would soon be re-purposed to run Linux.

Modern x86_64 and ARM designers absolutely know a lot about computers, and the expectations of modern software. That’s why we see constant advancements in things like vector instructions, needed for video decoding and photo manipulation, and specific instructions to speed up random number generation and block cipher modes such as AES-GCM. Then, at a higher architectural level we have much better integrated memory controllers, protected memory implementations, and branch predictors than could ever be dreamed of in the 90s. The Intel Core architecture reigned in the cost of pipeline flushing, and led to a 15 year renaissance in efficiency, now being led by AMD’s Zen architecure.

There have of course been advancements as well in semiconductor physics and chemistry, such as Optical Pattern Correction and ridiculous advancements in DRAM dialectric efficiency that isn’t touched on anywhere here; and I would consider being able to physically manifest these near impossible artifacts of technology “knowing something about computers”

Modern x86_64 and ARM designers absolutely know a lot about computers, and the expectations of modern software. That’s why we see constant advancements in things like vector instructions...

Perhaps the designers know a lot, but Intel and AMD seem to have been driven by sales & marketing, not by knowledgeable designers. Look at the list of "features" being regularly added to Intel CPUs - and then look at how many have been depreciated or removed, and consider the large proportion that have never been widely used.

Don't waste those transistors - give me the simpler & cleaner architecture, and a little more cache.

Those mistakes are because their crystal ball about the future is cloudy, not because they don’t understand the present.

Don't be so hard on the mainframes. They're absolutely fantastic and they're one main job in life, executing transactions. And you can run the same binary, unmodified, from the original 1960's system 360 on today's Z series. That's what business love. Don't lose my money and don't make me re-write it. And while some Z series are running Linux, they're really there to run Z/OS, CICS, and those transaction workloads. You could move those workloads to Linux but you'd have to recompile them, but also re-create the entire DB2, CICS, VSAM, MQ infra on Linux. That's a great way to light piles of money on fire. And re-writing those programs in other languages can work, but is often a great way to light much larger piles of money on fire. And mainframes do have cool tricks up their sleeves like LPARS, and Sysplexes, and so on. But your comment wasn't really about the beauty that is the modern mainframe. But yes, the original 8086 was meant to look not unfamiliar to mainframe assembly (at some level).

I actually think they're talking about packing general compute cores into a super computer that would be better off having RTL specific to the task. Like AVX 512 (which Intel seems to be moving away from while AMD is embracing?). But that's kind of an early 2000's view of super computers. They have been packing accelerators on them (notably graphics cards) to crank up the teraflops. Whether or not those were effectively exploited, or they actually got the performance, I don't know. In my work I've seen fewer customers head that way, but that's not the pool I swim in. Some machines added FPGAs to the mix. We use them on our custom network cards so we do more of the packet processing outside the kernel. But maybe the weather super-computer should have some RTL for Navier - Stokes (?) that's what I think the weather people use? Or maybe make a custom silicon just for super-computing with a whole bunch of AVX512 units? Or maybe a lot more on-chip separate instruction cache? Might not be useful for CoD or Java but awesome for SC. But I do agree with you their characterization of modern super computers is a little dated.

This article conflates the abundance of terrible software with the near absence of great software. The abundance of terrible software can easily be explained by the the growth of the sector which attracted many mediocre software engineers who just wanted a paycheck.

But why is good software nowhere to be found? There have never been more talented software engineers who are willing to work hard and want to write great software.

My best answer: systematic market failure. Good, reliable, carefully written software doesn't win. The best illustration I can think of is VSCode vs Sublime. Sublime Text is -- by any reasonable metric -- a great product. VSCode is slow and very buggy... but it's free and it has a plugin ecosystem that can't be beat. How can you compete with that? You can't. That's the quality problem in a nutshell.

Building up complexity is not so bad if you have the mindset that lets you have a fresh start, learning from all your mistakes and accomplishments.

That's why I started http://civboot.org. I want to take the best parts (those that best contribute to being able to understand the whole) of the modern technology stack and reducing them to a 100-1000 lines of easy to read code that build upon each other. Then I want to do the same things with hardware and mechanical engineering. We'll see what I can do with my life!

The Permacomputing folks are exploring some ideas for reducing computing complexity.

https://permacomputing.net/

> Programs used to be pipeable. Now, GUIs are killing pipes

Unix command line utilities were pipeable. Consumers never had use for IPC, most companies have way more important things to worry about

Exactly. Most of us write software for non-programmers.

Pipeable software is great for developers and computer scientists.

But for laypeople, they need a UI. They don't understand -- and don't want to understand -- the machinations behind the process. They have a business process and they want the software to model that business process.

And that business process is not going to be executable on a command line.

> Pipeable software is great for developers and computer scientists.

> But for laypeople, they need a UI.

Totally agreed with your points. Also, maybe I am completely out of touch, but there is nothing stopping people from using Unix utilities. The majority of my meaningful computing is done within a terminal emulator where the majority of my tooling is pipe-able. An example that also highlights this is Microsoft's work on PowerShell -- which is built to be used in complex pipelines (I think Microsoft is an interesting example because they have a history -- pre-2010 -- of being one of the biggest opponents to the Unix philosophy).

Where is this mentality in the original article coming from that pipe-able tooling is no longer an option for people who care about that? Am I just that out of touch in thinking that Unix/Unix-like tools are literally everywhere and building a command-line-focused/pipe-able ecosystem is better than it ever has been?

EDIT: some grammar and clarification on my points

> "(I think Microsoft is an interesting example because they have a history -- pre-2010 -- of being one of the biggest opponents to the Unix philosophy)"

Windows had system-wide IPC (OLE and COM/DCOM) since Windows 95 that Linux doesn't have today, and which I suspect Linux users don't even know they're missing. You want a spreadsheet in a word document, you could drag it in there and Excel as a component would appear inside Word. You want to extract JPG metadata in your VBScript, call WScript.Shell and lean on Explorer to do it. Array calculations? Automate the 3rd party J engine. Voice recognition in Python with PyWin32? Instantiate SAPI.SPVoice. System wide task/specialty-focused components not like installing a node.js library, but available to any language or any program which speaks the same interfaces.

It isn't /piping/ but it isn't everything-reimplements-the-world either.

> "An example that also highlights this is Microsoft's work on PowerShell -- which is built to be used in complex pipelines"

And sadly you have to drop away from the pipelines to fuse operations together to get decent performance.

    Get-ChildItem C:\Windows | Where-Object Name -like '*.dll'
    gci c:\windows |? Name -li *.dll

will not be as fast as

    Get-ChildItem c:\windows -Filter *.dll

because the first one has to generate pipeline data for every file only to filter most of them out, the second one can generate only the data which is needed in the first place. And this problem of fusing operations to avoid wasting resources is endemic to pipelines, not only to PowerShell - see Unix shells serialising everything to text at the output of a command only to parse it from text at the input to the next command, or how commands gain ever more options to do with filtering and processing, summarising and formatting, which aren't anything to do with the "one thing" they allegedly do.

I think your points are well articulated and educational to me as I am admittedly one of those Linux users that doesn't fully grasp/appreciate the cohesive nature of the system-wide IPC you are describing (even if I was on Windows I would still just stay in the terminal for most of my applications).

> sadly you have to drop away from the pipelines to fuse operations to get decent performance

I used PowerShell as an example because it's currently an important part of the Windows ecosystem and works very well with piping. In my experience using PowerShell (on Linux) as my daily driver I haven't noticed performance losses in using pipelines. That being said, maybe I'm losing more resources by not optimizing every command I run, but so far I am pretty happy using PowerShell while heavily using pipelines.

COM as far as I used it was always this incredibly opaque thing that no one understood. The only good thing is that you could generate C# code in visual studio for it, but the generated stuff is barely understandable and versioning with COM is another big issue.

> "The only good thing"

The good thing is that in dynamic languages (VBScript, Python, PowerShell) you can instantiate COM objects and call their methods in a couple of lines. I have never held the "oh but COM is badly designed and complicated inside" complaint in high regard, because the alternatives are either: it should be easy for programmers and if it's hard for users who cares, which is worse, or if it's not easy for programmers it shouldn't exist at all, which is also worse.

GUIs aren't inherently incompatible with composable data. Sharing in iOS and Android is an extremely rudimentary version of such. Then there was OLE in Windows (mentioned in another comment here) and Apple's OpenDoc (controversially canned by Steve Jobs).

It's a harder task to specify than just piping text, and the period of corporate/consumer computer history GUIs have come to maturity in has made it less likely to happen. Which is a shame. With a modicum of luck and the right standards and incentives, marvellously useful tools for active humans could have come about. It seems unlikely to happen now. Most computers are essentially training clickers for passive consumers.

There's no reason why we couldn't come up with a nice GUI than piped output.

I don't think the problem is GUI specifically - the problem is poor/no provision for automation. Our widely used apps either discourage (by making it difficult), or just do not enable, anything other than manual actions.

Take the MS Office suite, for example. The entire suite is built round highly manual operations - the common operations are provided and triggered manually. But if it's not provided, good luck. Just say, you want to print your document with the odd pages rotated ... it's not going to be easy ... perhaps print to a pdf, then use an external editor to MANUALLY rotate each odd page! Or print odds and evens, then MANUALLY interleave the pages. It can be done, but we're encouraged to do it manually and mechanically :(

For virtually any issue you have with Office the answer is to find the Python module for the document format and write a quick script. Then, instead of some arcane shell monstrosity that’s easier to rewrite than edit, you have a script whose function is obvious and testable.

Rinse and repeat for all of the actual examples people come up with for how pipelines are better. They’re not magic, they’re just a tool.

https://www.geeksforgeeks.org/working-with-page-orientations...

In the old days Office came with a macro recorder that you could use for that kind of thing.

I watched GPT solve a leetcode the other day with excellent comment annotations. Wondering how AI refactoring might fit into cleaning up sloppy codebases... Seems like something I should have already thought to try...

Also haven't compilers continued to get better? Legitimately curious. I guess I always assumed they had been and that it was important. Realizing I don't really know...

Nobody understands computers in their entirety but someone understands each part individually. It's just division of labor in action. And it seems to work. Software hasn't really gotten any slower in the last few years, and SSDs made it fast enough again.

Software isn't piplinable because we don't write software to process data as much anymore. We write software to interact with people and the world. The pipeline model doesn't apply, we need things like the if this then that model or extension APIs.

Which, admittedly, we are not great at, if it was up to me a standardized IFTT-like interface would be a core feature on every platform and it would be easy for apps to expose blocks.

I'm pretty happy with most of the software world at the moment, even though I have issues with tech culture and some of what tech is being used for.

You know what? I don't care any more. I gave up on "modern" computing and just tinker on plan 9. I don't care about Windows 8/10/11. I don't care about Linux or what DE to run this week. I don't and have never owned a Mac. I don't care if BSD is dying. I just want an ecosystem that lets me tie things together seamlessly using simple protocols and API's which is what plan 9 delivers in spades.

Do what you want. Write all the Rust, JS, Zig, Python, Go whatever on your container vomiting abomination. I'll be in the corner enjoying my life.

[Computers and applications] operate in an invisible ether and live out there on some distant, mysterious Mount Olympus — better known to us as a data center. Their mercurial whims dictate our moods and our fortunes. We plead with them, but have no idea if they are listening.

I don't disagree that a lot of people think this way, but it rarely is the case. I always try to use this confusion as a teachable moment: "this is how you do this, and this is how I figured it out". People don't necessarily want to learn, though.

Computers and what we're doing with them have come way farther than it was ever dreamt of or as we could have ever expected. At this point, innovation is seldom about the technology anymore, but about an opportunity for doing business. Maybe time to lean back and to reconsolidate. Maybe also time to reconsider for a moment. Because, on the way, we may also have lost a few things that may be worth picking up. Compare Bret Victor. (Could we still pick up these threads?)

Sometimes, side view give extremely valuable insights.

Unfortunately, see huge mistakes, non understanding whole engineering community principles.

Most important - purpose - whole industry (not just computers), from 19 century working to deliver cheap goods, achievable to all people.

And to do things cheap, must do some significant simplifications, this is direct answer to points 1, 2, 4, 6, 7.

So simple answer - figure out, how to solve issues you critic, and lead movement for this target.

For other q's, will answer later.

Sources to read about current industry paradigm (will add when remember additional):

My Life and Work by Samuel Crowther and Henry Ford https://www.gutenberg.org/ebooks/7213

https://en.wikipedia.org/wiki/Six_Sigma

My solution to this is to take a well documented architecture I could potentially fully understand, use an FPGA to implement it, and jettison all of modern computing.

It's part retrocomputing, part recognition that what we have is actually not great and I'm tired of it.

Is this a viable path? No idea. I'm just tired of modern garbage.

Are you talking about actually doing that? I ask because that's more-or-less what I'd like to do, using Wirth's Project Oberon.

I'm literally looking for other people with the same dysfunction if you want to talk.

I took a look at Wirth's FPGA Project Oberon, but HDMI I think is simple enough to include. I think compatibility with modern C is a necessity, just because of the wealth that you can pull from at that point; I think it would be too difficult to program a C compiler for Wirth's RISC5 processor, but perhaps I'm wrong.

I'm pretty sure there's already a C compiler for it. :) Anyway, I've got the dysfunction, I just added an email address to my profile if you want to contact me.

Cheers!

> "No one knows what they’re doing, and it’s a civilizational problem."

This last bullet point unintentionally describes the root cause and settles all the article's complaints.

How? Because this is plain factually incorrect. Just like how it works for the rest of civilization, someone does (or did) indeed know what the computer is doing for any given component within any layer of code. Complaining about computers in this way is exactly the same as complaining about the inefficiencies of government or other large organizations.

What's changed is how much every aspect of the software must have "moving parts" so to speak. The most efficient solution is not necessarily the best solution anymore now that so many people from non-technical backgrounds are stakeholders in software development.

Hardware improvements have allowed for far more complex software and greater speed has indeed been achieved where it counts (the lower level operations). Just because a GUI is slow doesn't mean the underlying system is slow. A user's perspective is inherently biased, selfish, and inaccurate. The sheer scale at which we deploy software today has a cost too and it's more important than perceived (in)efficiency despite being less glamorous.

> someone does (or did) indeed know what the computer is doing for any given component within any layer of code.

It’s not unusual that code isn’t quite doing what its author thinks it’s doing. Secondly, the “did know” is important. The detailed comprehension of what some code is (supposed to be) doing tends to fade quicker than we would like, and intent often goes undocumented.

The cost of maintaining undocumented and/or poorly written code is far lower than maintaining the physical infrastructure the code may have replaced though.

It's great that the industry still has enthusiasm to always improve, but this is not a technical problem. What we are experiencing are organizational problems. Not to kick a hornet's nest, but the flip side of this problem is so many software devs not wanting to work in management.

My perception is that new code gets written at a much faster pace than existing code has any chance to keep getting maintained. There is incredible churn.

The other issue is that almost everything is built on leaky abstractions and underlying software components with inherent design problems, that are hard to reason about, and which remain unfixed because of backwards compatibility and/or because no one understands the code anymore.

Moreover, almost every time you want to fix something, you run into issues in the next lower level of the software stack that you have to work around, or just resign to gloss over.

I agree that it’s a management problem in terms of priorities, but the technical problems are very real.

> Complaining about computers in this way is exactly the same as complaining about the inefficiencies of government or other large organizations.

And those would be valid complaints, no?

You seem to be defending the system as-is, as inevitable, and dismissing ambitions about the world as it could be as if they were the words of dreamers, and ungrateful idealogues.

One should not use our current dependency on broken systems as a self justification. That's unfalsifiable, as we don't get a null hypothesis re-run the history of computing where we made better decisions.

I think the article is spot-on as an observation. And the last remark about it being an intrinsic "civilisational" problem, while seeming whiney, should not be dismissed if we are serious about solving many of the problems that technology has created as the price for progress.

To simply accept it as an immutable feature is defeatist. We have to believe there are are better technologies than those which mirror the failings of big organisational inefficiency.

> You seem to be defending the system as-is, as inevitable, and dismissing ambitions about the world as it could be as if they were the words of dreamers, and ungrateful idealogues.

That’s not how I read what they wrote. I read it as, “we got here because people voted with their wallets/feet/attention/time to get us here. We have inefficient government, etc. for the same reasons. The ‘problem’, if there is one, is that we have a lot of competing, sometimes contradictory, desires and no clear winner. It evolved this way.”

I didn’t feel they were saying it’s inevitable or unchangeable, just that it happened because that’s how a bunch of different people reacted to the situation. If they had acted differently, we’d be somewhere else.

I'm really glad you wrote that.

I read the OP again, and didn't see any different.

But what I did see is the distortion in my own lenses. There's some _reason_ I can't read the OP differently, and it's about my stuff. Thanks for shining a different light on it.

Excellent! Couldn't have said it better myself.

I'm starting a new stack (based, as it happens, on Prof Wirth's Oberon RISC chip) and network. Let me know if you're interested. I don't know how to save the masses, but I think we can save the folks who want to be saved. (Email in profile.)

Looks like it's been hugged to death...

Points 1 and 6 seem to contradict.

I've read the article: I'm more furious at the author's handwavy criticisms than anything else.

Going down point by point:

> 1. Good hardware is masking really bad software.

This point assumes that there isn't any other reason other than "developer laziness" that bad software exists. It glosses over the fact that "wasteful" development practices are often hoisted onto developers due to the need(s) of:

- Making the software grokkable/comprehensible for new/incoming developers

- Ease of software maintenance (related to earlier point)

- Limiting failure states of the software in question (related to earlier point)

- Time constraints & mandated requirements from 3rd parties (often business/legal people that focus on "get it done", rather than the necessity of such constraints/requirements in the first place)

------

> 2. All the bad code is piling up, and we don’t know how to get rid of it.

The author failed to mention that the edge cases encountered in the wild & the additional complexity needed to accommodate them are often the main reasons for such "bad code" existing in the first case. The aforementioned edge cases, along with the time constraints & mandated requirements, are what lead to "bad code", along with feverent disapproval of its removal due to <insert edge case/legal requirement/business case here>.

------

> 3. Programs used to be pipeable. Now, GUIs are killing pipes.

This is in large part due to the unwillingness of (a whole lot of) non-developers to learn how to use pipeable tools in question, instead hoisting it back onto developers to "give me something that *I* can work with". This is fundamentally a social issue that hasn't been addressed at all, in that the increased self-voluntary infantilization of the general public is inducing demand for GUIs.

There are definitely non-developers that decry this trend of simpler-&-worse GUIs, but the silent majority have altogether said that "this is fine", and that they're willing to be coddled in order to obtain the luxuries that they desire, even if it induces further infantilization.

------

> 4. Computers are telling me what to do, but I can’t tell them what to do.

This is again related to (3), and the self-infantilization that a lot of people are willing to undergo for the sake of convenience. It also exposes the author's unwillingness to take the necessary steps in order to perform the self-customization that they so desire.

This point also glosses over the reality that as the number of possible configurations increases, the number of possible failure states grows at least linearly at the same pace, with said failure states often growing at a multiplicative pace in proportion to the number of possible permutative states of configuration. Is it no wonder that in an effort to decrease the surface area of failure states, that said configurations are walled off in favor of funneling everyone towards the default?

------

> 5. Software is not technology. It is ideology.

The quote that the point entirely uses rests on 2 points:

1) Hollywood's system, when compared against software development, has someone assuming directive control, whereas software doesn't have such a person.

2) There's an equivalency whereby (interactive software == movies)

(1) does exist in modern software development, with the list of requirements & general architecture drawn up by product owners & lead developers respectively, with overall development handled by the rest of the development team.

(2) is false due to the fact that whereas movies only need to showcase 1 linear series of synchronized video & audio, interactive software has to account for all possible interactions with the software itself. A more proper analogy that could be drawn would be choose-your-own-adventure novels, from which interactive text-based games were partially derived from. Even so, said novels do not have to deal with malformed inputs, & the choices given by the novel do not need to internally carry state.

------

> 6. Computers are fast, but in the dumbest way possible.

The point in question is potentially performing a lie via omission, in that the author left out the rest of the interview that they were quoting from. (http://worrydream.com/refs/Mead%20-%20Gene%20Youngblood%20In...)

(Side note: The interview in question, even if there is no concrete date for the interview, can de dated to the early-to-mid 80s, due to the interview's usage of terms like floppy disks (pg. 18), the Intel 286 processor (pg. 5), & the 1.5um silicon manufacturing processes (pg. 4). Since then, SIMD, GPGPU programming, and compiler-derived vectorizations & optimizations have allowed for further performance improvements, on top of the increased CPU performance that has accrued since then.)

In said interview, Carver lays out that the 10000x solution being touted are none other than FPGAs & ASICs:

|> GENE: What do you call the kind of architecture you're talking about?

|> CARVER: I call them silicon algorithms. You just map the application right into silicon. And the technology for doing that we understand pretty well. I don't mean we've worked it all out. But we've developed the technology for taking high-level descriptions and putting them on silicon. It's called silicon compilation, which is the obvious next step. You need to compile things right down into the chip instead of compiling them into some code that you feed to this giant mass of chips that grinds away on it trying to interpret it.

|> GENE: So the silicon compiler solves not only the complexity problem but also the problem of massively parallel architectures by allowing us to experiment with the dedicated hardware that alone can realize the full potential of that architecture.

|> CARVER: You bet. Otherwise there's no hope. Because then you're stuck. If it takes five years to design a chip nobody's going to experiment with algorithms in silicon, right? Because it takes years to get any place. And that's in series with your learning curve. So you have to have a technology for experimenting with designs in silicon more rapidly than that.

Ironically, the inability to customize, which was lamented in (4), are further compounded by the crystallization of algorithms into "silicon algorithms", whether via FPGAs or ASICs: The algorithm in question becomes much harder to modify as it descends downwards from general software into silicon gates, with any bugs/mistakes requiring much larger efforts to fix them.

------

> 7. No one knows what they’re doing, and it’s a civilizational problem.

The entire point rests on the axiom that unless everything with a system can be understood by a single person, said system shouldn't be built.

This is nothing short of a "complex == bad" type of thinking, wherein in order for something to exist, everything from top to bottom has to be understandable to a single person. Leaving aside the fact that the same sort of thinking can be applied towards everything else in modern society (modern plumbing & electrical systems, cars/planes/trucks/<insert transport here>, legal/tax laws, institutions/bureaucracies, economics, geopolitics, modern medicine, etc.) & that there's no sort of alarmism from the author applied to said things/systems, the author fails to recognize the fact that the distribution of responsibilities is the foundation of modern civilization, and that the resulting specializations & improvements made towards each component of the entire system results in a system that is overall better off than if everyone w forced to build everything themselves.

There are definitely some technical debts that can be removed from each part of the overall system, but to say that everything more complex than what can fit in one person's head should be barred from existence is a exceedingly prescriptive way to view how the author's ideal society should function.

------

All in all, the author has not realized that they've willingly allowed themself to undergo software infantilization, nor have they (at least publicly) done any steps towards weaning themselves off from the process itself, *WHILST* having the gall to complain to the world about how "everything about computers now = bad". They've not publicly shown any willingness to at least take the bare minimum in software self-discovery in the first place.

Just remember that this has been coming down the pike for much longer than consumers had computers in our households. Even if we'd never picked up Atari 2600s at Sears by the truckload, even if we'd never hauled home VIC-20 and C-64 and Apple ][ systems, this would've been foisted on us. Because Corporate America moved to the cloud before we did. Corporate America was on the Internet before consumers were. Corporate America were all early adopters, right after the Department of Defense and military branches adopted it all too. And in-between that was the R&E sector, that is, universities, think tanks, etc.

There used to be a high-traffic mailing list called "com-priv". It was about the commercialization and privatiztion of the Internet. This was, of course, a foregone conclusion, no matter how much the little guy fought back. The Internet was designed from the ground up to take over business, because that's where it was born and suckled until it was mature enough.

Yes. I worry very much that the internet will lose it's end user utility and become something that is simply infrastructure for deploying and operating commercial products and services. We are far along the path, but the story isn't over yet. The internet can still be saved for users.

I really like that blog layout. Nice images, good layout. Dense!

On the article and all her points: I guess the best we can do is pray to the computing gods that everything works out!

Everything is working out fantastic for computers. It should not be lost on anyone, that yes, javascript sucks, however I have a rectangle in my pocket with all the information that's every been written (to a large extent) accessible. Whilst I choose to use it for meme's that's more my failing than the computers.

Computers do a hell of a lot these days that goes unoticed. Like multi threading. Background tasks, richer more complex styles. Sure computers 30 years ago where fast, but they didn't really have color screens.

The architecture complaints seem out of place as well. RISC, CISC and then CSIC on RISC, there's change in the architecture space as well.

I don't think the author is considering the timelines that exists. It's been a pretty productive 100 years of computing.

Reply on news.ycombinator.com