5 ms·
I also observe a renaissance of command line interfaces. I guess it's a trend in a similar way how the graphical user interface (in the MS Windows/OS X/X11 way)
by ktpsns 6y ago
I also observe a renaissance of command line interfaces. I guess it's a trend in a similar way how the graphical user interface (in the MS Windows/OS X/X11 way) has been trendy in the 1990s/early 2000s. Remember that Apple banned the terminal from classic Mac OS. This was a declaration of war against complicated CLIs. Nowadays we experience the opposite: Microsoft is building the most modern Terminal emulator as well as many productivity tools such as Powershell but also the Linux subsystem.
Of course this is driven by commercial interests. Microsoft tries to close the gap to the rich Mac OS X development environment, which is rich because it is compatible to the Unix/Linux ecosystem.
As the author noted, many jobs are primarily terminal-based in a way like probably nobody would have believed 20 years ago. DevOps or data scientist, they both enjoy powerful CLI applications, REPL interfaces, scripting as if the "GUI movement" did not even take place.
- Cthulhu_ 6y agoQuestion, because I wasn't a developer 20 years ago yet; were the GUI tools of "back when" wrappers around CLI tools? I get that impression with most IDE's I've worked with.
- yuribro 6y agoI don't think they were the same way they are now. Visual Studio 6, which was an amazing environment for its time, was all implemented as a GUI application, including the build system, IIRC you could do some automations with VBA or a complex "macro" system baked inside the UI. You could run the compiler/linker as cli apps, but everything else was built in. VisualAssist was a very popular plugin for it (don't know if it's still relevant) which added functionality inside the GUI.
- flohofwoe 6y agoI think this depends heavily on the platform. Towards the end of the Amiga it was common that applications were accessible through a GUI, through the command line and through scripting, as well as extending operating system features for other applications via system-wide installable plugins/extensions which are recognized by other applications. It was common to use a mix of UI and command line workflows and both worlds were well integrated with each other. For instance: A typical 2D drawing program which would primarily be used through the UI to draw images could also register new image format plugins with the operating system, so that all applications that deal with image files suddenly can load and save those new formats. The same application might be started on the command line in a 'headless' mode to offer image manipulation tasks like ImageMagick, and finally the application can offer an AREXX scripting port for more complex automation tasks, and "orchestrating" several applications. All of this was standardized through "best practices" guidelines by the Amiga team. I miss the Amiga :) PS: My pet theory for the reason why there's a "shell renaissance" is that UI usability (in the sense of making complex application features "usable") has dramatically regressed in the last 10..20 years because the target audience for most apps has changed from active users to passive consumers. People who don't fit the "average user" have no other choice than to move to the command line because UIs are no longer designed for them. This "average user" targeted by UI designers is no longer a creative person who uses the computer to solve tasks or create art, but a passive media consumer. The computer has been degraded from the "bicycle for the mind" to a dumb TV set basically.
- dredmorbius 6y agoPeople who don't fit the "average user" have no other choice than to move to the command line because UIs are no longer designed for them. Tyranny of the Minimum Viable User https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyranny_of_the_minimum_viable_user/ https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...
- p2t2p 6y agoI disagree. While what you're saying is true there's other side to the issue. The command line tools are simply more versatile and configurable. We can try to take git clone command as an example and try to design a GUI dialogue which would allow to use all the options it has. I think it is very hard and you will end up with something looking scarier than space shuttle cockpit. I believe it'll take roughly the same time to make sense of that dialog that it takes me to quickly man git-clone to remind myself about some obscure option I don't use everyday. I don't hate on GUIs, I just think that it is very hard to design full-featured GUI for complicated tools that we use every day. I would like to see an attempt to do this for Git, the key is being full-featured.
- flohofwoe 6y agoI think that's more because the standard git client was designed with command line usage in mind and UI usage had been ignored at that step. Had the goal been a hybrid GUI/CLI from the start than the entire git workflow might look different (which wouldn't be a bad thing IMHO, because the git command line UX isn't all that great either).
- smichel17 6y agoThis is my criticism of most git GUIs. They try to provide 1:1 functionality with the command line. But this defeats the purpose -- instead of making it more obvious what every button will do, it adds an additional layer of complexity where now I have to guess which CLI operation that button maps to. But the point of the GUI is that it's more accessible than the CLI. If you have to learn the CLI interface anyway in order to use the GUI, it is wasting a huge amount of potential.
- cheph 6y ago> Microsoft is building the most modern Terminal emulator If it is anything like Powershell, which is more "modern" than bash, then I don't think it will make much of an impact. Powershell seems like it was designed by a comittee which did not quite understand the point of what they were doing. It seems that if at least someone on that committee used a Unix terminal maybe once in their lives they would realize that what they were building would deliver a really bad user experience.
- cringepirate 6y agoI read "Bad user experience" but I suspect what you mean is "It not what I am used to". They (Microsoft) say that their inspiration was Korn Shell and Languages like TCL. Microsoft when they still offered Windows services for Unix, they did provide a Korn shell. If you look at some PowerShell examples and some Korn Shell example there are quite a few similarities between the two. So they obviously were quite aware of the options in the *nix world. I really wish people wouldn't make these sorts of claims when spending like less than a few minutes looking up the development history would dispel these ideas immediately. Personally I really like PowerShell and I find it fun to program in whereas with bash I seem to have to always relearn it whenever I attempt to do something non-trivial. However I come from a background of programming in OOP languages like Java and C# so many it just suits my mental model better than bash.
- dllthomas 6y agoMy assessment, from a history with a lot of bash and a little, not terribly recent PowerShell, is that PowerShell wound up in a pretty common position of having a better language but a worse UX. Picking out why (wrt UI in general, not powershell in particular) is an ongoing interest...
- koffiezet 6y agoIn my (limited) powershell experience, it's a "scripting first" shell, while bash is more of a a cli-first shell. Using a powershell cli is very verbose (although pretty consistent), but using it without some sort of GUI helper if you're not familiar with it is pretty daunting.