> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on.

> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on. I'd correct that to: The engineering world would be a much better place if more people built beautiful, easy to use command line apps It can be done, although it takes a lot of effort to do well- and a lot of the developers who write CLIs* have very few notions of HCI design. As a result the vast majority of CLIs are inspired from programs that are decades old, and in which no thought was given to the interface, thus perpetuating the cycle. When well executed, a CLI is insanely superior to a GUI on many fronts (with a few exceptions, naturally, such as image/video editing), and more respectful of the users. It is much more friendly to users with vision or motor impairments: any font and any color scheme can be applied, any method of text input can be used, text readers behave in a much more predictable manner, etc. And of course it enables scripting to a level that GUIs just can't compare to. Ideally you'd have a well designed CLI for the users who want it & scripting, and a well designed GUI - but let's face it, doing both is a huge drain of time. If you're going to do one, then a CLI is much, much preferable. On the usability scale, there isn't "CLI apps" on one end and "GUI apps" on the other. Some GUIs are extremely usable, some aren't; some CLIs are extremely usable, some aren't. I am a staunch supporter of the idea that while GUIs became mainstream and CLIs were relegated to a niche position, it should have been the opposite. But we had mediocre CLIs and decent GUIs, so it's only natural that it went that way. Great CLIs would have been preferable on many fronts. Traditionally, the main argument against CLIs is the lack of discoverability that GUIs afford, which is a very valid point. That being said, most CLIs don't make an effort to enhance discoverability, which makes the argument still valid, but a little unfair. Ultimately, I fully subscribe to Jeff Raskin's argument that if you're going to build a tool that users will use on a daily or weekly basis, then it's better to build something with a steep learning curve the first few hours which then results in an efficient and effective tool, rather than something that any newcomer can master within seconds but that will be tedious for extensive use. GUIs that you can master in seconds belong in smartphone apps that you will use a handful of times and then delete a few weeks/months later (this isn't dismissive- if there's a market for it, then it's legitimate). Powerful CLIs that are a bit rough the first handful of hours but become extremely powerful tool belong in your browser, your email client, your text editor, your calendar, and so on: tools that you expect to use for years, if not your lifetime. * : In this comment, by CLI I mean any form of program that runs solely in a command line, but that also includes highly interactive apps built with ncurses etc. There are very, very few command line apps that are solely "type a command, get an output" anymore.