The question of why text user interfaces are difficult is an interesting one, but I think boils down to "Why can't you have a conversation with a computer like you do with a person?"
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 aspects of Perl you mention are trivial bits of syntactic sugar, that don't add significantly to complexity and don't prevent you from using the idiom other languages do. Saying "everybody" thinks they are stupid is begging the question as much as if you dismissed the ternary operator that way.
Also, Perl and COBOL originated almost 30 years apart, so grouping them together as "early" languages is peculiar. If Perl is "early", then are C, C++, and Java also?
Urbit currently runs on top of Unix, so yeah that repository will be mostly C. If you look up the project on its website, you'll see it runs in three new languages that solve the problems the author talks about.
There are two common situations for developers: Encountering a software project for the first time, and the opposite, developing a project from scratch and then maintaining it.
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.
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...
> Consider the three operating system families we are forced to choose from: Windows, Apple, Other (which I shall refer to as “Linux” despite it technically being more specific).
> 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.
Yeah he dismissed Windows way too easily, but some of his later points still hold for Windows. The terminal still sucks (though Powershell at least tries to modernise it a bit). It still uses processes and files in basically the same way Unix does. The most common interface between programs is still the C ABI.
It doesn't have the obsession with unstructure text, which is nice.
It is a mistake to call it "the terminal". Consoles are not terminals.
It is a regular thing for Linux/Unix people to talk about making a "better terminal". The irony of your talking about Windows in terms of "the terminal", is that pretty much all of the ideas that people put forward for making a "better terminal" have actually been done, decades since, in the worlds of MS/PC/DR-DOS, OS/2, and Windows NT. OS/2 version 1.0 had the MOU, KBD, and VIO subsystems, which introduced device independent input event streams, 2D screen buffer addressing, a handle-based API, and API calls rather than escape and control sequences. Windows NT took this further into the Win32 concept of a console.
And the most common interface between programs has never actually been the C ABI, not on DOS, not on OS/2, nor on Win32/Win64. The most commonly used convention has to be the one used by applications softwares to make system calls. Thus the most common calling convention on 16-bit OS/2 and Win16 was in fact the (Microsoft) Pascal calling convention. 32-bit OS/2 and Win32 used different calling conventions, APIENTRY and WINAPI, that still weren't the ones used by plain C functions unadorned with calling convention specifiers.
The preëminence of the Unix Way did not arise in a vacuum. It arose by Unix winning out, again and again, against better-funded, more 'modern' solutions, each of which has aged a lot less well than Unix itself.
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.
'The powers that be'. Even the abbreviations we use these days are different. :) Younger people don't understand me when I say 'IANAL' or even 'IIRC', which is a shame, IMHO.
Hot grits and Natalie Portman forever. flashes Slashdot gangsign
I don't see that locking handles in Mac OS has any relevance to the merits of Unix. That was just part of dealing with relocatable memory without an MMU.
> Consider the three operating system families we are forced to choose from: Windows, Apple, Other (which I shall refer to as “Linux” despite it technically being more specific). All of these are built around the same foundational concepts, those of Unix.
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.
The author got a number of things wrong, but the thing that has surprised you is one of the few that xe actually got right. The handle-based API and subdirectories, introduced in MS-DOS version 2, were both Unix concepts added to MS-DOS that remained in DOS+Windows and in its successors OS/2 and Windows NT. (This wasn't the only Unix concept to cross to the IBM+Microsoft world. 32-bit OS/2 even changed to keeping system time the same way that Unix did, with a 64-bit count of seconds since the Epoch.) Command pipelines were right there in MS-DOS 2, as well. Peter Norton wrote a chapter about them in his MS-DOS and PC-DOS Users Guide in 1984.
Ironically, the thing that you have got wrong, in your turn, is your assertion that "an obsession with unstructured text" is actually true of MacOS and Linux in the first place. Most textual data files in such operating systems are in fact structured into records and fields; many data files (especially on the BSDs with termcap, the account database, and various others being Berkeley DB files) are not text at all; and there has been one particular database (the login database) that has not been text since 1BSD and Research Unix version 7.
Why does his teletype comments miss TUI tools like tmux, vim, midnight commander?
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
gui doesn't necessarily mean you have to update bitmaps over network to be responsive. It could be done in a protocol(just like ssh is) for low bandwidth/latency usage.
That was X11. A minimal but extensible protocol which survived many decades and successfully adapted through generations of hardware. Over time people created abstractions over it (Gtk,Qt,etc) such that X11 was limited to update bitmaps over network to be responsive. Now X11 will be replaced by Wayland on Linux.
30 comments
[ 1.7 ms ] story [ 84.9 ms ] threadGraphical 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.
Also, Perl and COBOL originated almost 30 years apart, so grouping them together as "early" languages is peculiar. If Perl is "early", then are C, C++, and Java also?
C was one of the first problems the author had in the blog post.
[0]: https://github.com/urbit/urbit
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.
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...
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.
> 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.
It doesn't have the obsession with unstructure text, which is nice.
It is a regular thing for Linux/Unix people to talk about making a "better terminal". The irony of your talking about Windows in terms of "the terminal", is that pretty much all of the ideas that people put forward for making a "better terminal" have actually been done, decades since, in the worlds of MS/PC/DR-DOS, OS/2, and Windows NT. OS/2 version 1.0 had the MOU, KBD, and VIO subsystems, which introduced device independent input event streams, 2D screen buffer addressing, a handle-based API, and API calls rather than escape and control sequences. Windows NT took this further into the Win32 concept of a console.
* http://jdebp.eu./FGA/tui-console-and-terminal-paradigms.html
Command-line interpreters are not terminals, either. Powershell doesn't modernize "the terminal".
* http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console....
And the most common interface between programs has never actually been the C ABI, not on DOS, not on OS/2, nor on Win32/Win64. The most commonly used convention has to be the one used by applications softwares to make system calls. Thus the most common calling convention on 16-bit OS/2 and Win16 was in fact the (Microsoft) Pascal calling convention. 32-bit OS/2 and Win32 used different calling conventions, APIENTRY and WINAPI, that still weren't the ones used by plain C functions unadorned with calling convention specifiers.
* http://jdebp.eu./FGA/function-calling-conventions.html
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.
Sorry I searched for "TBTB told us Pascal" and no real info popped up, except for some NSFW videos. What is TBTB?
Otherwise I agree with most of what you said; UNIX is dead, long live UNIX.
Hot grits and Natalie Portman forever. flashes Slashdot gangsign
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.
Ironically, the thing that you have got wrong, in your turn, is your assertion that "an obsession with unstructured text" is actually true of MacOS and Linux in the first place. Most textual data files in such operating systems are in fact structured into records and fields; many data files (especially on the BSDs with termcap, the account database, and various others being Berkeley DB files) are not text at all; and there has been one particular database (the login database) that has not been text since 1BSD and Research Unix version 7.
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
Only quick one I can think of as I wrote the question is winbox. But then again winbox is just a wrapper for the cli.
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.
- https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook