There is only one OS, and it’s been obsolete for decades

In the first situation, you start going through the sources and see all the oddities, areas with questionable functionality, outdated techniques, and places where there must be better ways to implement a solution than the crazy spaghetti code you're looking at. Many inexperienced developers think, "Trying to figure this all out is a waste of time... I could write the whole thing from scratch faster than modifying this monstrosity."

Then there are those developers who have created said projects and understand the reasons behind all the craziness under the covers. Like a battle plan, no software project encounters the real world unscathed and unchanged: Edge cases pop up, bugs in other systems need to be worked around, features outside the original scope were added, limitations of current hardware or libraries needed to be accounted for, etc.

This article is written from the perspective of the former: "God, what a mess! What is all this crap?? Text files and consoles and all this other junk is horrible!" The fact is that every piece of software is filled with this stuff, down through every layer in the stack, and that's never going to change until humans are no longer involved in the process. If you sent this article to Linus Torvalds, he'd read about four lines, realize the author doesn't know what he doesn't know and dismiss it all out of hand.

Wait, what?

Linux and macOS, OK, sure, they are based in varying degrees on Unix. But Windows? Windows has no appreciable Unix heritage. The DEC roots of the people Microsoft hired to develop Windows NT mean that modern Windows has some similarities to systems like VMS, but VMS isn't Unix and never was.

> Oh, wait a minute, this is still the only way we can get anything done in the world of programming! Typing textual orders into a “terminal” or “console” application—nothing more than an emulator for the teletype!!

On Windows? What?

> 3. “Everything is a file”

...

> 4. An obsession with unstructured text

The only thing I can figure here is that the author is familiar with Macs and Linux, where these assertions are all true, and is just assuming that they must therefore be true on Windows as well. Where they very much are not.

Windows has had some convenience features layered on top of it to make it more comfortable for people familiar with Unix to use, but deep down in its lizard brain it is very much not Unix and was built around a completely different set of assumptions. Windows doesn't assume everything is a file, interprocess communication in Windows has never been about piping text between processes, Windows has been GUI-first rather than terminal-first from Day Zero, et cetera et cetera et cetera. It's just a completely different thing than Unix and Unix-derived systems like Linux and macOS.

One can argue that this is a strategic weakness for Microsoft, as the world (especially among developers) has more or less settled on Unix as the One True Way to Write an Operating System, and thus the more different Windows is from Unix the harder it becomes for them to sell Windows to people. But listing all the legacy baggage that Unix-derived systems haul around with them and then saying "oh yeah, Windows has all that junk too" is just incorrect on a fundamental level. Windows carts around plenty of legacy baggage of its own, but none of it has much to do with teletypes or text pipes.

> All of these are built around the same foundational concepts, those of Unix.

> Android sits atop the Linux kernel, with iOS (as well as Mac OS) atop Darwin (dunno about Windows Phone, but it doesn’t matter). Linux and Darwin are both descendants of Unix. Windows also bears many similarities to Unix, possibly through it, but whether there is a dependency does not affect the point. To me, the key effects of this monopoly are as follows.

And we're done here. Thanks for playing, close the door on the way out.

A language is not unstructured text, then it would not be called a language.

Seems like a article full of complaints(that is already well-known to be not the ideal thing) and propose no alternatives.

C succeeded in part because, in many problem spaces, it was easier to write "portable assembly" than it was to bridge the semantic gap between higher languages, like LISP, and typical ISAs.

All of this Bret Victor cultistry is a grandchild of B5000 design. Want better software, need better hardware.

Maybe with the end of Moore's Law, we'll start making better hardware...

I feel if he acknowledge these tools some of his arguments fall flat.

There a reason why there is no real alternative to TUI's. Because all of them suck. Even Microsoft back-peddled with powershell so that Windows have better tui support.

I want to use TUI tools like ssh and tmux. For the power it gives me, and the low usage of bandwidth, that gives a better response time then most GUI tools.

"UNIX is very simple, it just needs a genius to understand its simplicity." ~ Dennis Ritchie

Graphical user interfaces bypass some of those issues with direct manipulation but I don't think people have an easy time learning how to use complex GUI applications. Before the smartphone I remember 1000 page books about how to use Microsoft Word and lately graphic designers are starting to realize that "It's not just me, Photoshop really is hard to use."

The big difference between computers and humans is that computers tend to require you to formulate inputs in a specific way and that they don't tolerate ambiguity. Early programming languages such as COBOL and Perl had highly complex grammars that most developers today have an aversion to. (For instance almost everybody things that "unless" and "ACTION if CONDITION" in Perl is stupid; even though natural languages are that way.)

Closely related to that is the "namespace problem" which boils down to an inability to create a unique meaningful name for every concept (ex. function, variable name, file, ...) that somebody might want to refer to. People let you use ambiguous words and will usually guess what you mean correctly, if they aren't sure they usually know they aren't sure and will ask clarifying questions.

The trouble w/ making programs that can do that is now you are dealing with something that doesn't necessarily have a right answer or we don't know what it is. My experience is that (despite what many of bosses have thought) it can be a lot harder to make something that has to be 99.9% right as opposed to 100% because you might find that there is some 0.001% case where you think you can tolerate an error but no... If you work out the math for something to where you can define what correct is, it might take a while to think through and implement but the task is finite. On the other hand there is no limit to how much time you can spend screwing around and going in circles.

The two will combine to create the paradigm we look at the next new thing.

You can propose your replacements, we can shed our vistigal features. No matter how much things change, it’s impossible to make a clean break.

- https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook

Simplicity is a positive virtue, not just a negative one. Having everything be 'just files', or compile to something that is C or C-like, and having an API that is still mostly usable on an actual TTY, are actually great, wondrous things to programmers dealing with cognitive load. Aside from projects that are essentially refinements of Unix -- Plan 9 and Fuchsia, for example -- I haven't seen anything that provides remotely as powerful an idiom. But then again, I haven't been looking. Because Unix already meets my needs just fine. It is Good Enough.

Yet there has been no shortage of attempts to do better, and they were almost all unanimously terrible. Remember how much fun it was locking handles in MacOS 7, before you could reliably play with stuff on the heap? Yeah, you probably don't. But I do. It sucked. But TBTB told us Pascal and 'cooperative multitasking' (ha!) were in; that it was gauche to touch a terminal; and that the future was remote procedure calls. Shortly thereafter, the future was OLE, or maybe CORBA, or maybe the JVM. It didn't really matter what the future actually was -- the message was always, 'C is dead, UNIX is dead, long live ____'. And here I am, unironically typing you this message on El Capitan, atop a Unix kernel, with about five terms behind the browser window, in the year of our lord 2018.

What is dead can never die. :)

Thus I'd argue that unix, and all its anachronisms, comprise the little black dress of informatics -- always in fashion.

I'd argue that is in fact deeper than that; it's an ideology; specifically, it is what I would call 'anarchist', but you might call 'decentralist' or even 'libertarian'.

Either way, I'm keeping it. I'm probably still more in love with Unix than I will ever be with any human.

P.S. also Vim called and reminded you visit Eclipse in the Old Prog's home.