Explicating the survival of the Shell as default OSS UI



  • The subject of why most open-source software has a shell-based primary UI is something that comes up here from time to time (most by brought up by @blakeyrat), and why this is a Bad Thing (ditto), but there doesn't seem to be a clear idea of why this is the case. I think that a review of the issue is in order, explaining the reasons it is the case. I'm not intending to defend those reasons - several of them are genuinely bad - just to delineate them.

    • Because most OSS is for Unices. Note that I didn't say Linux, or MacOS, or FreeBSD, or even the specific implementations that are actual licensed versions of UNIX, but Unices in general. This has a major impact on the way code is written, because the Unix operating system doesn't have a user interface. Period. It simply doesn't. All user interaction is done by user-land programs, and this includes the shell. There is no common denominator between different Unix UIs except the present of some sort of shell, and even that isn't actually a part of the operating system. Since the shell - usually, but not always, some derivative of the original Bourne shell - is the only thing you can count on being present, it becomes the lowest common denominator for all OSS.

    • Portability. The commonality of shells goes beyond Unix, of course, and while the Windows PowerShell has little in common with BASH or tsch, it is similar enough that it is easier to write a minimal shell interface that will run on all common platforms than to re-implement a GUI for each system.

    • Because there is no really universal GUI toolkit that is satisfactory to all developers.

    • Because GUI programming is harder than CLI programming by at least an order of magnitude. While this is a very poor reason in and of itself, when combined with the need for portability and the lack of a universal GUI toolkit, it is a major barrier to development of quality user interfaces.

    I'm sure there are other issues that are at play as well, and I welcome any additional comments on this.



  • Because the people developing those programs are all already experts on CLI and see no reason why they should move away? Users should "just learn".



  • Hmm, how about the same complaints you guys have with Discourse: complexity.

    In short, shell is simple, GUI is hard. GUI is built on layers on top of layers of libraries and dependencies. There are hundreds of things that can go wrong. And they often do.

    Shell, on the other hand, can be implemented using the barest minimum of hardware and software resources. Someone just mentioned they got it working on a wristwatch. That's why it makes sense to have it running at the foundation of the OS. When the GUI breaks, this is where you go to fix things. That is true even for OS's that try very hard to hide the shell from end users, like Windows and Mac OS. It just makes sense.



  • Unfortunately, that kind of attitude is common among OSS developers. It isn't so much arrogance as it is laziness; they don't want to bother coming to the user, they want the user to come to them.

    The corollary to this is 'we can write the shell version first and then paste the GUI on top of it later'. Aside for the fact that this often makes for bad user design, all too often that step is ignored, or left to some other group to do. The corollary to this, in turn, is that 'we don't need an API, we've got the shell commands!'. This lack of a proper API for connecting a GUI up, as much as anything else, seems to be part of Blakeyrat's beef with tools like GIT.



  • Yeah, the cli is standardized. Let me just apt get, yum get, zypper get, aptitude, wget, curl. .

    No, we don't need your explanation of the cli. We've used Linux environments. They suck.

    Sometimes a necessary evil, but they are horrid when it comes to standardization.



  • This is a valid argument for the persistence of the shell itself, to be sure. Whether it is a good reason not to have an application-level GUI is another matter.

    I do have one more argument in favor of it, which I forgot to mention: expressiveness. There are things which can be done easily in a shell - especially if you have auto-repeat - which are cumbersome at best in a GUI. The solution, of course, is to allow the users to write scripts or record auto-action macros, but that too is something the user would need to learn to use, and unless it is built into the desktop manager, they would have to learn different ones for each and every application. Shell, for all it's weaknesses, is quite powerful (though in the shoot-your-own-foot-off sense, all too often).


  • FoxDev

    i believe the implication was that the CLI was standardized because it's gong to be there not because a certain set of tools will be installed. At least that's how I read it.

    I can log onto just about any linux machine out there and be guaranteed1 of only two things:

    • BASH or a derivative is installed and is probably my default shell
    • VI is installed

    1: no, not guaranteed, but extremely, extremely, extremely likely to be the case



  • @Matches said:

    No, we don't need your explanation of the cli. We've used Linux environments. They suck.

    You're missing the point. I'm not trying to defend the CLI; I am trying to get a grip on why it has persisted, and continues to be used as the default environment, so long after better solutions have existed.



  • Because better solutions don't exist. Every distro of Linux spends all their time recreating the desktop, not one spends it's time actually furthering new system features. New features that aren't fun to implement, but are required to progress.



  • @cartman82 said:

    In short, shell is simple, GUI is hard. GUI is built on layers on top of layers of libraries and dependencies. There are hundreds of things that can go wrong. And they often do.

    Even relatively simple GUI work (like a straight-forward, single-threaded MFC dialog app, which is an adequate model for many, many things that you'd otherwise do via CLI) is complex enough. Add in the complexities of multithreading, MDI, complicated accessibility interfaces, UI scripting integration (which is a far more complicated way to make a program automatable than scripting a CLI program), etc..., and you've got a real hairball on your hands. (Never mind that many OSes are designed in a way that makes it impossible to write a responsive GUI without threading, due to certain system calls not being available in a non-blocking or otherwise asynchronous form.)

    OTOH: the CLI and GUI worlds don't always play nicely with each other, especially in Windows (OS X and modern Linux DEs make much stronger efforts at this.)


  • Java Dev

    I think you've hit the nail on the head here. Particularly that a CLI interface is easier to write.

    I also find that for remote (= other continent) machines, the CLI is easier to use. But this may be because my usecase mainly involves editing files and compiling/running code. Vim is my preferred editor, and our end user interface is web-based.



  • I'm not talking about Linux. I'm talking about OSS software that runs on Linux... and OSX, Windows, and who knows what else. When I said 'better solution', I was talking about GUI applications in general, as opposed to CLI applications. It's got nothing to do with Linux specifically.



  • You do know that Powershell is a thing, right?



  • @cartman82 said:

    In short, shell is simple, GUI is hard. GUI is built on layers on top of layers of libraries and dependencies. There are hundreds of things that can go wrong. And they often do.

    A TTY layer is not a simple thing. Parsing and interpreting VT100 commands is hard. CLI programs work with strings, which are a pain to manipulate in C. There are multiple shells and commands which behave slightly differently.
    So no, I don’t consider the current state of CLI programming to be “simple”. A new CLI implementation, possibly using serialized objects instead of text for data exchange could probably work way better.

    I have never used a CLI to fix problems on OS X or Windows, mostly because the GUI always works. Of course, on Linux, having X not starting up can still happen, but it’s becoming rarer.



  • It only really applies to Linux. The shell is a raw, low resource, fast direct interface to apis that can be used for development and recovery. Osx and windows generally only expose these features for power users. Its faster to start run cmd ipconfig for your ip than navigate six screens to reach your destination in the networking center. Gui exist for pretty much everything in the commercial os space, but it doesn't remove cli utility.

    I actually had to use the windows boot disk command prompt to repair my server mbr just a few weeks back

    There's also a question of cost, 100k servers running just the cli environment, or 100k servers running just a fraction of that due to resources required by the gui.



  • @Arantor said:

    You do know that Powershell is a terrible, awful, mis-conceived thing, right?

    Yes.

    Yes, I do.


  • ♿ (Parody)

    @Arantor said:

    You do know that Powershell is a thing, right?

    It's not an OSS thing, though.


  • ♿ (Parody)

    @VinDuv said:

    So no, I don’t consider the current state of CLI programming to be “simple”. A new CLI implementation, possibly using serialized objects instead of text for data exchange could probably work way better.

    But it's still simpler than a GUI. You're not arguing that are you?



  • I know it's not. That's my point.

    Survival of the shell as a significant UI element, on the other hand, is certainly part of what this is about.

    I don't run a GUI on my Linux server. I could, and have done in the past, but I don't now. It's not because I can't, it's because it makes so much more sense for me not to run a GUI on it when everything I need to do I can do without a GUI.

    Same is true of Windows. I haven't played much with Powershell but even stuff I do on Windows I tend to do via the shell for anything other than very light copying of files just because I can do it faster there.

    That's why the shell continues to be useful: it's a GTFO your way approach to doing things.

    The only remaining question is why it remains so prevalent in OSS... and that's because, IMO, of two things. Firstly, the one-size-fits-all approach. App devs don't know if the user will have Qt or GTK or something else installed, let alone GNOME or KDE, so the lower the requirements, the more use is likely to be gotten. And secondly, the whole 'scratching my own back' mentality so prevalent in OSS; if they can build it, they are capable of using it and if that requirement is met, what else is needed?



  • @Arantor said:

    what else is needed?

    Quite a bit, actually.



  • Not from their point of view.

    That's the part so many people don't seem to realise. OSS starts with people scratching their own back. Once that's done, unless they have great vision or planning - and most of them don't - their role is done once it's publicly shared. If they choose to follow it up with feature requests and so on, that's great and all, but scratching one's own itch and being nice to share is always the primary motivation for starting any OSS project.


  • ♿ (Parody)

    C'mon, the button clickers know what's best for all of us.



  • @Matches said:

    Yeah, the cli is standardized. Let me just apt get, yum get, zypper get, aptitude, wget, curl. .

    No, we don't need your explanation of the cli. We've used Linux environments. They suck.

    Sometimes a necessary evil, but they are horrid when it comes to standardization.

    Common system commands tend to be standardized, such as ls, rm, tar, etc... Things specific to certain Linux distros (i.e. apt-get, yum, sypper, aptitude) won't be. curl is fairly newish (in Unix terms) and won't always be installed, although that's in-part because it's not a system tool



  • Like Jeff?


  • Discourse touched me in a no-no place

    @VinDuv said:

    I have never used a CLI to fix problems on OS X or Windows, mostly because the GUI always works.

    Well hooray for you. I have in both cases had to fix things from a CLI (usually when networking decides to really 💩 itself for some reason).

    The major difference between a CLI application and a GUI application to do the same task is that users expect to do things asynchronously with a GUI. What's more, the resources required to provide minor things like status updates, visualisations of the configuration, etc., all that takes just a lot more effort. When that effort is put in, you've got a a better application, sure, but for a lot of code it's hard to justify all that developer effort. Which is better: a tool that has just an ugly CLI but which took one person 2 weeks to code and 2 to debug, or a tool that has a GUI and which is pretty but which took a year to write and debug to the same quality, and that's a year with a several-person team (typically at least programmer, tester and artist; lots of programmers can't do shit for making things pretty 'cos they don't think like that). The answer depends on the number of users for the tool, and what sort of users they are (if your users are other developers, the right type of UI is not the same as if it is the massed grandmas of America).

    Platform-independent GUIs are possible. They're several orders of magnitude more difficult to do right than single-platform GUIs though, because you're much more constrained on what you can do as different platforms have different visual languages. This means that most cross-platform GUI apps end up sucking on at least one of their target platforms, and sometimes even on all of them. This is a particular issue if you're building apps that are cross-platform between Windows and OSX, which differ on “little” things like whether certain system dialogs are modal…



  • Fucking this. When I first tried using Linux as a is I had to drop down to the CLI to get shit to work. Nothing much has changed in 10 years. Yeah hardware support is much improved but that is about it.

    KDE has been rewritten twice since then and the only real difference is it does some GPU acceleration. Gnome has been scrapped and rewritten ... Sorry I mean completely fucking changed. The display manager is archaic.



  • @lucas said:

    Fucking this. When I first tried using Linux as a is I had to drop down to the CLI to get shit to work. Nothing much has changed in 10 years. Yeah hardware support is much improved but that is about it.

    KDE has been rewritten twice since then and the only real difference is it does some GPU acceleration. Gnome has been scrapped and rewritten ... Sorry I mean completely fucking changed. The display manager is archaic.

    One could argue that shitty GUIs are another part of the reason for CLI-based OSS. It' s a lousy reason, and one which shows a lack of interest in actually improving the GUIs, but it is there.



  • If they improved them over time as windows and osx has done in the same time period that wouldn't be the case. The fact is that the two major DEs threw away years worth of work and just started again.

    In 2003 both gnome and kde had a similarly rich experience as windows 2000/XP. Hardware support sucked but that wasn't the DEs fault.


  • ♿ (Parody)

    @lucas said:

    If they improved them over time as windows and osx has done in the same time period that wouldn't be the case. The fact is that the two major DEs threw away years worth of work and just started again.

    Yeah, but what about KDE and Gnome?



  • Very funny


  • Java Dev

    Does ncurses count as a GUI for the purposes of this thread?


  • BINNED

    Only if you're trying to troll @blakeyrat.



  • @lucas said:

    Fucking this. When I first tried using Linux as a is I had to drop down to the CLI to get shit to work. Nothing much has changed in 10 years. Yeah hardware support is much improved but that is about it.

    KDE has been rewritten twice since then and the only real difference is it does some GPU acceleration. Gnome has been scrapped and rewritten ... Sorry I mean completely fucking changed. The display manager is archaic.

    The display manager is archaic. At least devs finally realized that and decided to start writing replacements that ditches the 30-year old XWindows network-centric display system. One of the new ones is Wayland.

    http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

    First release of Wayland was two years ago.

    The OSS community being as it is, of course someone (in this case Canonical who makes Ubuntu) decided to do the same thing but differently:

    ...which has been delayed until 2016 last I heard (it was supposed to ship in Ubuntu 13.04 in April 2013). Meaning that Ubuntu and its derivatives are still using the old X Server.



  • This is the thing I was getting at, there simply isn't the resources for what I would call "Desktop Linux" to have 2 completing display servers, multiple rewrites of the major DEs (KDE is doing it again) ... competing sound systems etc.

    If you want a Unix with a decent desktop interface you best bet is unfortunately shelling out for a Macintosh of one variety or another.



  • @powerlord said:

    ...which has been delayed until 2016 last I heard (it was supposed to ship in Ubuntu 13.04 in April 2013). Meaning that Ubuntu and its derivatives are still using the old X Server.

    Is there any major distro that has made the switch from X? Wikipedia doesn't mention anything, but hints that neither Gnome nor KDE are fully ready for Wayland (let alone Mir).


  • Discourse touched me in a no-no place

    @powerlord said:

    First release of Wayland was two years ago.

    It's also awfully poorly documented. It's a subtle kind of poor documentation, one with lots of details about stuff you mostly don't care about (it reminds me a bit of XIM…) and missing key things like how to actually get a drawing surface that's associated with the system. You know, little stuff like that.

    Today's challenge: go to the official site and find how to get something that you can actually draw some shapes or text on with a library that you can comprehend.

    … I'll wait a bit …

    Have you managed to find anything as informative as this code yet? The relevant lines are:

    window->native =
    	wl_egl_window_create(window->surface,
    			     window->geometry.width,
    			     window->geometry.height);
    window->egl_surface =
    	eglCreateWindowSurface(display->egl.dpy,
    			       display->egl.conf,
    			       window->native, NULL);
    

    They're the ones that their documentation goes out of its way to not fucking tell you. If we have to guess this shit (or cargo-cult it from elsewhere) we are not dealing with something with production-quality docs. What is the rest of it like? Who knows…



  • The problem is basically that OSS folks don't give a fuck about what the users actually need or want. A typical dev will get all hooked up on the core feature of his program, because that's why they actually started coding - and then the "boring" stuff like UI, external APIs or not crashing on Mondays gets deferred to "whoever cares", which usually means nobody.

    It's not entirely bad - unless you expect people to actually use your software, instead of getting props just for the fact that it exists. It's like Ulysses - everybody will tell you that it's the greatest piece of literature in the past few centuries, but almost nobody actually managed to go through it.

    (side note: it's actually way better to deal with a patched together CLI than with a patched-together GUI. @SpectateSwamp, we're looking at you.)


  • Discourse touched me in a no-no place

    I suppose the problem is that nobody's sat down and said:

    How do I produce a tutorial for using Wayland as an ordinary application programmer, going from basics all the way through to a working application?

    They could also then go off and do the same with GTK and Qt and so on if they want, but the whole thing about showing the basics properly and clearly just isn't there. Nor is a culture of actually getting someone external to read the docs and taking their comments on board.

    Grrrr. I'm starting to rant too much for my taste here…



  • Of course you would post this on the one day I'm away from my computer all day.

    @ScholRLEA said:

    but there doesn't seem to be a clear idea of why this is the case.

    What bits are you missing? It's bad for SO MANY reasons.

    @ScholRLEA said:

    Portability. The commonality of shells goes beyond Unix, of course, and while the Windows PowerShell has little in common with BASH or tsch, it is similar enough that it is easier to write a minimal shell interface that will run on all common platforms than to re-implement a GUI for each system.

    Writing a portable GUI is easier than you think, like I mentioned earlier, tools like Xojo are around. (Of course, Xojo is commercial and so the *nix users would never use it, despite it solving this particular problem.

    Doing it in C++, though, is very difficult, but, then again, so is doing everything in C++. I actually think a large part of the problem here is open source's reluctance to use any programming language more modern than C/C++ for application development-- even the open source community has C# and Mono, which does decent cross-platform GUIs. They just don't bother using it.

    @ScholRLEA said:

    Because there is no really universal GUI toolkit that is satisfactory to all developers.

    I don't see the relevance of this one. Very few people like the spaghetti mess of Ruby, Rails and God-knows how many obscure JavaScript libraries Discourse is running on, but it's still open source.

    @ScholRLEA said:

    Because GUI programming is harder than CLI programming by at least an order of magnitude. While this is a very poor reason in and of itself, when combined with the need for portability and the lack of a universal GUI toolkit, it is a major barrier to development of quality user interfaces.

    Now you're getting closer.

    But it's not just that it's harder (and I won't deny it is), but it requires doing things open source developers don't like to do much: talking to their users, planning without coding (things like paper prototypes, surveys, etc), and frequently erasing your own established and working code to do things a different way.

    @ScholRLEA said:

    I'm sure there are other issues that are at play as well, and I welcome any additional comments on this.

    High Priesthood of Technology.



  • @cartman82 said:

    In short, shell is simple, GUI is hard. GUI is built on layers on top of layers of libraries and dependencies. There are hundreds of things that can go wrong. And they often do.

    That's ridiculous. Open source GUI toolkits maybe, but not good ones.

    You would be shocked at how simple the Classic Mac GUI libraries were.

    Which brings up another point: most developers haven't ever in their life used a truly excellent GUI. So you keep seeing the same canards over and over again, people saying shit is "impossible" when in reality it not only is possible, it's already been done.

    "You can't make a great graphical programming environment!" "Oh yeah? What about HyperCard, asshole?"

    "You can't script a GUI!" "Creating AppleScripts in 1994 was easier, faster, and less error-prone than scripting together CLI commands is now."

    "Spatial navigation is a dead-end!" "No, you only think that because you used the broken Windows 95 implementation which wasn't spatial at all, Microsoft just called it that."

    "Your OS needs a CLI anyway!" "Classic Mac never had a CLI, the concept literally did not exist in the OS at all, and somehow was the second-most popular OS for a very very long time."

    This goes back to my complaints about developers writing software before educating themselves on what came before. The reason the state of the art never advances is because there's no "standing on the shoulder of giants" in our field, at all. Every so often you get lucky and someone's experience is actually paid attention to (like Fred Brooks' work), but 90% of the time it's completely forgotten only 10 years later and then some other "clever" developer comes along an re-implements the same already-rejected idea.

    Which is why Gmail, right now this instant, has auto-hiding lists of folders, an idea that was already tried and utterly and thoroughly rejected in Windows 2000.

    @cartman82 said:

    That's why it makes sense to have it running at the foundation of the OS.

    The simplest and most usable OS I have experience with had no CLI.

    @cartman82 said:

    It just makes sense.

    My actual experience of actually using a system without a CLI "foundation" says you are full of crap.

    @ScholRLEA said:

    I do have one more argument in favor of it, which I forgot to mention: expressiveness. There are things which can be done easily in a shell - especially if you have auto-repeat - which are cumbersome at best in a GUI.

    Again, this is a problem that was completely solved in 1994 or so with AppleScript and has since actually been unsolved. Automator in current Macs is not even close to what you could do with Script Recorder and AppleScript in general back in 1994.

    @Matches said:

    Because better solutions don't exist. Every distro of Linux spends all their time recreating the desktop, not one spends it's time actually furthering new system features. New features that aren't fun to implement, but are required to progress.

    CADT. Every product is version 0.8, which is followed by version 0.8, which is followed by version 0.8.

    @tarunik said:

    Even relatively simple GUI work (like a straight-forward, single-threaded MFC dialog app, which is an adequate model for many, many things that you'd otherwise do via CLI) is complex enough.

    Why would you write a straight-forward GUI in MFC? Even without leaving the world of Microsoft, you have much, much better tools available to you. And, as I said above, if you ever experienced the simplicity of Mac Classic's API, you'd be blown-away by it.

    @tarunik said:

    Add in the complexities of multithreading, MDI, complicated accessibility interfaces, UI scripting integration (which is a far more complicated way to make a program automatable than scripting a CLI program), etc..., and you've got a real hairball on your hands.

    Stop using C. WinForms does 99% of this shit for you. And WinForms is one of the worst alternatives.

    @tarunik said:

    (Never mind that many OSes are designed in a way that makes it impossible to write a responsive GUI without threading, due to certain system calls not being available in a non-blocking or otherwise asynchronous form.)

    That's a valid complaint. BeOS tried to solve that, BTW. I never actually wrote BeOS software, so I'm not sure how effective their solution was.

    @Arantor said:

    Same is true of Windows. I haven't played much with Powershell but even stuff I do on Windows I tend to do via the shell for anything other than very light copying of files just because I can do it faster there.

    Ever actually measured your speed? Done a double-blind test?

    In the past, whenever this has been studied, CLI users always perceived that they finished the task quicker; the GUI users always finished the task quicker.

    @Arantor said:

    That's the part so many people don't seem to realise. OSS starts with people scratching their own back. Once that's done, unless they have great vision or planning - and most of them don't - their role is done once it's publicly shared. If they choose to follow it up with feature requests and so on, that's great and all, but scratching one's own itch and being nice to share is always the primary motivation for starting any OSS project.

    Right; but the big culture-clash is that they also simultaneously say, "hey our software is great, everybody should be using it."

    If I visited a open source project and their homepage said: "Git is really hard to use and doesn't really do anything new, go away", then I probably would have nearly the problems I do have with it.

    What the actual website says:

    Git is easy to learn and has a tiny footprint with lightning fast performance.

    Fucking liars.

    @dkf said:

    (typically at least programmer, tester and artist; lots of programmers can't do shit for making things pretty 'cos they don't think like that)

    Here's an illustration of another problem: usability has nothing to do with "prettiness". Mac Classic was ugly as shit. It was simultaneously the most usable OS ever made. Developers don't even know what usability is anymore.

    @dkf said:

    (if your users are other developers, the right type of UI is not the same as if it is the massed grandmas of America).

    That's self-fulfilling prophecy.

    "Git users want a shitty CLI because developers like a shitty CLI ." "Well, has anybody ever tried offering developers a really great GUI for that task?" "Nope! Because we know developers like a shitty CLI."

    @ScholRLEA said:

    One could argue that shitty GUIs are another part of the reason for CLI-based OSS. It' s a lousy reason, and one which shows a lack of interest in actually improving the GUIs, but it is there.

    People who have only been exposed to shitty GUIs might come to the wrong conclusion that all GUIs are shitty.

    @PleegWat said:

    Does ncurses count as a GUI for the purposes of this thread?

    It does if it does.

    For example, I'd say that the MS-DOS 5+ "edit" command is a GUI. Sure, it's in text-mode. But it also follows all the standard GUI conventions of the time.

    A ncurses app could emulate a GUI like that, or it might just use it to draw distracting colors. Without knowing more than "it uses ncurses", there's no way to proffer an opinion.

    @Maciejasjmj said:

    The problem is basically that OSS folks don't give a fuck about what the users actually need or want. A typical dev will get all hooked up on the core feature of his program, because that's why they actually started coding - and then the "boring" stuff like UI, external APIs or not crashing on Mondays gets deferred to "whoever cares", which usually means nobody.

    It's not entirely bad - unless you expect people to actually use your software, instead of getting props just for the fact that it exists.

    Again: that would be perfectly fine, if the product's website said, "this is broken garbage, I hate you, go away". But invariably, the website says, "this great intuitive new product will solve all your problems and happy joy sunshine!"



  • How fucking long did it take you to quote all those people?



  • I actually replied the *shudder* Atwood way.



  • I don't know what that means.



  • Opening up the reply box and then just scrolling down all the posts and quoting bits as you go. I feel dirty.

    I usually reply to each post individually just to spite Atwood.



  • @blakeyrat said:

    ScholRLEA said:
    I do have one more argument in favor of it, which I forgot to mention: expressiveness. There are things which can be done easily in a shell - especially if you have auto-repeat - which are cumbersome at best in a GUI.

    Again, this is a problem that was completely solved in 1994 or so with AppleScript and has since actually been unsolved. Automator in current Macs is not even close to what you could do with Script Recorder and AppleScript in general back in 1994.

    Quite right. Actually, it was solved a lot earlier than that; Doug Engelbart (who pretty much invented the whole idea of user interface design) did a lot of work on it in the 1960s as a matter of fact, as did Alan Kay in the 1970s - that was really the whole idea of Smalltalk, in fact - and Niklaus Wirth in the 1980s. The solutions keep getting ignored, unfortunately, and then reinvented with all the lessons learned by previous developers forgotten.

    The real issue is that the tools have to be in place, well designed, and universal, or, as I said earlier, you end up with the applications forcing their own poor and (more importantly) incompatible implementations on users who just want to get things done. This has always been the main problem with tools like AutomateIt! and the various attempts at a HyperCard equivalent for Windows - the users couldn't rely on them being there on any given machine they needed to work on..

    As I've said before, I've always liked Wirth's solution as used in Oberon: make it possible to take any piece of text, select it, compile it on the fly, and run it as a script. You could make a button just by selecting the code you want it to run and bind it to a point in the display. Simple. You still had to learn a little bit of how to write a script, and unfortunately the particular language he used (Oberon, an OOP derivative of Modula-2) was not especially suited for it, but the basic idea was there. The main thing lacking was an action recorder, which is really what most people need more than scripting, but since Wirth was a language designer and not an interfaces expert it was an understandable oversight.

    Much as many of you may dislike Lisp and/or Smalltalk, the designers of both Smalltalk-80 and Genera had this problem in hand as well - for anyone who could learn either Smalltalk or Lisp, that is. I'll admit that Smalltalk is by far the better of the two for this purpose, but I'd still say Lisp is better than Oberon for scripting. But enough digression.

    And as I said when I brought the subject up, it is not a good reason for not using a GUI. It is a very bad, specious reason, as the absence of such tools is a sign of a poorly designed user environment.



  • @blakeyrat said:

    <snip> 💓 💓 💓 MAC CLASSIC 💓 💓 💓 </snip>

    So basically, there was one good OS in the world - Mac Classic. And it was all downhill ever since. I never had that computer, so I can't tell if it's nostalgia or you're on to something.

    But I looked it up and you're right, it didn't have CLI underneath GUI.

    The fact remains you need a lot more code to set up GUI than CLI. Not talking about API, talking about the mountain of stuff underneath. On the other hand, I imagine Apple might be able to pull it off, as they control their own hardware (so at least there's one layer of complexity that goes away).

    I do wonder if it could be done today, though. I would definitely be interested if someone gave it a go, although the bar to entry is so high, I don't expect to see a genuine new OS in my lifetime.



  • @blakeyrat said:

    Here's an illustration of another problem: usability has nothing to do with "prettiness". Mac Classic was ugly as shit. It was simultaneously the most usable OS ever made. Developers don't even know what usability is anymore.

    Developers, on the whole, never really did. A handful of designers have, like Ted Nelson and Alan Kay and Jef Raskin, but most have simply never learned that UIs are something that need to be designed. Schools don't teach it, programmer culture doesn't support it, and few if any bother to figure it out on their own.



  • @cartman82 said:

    The fact remains you need a lot more code to set up GUI than CLI. Not talking about API, talking about the mountain of stuff underneath. On the other hand, I imagine Apple might be able to pull it off, as they control their own hardware (so at least there's one layer of complexity that goes away).

    Fun fact: the original Macintosh Toolbox was crammed into a single 64K ROM (I doubt you could compile "Hello World!" into 64K with some of the compilers out there today) and ran in just 128K of system memory on the very first model. It was all hand-coded assembly language, on a 32-bit CPU (the Motorola 68000) that came out only about eight months after the vastly inferior 8086. It was mostly written by a single coder, (Andy Hertzfeld, IIRC), in less than four months.

    To give Blakeyrat his due, he's dead right about this one.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Here's an illustration of another problem: usability has nothing to do with "prettiness". Mac Classic was ugly as shit. It was simultaneously the most usable OS ever made. Developers don't even know what usability is anymore.

    I know, from long years of experience, that I don't produce pretty UIs (which some believe to be a substitute for a usable UI). I get satisfied very rapidly as long as the information is there. If I need to produce such a thing, I'll hire someone to do that side. I'll give them a solid foundation to build on, a working roof, properly connected power and sewers and so on, but I'll let someone else figure out what the wallpaper should be and how the kitchen cupboards should be arranged.

    @blakeyrat said:

    That's self-fulfilling prophecy.

    "Git users want a shitty CLI because developers like a shitty CLI ." "Well, has anybody ever tried offering developers a really great GUI for that task?" "Nope! Because we know developers like a shitty CLI."


    Git is actively misanthropic. Enough about it already.

    A usable interface for a developer is something like a highly logical and well designed API, or a clear and powerful IDE. It can reasonably demand some learning to use well; developers are usually at least power users.

    An interface aimed at end users is very different, especially as it is rare that those end users will consider it important to actually learn in depth what you're doing. This means that the developer of the code concerned has to pay a lot more attention to how to present things to users, how to guide them through the decisions that need to be taken and what decisions ought to be concealed entirely through the use of auto-detection and sensible defaults (unless someone self-identifies as wanting this extra level of detail).

    But arguing that all user interfaces ought to have that level of attention spent on them? That'd be a vast waste of resources. Spend effort where it will be most effective, bearing in mind that there's lots of other things that need it too.


  • Trolleybus Mechanic

    I vaguely remember that when I was learning software design, the rule was "the UI comes first".

    Then again, it sometimes seems like everything I ever learned about software design doesn't really apply in the Real World.


Log in to reply