Live data from Hacker News

The Renaissance of the Shell?

effective-shell.com

21–30 of 69 posts

Re: The Renaissance of the Shell?

#21
post #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…

> I think that POSIX-shell scripts can often be completely unreadable and difficult to maintain.

The same could be said for any language, if you're not familiar with it.

Re: The Renaissance of the Shell?

#23
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)

I use Python a lot so it's not a deal breaker to me, but even after years of use significant whitespace is still firmly in the "bad ideas" category for me. It's form over function.

When I code in C and move some code around I can just tell my editor "reindent this code" and it looks fine immediately. With Python I always have to double-check to make sure everything is in the right place.

Similarly I almost never have to reindent anything manually in C. The editor always knows where I should be based on the number of open braces. In python I often have to readjust. A common situation where that's annoying is if I want to add code after and outside a block, in C I just tell vim to open a line after the closing bracket and I'm immediately at the right location, in Python doing this will have the cursor at the wrong level of indentation.

It's not the end of the world and it's bikeshed territory but for me significant whitespace is in the same category as automatic semicolon insertion in JavaScript, I sorta get why somebody thought it was a good idea at some point but it's just more trouble than it's worth in practice.

Python wanted to be the anti-perl and it went too far in some places. Pseudo-code is only "pseudo" for a reason.

Re: The Renaissance of the Shell?

#24
post #22

The shell is the tool that allows us to talk to our computers, and for our computers to talk to us. Until a better way comes out to tell the computer what to do, the command line will prevail.

I alsways explain it to new students as the shell being the equivalent of "under the hood" but for computers instead of cars. If you go to a car mechanic with engine problems and they won't even inspect under the hood, it's probably not a very good mechanic.

(The last few years have not been too kind to this metaphor because of computer-based analytics, but still)

Re: The Renaissance of the Shell?

#25

Earlier quoted context omitted.

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 worl…

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.

Tyranny of the Minimum Viable User

https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...

Re: The Renaissance of the Shell?

#26
Learning Vi at an early stage in career has been a life saver for me. Having to do a lot of my work on remote shells over many years could have been more difficult had I not had some degree of command over a text editor like Vi.

And then there are other advantages too. Editing code in Vi/Vim is akin to touch typing if you are really good. Programming becomes so much easier and so much fun.

And last but not the least, there are still loads of things to learn about Vi.

Re: The Renaissance of the Shell?

#27

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…

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

Another exception is Nushell, which seems to be partly inspired by PowerShell, and has some very appealing ideas. However, given the time Fish needed to steal even a small market share from Bash and Zsh, it will likely take a long time before something even more radical goes mainstream. Unless of course a major player were to back this new shell, like when Microsoft pushed PowerShell and Apple pushed Zsh.

Re: The Renaissance of the Shell?

#28

Earlier quoted context omitted.

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 worl…

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

Re: The Renaissance of the Shell?

#29

Earlier quoted context omitted.

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 worl…

Another Amiga datapoint is Blitz Basic II, which I pretty much learned to code on back in the 90s. It didn't have any command line tools, you did everything from the IDE. You could however control it remotely using ARexx.

(I actually used this feature recently when I wrote a Blitz Basic plugin for modern Emacs. It uses ARexx over the network to talk to Blitz, so you can write code in your modern operating system, and then compile and run on the Amiga running alongside in an emulator[0])

There were also a number of visual programming environments such as Amiga Vision and Scala which were marketed as "Multimedia Authoring Systems". They were used to create information kiosks, advanced interactive presentations and early CD-ROM hypermedia products such as multimedia encyclopedias, reference works and the like. I'm surprised there's nothing like them today, they seem ideal for the simpler end of the mobile ecosystem, or more cynically for those who want to turn their whole platform into unhackable (in both senses of the word) information kiosks.

Back in the 90s I looked at systems like this, or at Visual Basic, or NeXT Interface Builder (which later made its way to Mac OS X) and thought that the future would be some extension of these technologies, not the tottering stack of cli tools we use today.

I too miss the Amiga, and consider myself a proponent of desktop personal computing and "bicycles for the mind", which can be a depressing thing to be in these times.

[0] https://github.com/richardjdare/bb2-mode

Re: The Renaissance of the Shell?

#30

Learning Vi at an early stage in career has been a life saver for me. Having to do a lot of my work on remote shells over many years could have been more difficult had I not had some degree of command over a text editor like Vi. And then there are other advantages too. Editing code in Vi/Vim is akin to touch typing if you are really good. Programming becomes so much easier and so much fun. And last but not the least,…

Plus most modern shells have a vi editing mode. Add something like vimium to your browser and you can use the same muscle memory across environments.

I did switch from vim to Emacs + Evil though (Evil adds a decent text editor to Emacs), with my own set of spacemacs-like keybindings.

Post reply on HN