Live data from Hacker News

The Renaissance of the Shell?

effective-shell.com

11–20 of 69 posts

Re: The Renaissance of the Shell?

#11

It's hard to automate something with a GUI. It is also hard to make programs interoperate if they use a GUI.

I think that we just don't have a standard for it. I know people use AutoHotkey to automate a lot of workflows involving GUI applications.

Recently there was a thread about Factorio (the game), which is all about automating. And once you have standard-ish inputs & outputs, you can achieve a lot of automations, in a different way.

It also highlights that the shell has limitations: it's hard to give multiple inputs, and handle outputs and create a complex pipeline. (I guess that's why we have things like Airflow)

Re: The Renaissance of the Shell?

#12
post #6

I certainly hope the shell doesn't have a renaissance. Just today I was updating my dotfiles/customizing my OS, and I had to swap out several shell scripts for Python scripts because I couldn't edit shell. The scripts looked like arcane rituals, not editable code.

As I read it, the article is more about the concept of scripting in general - and not about any specific language bash/zsh/powershell/etc.

I definitely agree, I think that POSIX-shell scripts can often be completely unreadable and difficult to maintain. But I think the concept of scripting in itself is fine, even though the implementations we might use today are slightly outdated.

At the moment there's a huge number of interactive shells like nushell and xonsh being built, but they don't really focus on scripting; I'd really love to see more competitors attempting to take on the mess of bash scripts.

Re: The Renaissance of the Shell?

#13

It's hard to automate something with a GUI. It is also hard to make programs interoperate if they use a GUI.

It doesn't have to be though, there's just a high correlation between hard-to-automate apps and non-command-line apps. You can e.g. make a GUI app where every button or keybinding is bound to a named function (GUI Emacs comes to mind), and where those named functions can be used in scripts. Another option is to have a scriptable backend; LibreOffice has a terminal interface that lets you e.g. convert between document formats from a shell script, and Astroid Mail is built on Notmuch as its backend which is scriptable.

Re: The Renaissance of the Shell?

#14
post #6

I certainly hope the shell doesn't have a renaissance. Just today I was updating my dotfiles/customizing my OS, and I had to swap out several shell scripts for Python scripts because I couldn't edit shell. The scripts looked like arcane rituals, not editable code.

I remember seeing shell for the first time ~15 years ago, and it certainly looked like an arcane ritual.

Syntax like var=value and [ x -eq y ] was super weird coming from C and Python.

My Oil project fixes many of these problems:

http://www.oilshell.org/blog/2020/01/simplest-explanation.ht...

(as well as fixing semantic problems; it's not just syntax)

Re: The Renaissance of the Shell?

#15
post #3

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…

Question, 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.

I 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.

Re: The Renaissance of the Shell?

#16
post #3

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…

Question, 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.

I 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.

Re: The Renaissance of the Shell?

#17
Most of ones work should be in the shell all the time, because automation tasks are every day phenomena (or should be). Otherwise, if its GUI oriented, you will still have to learn CLI variant sooner or later and not only its harder or almost impossible to automate, but such automation is usually flaky as well.

Shell should be considered basic and most important interaction with computer with anything else deemed as optional.

The big problem is that almost all of the shell's are stuck in the previous century, except PowerShell.

Re: The Renaissance of the Shell?

#18
The three points about the renaissance of the shell are spot on.

(1) Systems being written in more languages means the shell becomes more important

I wrote about that here: https://news.ycombinator.com/item?id=24083764

The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages.

in regards to http://www.oilshell.org/

(2) Convergence around Unix and Linux for the server side.

Unix won. In 2017 or so, Windows Subsystem for Linux was marketed as "Bash on Windows" !!! That is, being able to run a 30 year old shell and other programs was a new feature of Windows.

(3) DevOps

I forget where I read this, but someone quipped that "old school sys admins didn't disappear". (That is, the experts at Unix shell.) "What happened is that they went to work for AWS and Google and then sold their skills back to you at a higher and recurring price"

I find that to be pretty spot on... The cloud companies are making a lot of stuff point and click, and cut and paste YAML, so you don't have to use shell, but I think programmers are better off learning and using shell.

Reaosns: For autonomy, to avoid being locked in, to exercise the ability to create simple, sharp, one-offs ... not drag in a 200 MB cloud SDK to solve a simple problem.

Re: The Renaissance of the Shell?

#19
post #5
post #2

I firmly believe that a lot of really productive work can be done with shell-based applications, and that this environment represents the true power of productive computing. With the web taking front and centre priority, we've lost something very important in terms of human/computer interaction - many would say things are 'easier', but I have to laugh at this claim whenever I see someone clicking something in a list…

You're not really wrong on many of your points, but you look at everything from a power user/developer mindset and that's too narrow of an approach, sorry. I.e. you should realize programming is not for everybody, not even close, so the claim that things are easier now is very much true for a lot of people out there. As such there's not much to laugh at, in fact that sounds borderline disrespectful to me.

> You're not really wrong on many of your points, but you look at everything from a power user/developer mindset and that's too narrow of an approach, sorry.

I sometimes wonder if how people talked about 'this whole writing and reading thing' way back when. Perhaps there's a future where the average person will be what we now consider a 'power user'?

Much as there's the criticize about current-day computer use, as someone who was considered a 'nerd' for chatting online in my teens, it's still amazing to see extremely non-typical 'nerds' sit at their laptops or phones chatting with others. Or to have conversation about gaming with people who fit the 'jock' stereotype.

I'd love to hear from historians how the 'common people' thought about writing back in the day when most people were illiterate.

Re: The Renaissance of the Shell?

#20
post #9
post #7

Earlier quoted context omitted.

Shell scripts have some idiosyncrasies sure, but at least they don't rely on significant white space.

Not a pure shell, but Makefiles do rely on whitespace. I never understood why so many people care about that (not to mention that python uses the curly braces as a useful syntax element for dicts & sets)

Makefiles don't gernally have anything more than one level of indentation that is significant.

People care about significant whitespace because it's inferring heavy semantic meaning from something that's by default invisible, and even when shown visibly, may not actually be particularly obvious.

Post reply on HN