Hacker News Reader

Comment by xg15 | Hacker News Reader

I think one of the things that still make shell scripts so alluring is that it's the same language you use for your shell.

Many of my scripts for personal use were basically just cleaned up and slightly extended versions of the command sequences I typed in anyway. This is different from writing a script in a proper language where you usually start from scratch.

I believe, this was Perl's approach originally: Let you use your shell commands as a starting point and then gradually extend the code in a safer language. However, this still leaves you with many of bash's syntax issues.

On the opposite side, many modern languages do have REPLs - but I have not seen anyone so far use them as actual day-to-day shells.

So I think to really get rid of shell scripting, you'd have to develop some syntax that would work well both for scripts and for shell use.

View on HN

I think that's the void PowerShell TIRED to fill, but I loath even trying to read such a script because everything is so obtuse. Unix style shells only blindly pass around octet streams, implicitly delimited by \n characters, but really a blind pipe of bytes is the true interface. As it _can_ be anything, to get anything other than human text each program needs an extra flag that alters it's output and thus documents the new format. There's also nothing that stops a program from accepting arguments that arrange for a nest of files and/or fifos (which can also be seen as a type of named pipe) for their interface instead.

Unix style shells start simple and get as complex as desired, rather than a set of typed objects which must all be kept in memory at the same time.

I think what PowerShell showed me is the next step above something the complexity of a Unix shell is a "real programming language", no matter if it's interpreted live (scripting) or compiled. There might be reason to revisit the exact syntax, but I'll wait to hold my breath until we've replaced keyboard layouts designed to slow down typing to a point which doesn't break a mechanical typewriter.

I'm always very mixed on PowerShell as it can be quite useful and it's mature enough in windows that it really does simplify a lot of windows administration tasks to be trivial and can save a ton of time there by having a nice and safe way to avoid working with the windows ui, a goal that everyone should strive for. The verbosity is not lost on me a d k do find it tiring to read scripts, and it's exacerbated when you read a poweshell script written by someone who started with a "real" language and tries to make PowerShell work like those languages.

Windows apps that have PowerShell cmdlets are a boon also to administration also and I'm grateful when the option is there.

My biggest gripe with PowerShell though is that as soon as you get past the "I don't want to click around windows/.net apps", Powershell shows how shallow it is and its quirks affect performance, design, etc. The PowerShell community encourages a lot of practices that end up trapping you in bad design which makes maintenancen and readability of scripts a challenge. (the handling of variables and their scope can be confusing as PowerShell allows for a lot of "cheating" on which data is accessible and the script will work, but it's very hard to tell sometimes the state of the data being worked on and where it came from. Use of += for adding to arrays is fastest to write at first blush, but you end up with awful performance because it copies the array, but your average PowerShell script writer wouldn't know it and ends up wondering why your script struggles outside of simple lab scale tests)

The answer to this is getting into reflection and using .net calls, but to get the right performance and behavior from PowerShell you end up with a good portion of the script being just straight up .net code and at that point I wonder why bother with powershell at all and not just use .net and some faster API to get data from the app or going through wmi to work with windows instead.

You can get complex PowerShell programs for sure. But they're PowerShell only in name, the force powering the program is usually something else that PowerShell only hinders as you need to now deal with PowerShell-isms to make it execute.

So in a sense it's very successful in that I think this is exactly what PowerShell was supposed to do. But I find as I got past short scripts that PowerShell just can't really do anything it does better than another language would. It can't work anywhere near as fast as bash or any other *nix shell can, you can get a lot of depth into windows but mostly through .net calls, and for applications, a good rest API returns the same data, but faster and in a format more useful for other applications. (both program wise and just in terms of concept)

It feels like PowerShelk was (is?) supposed to be a gateway drug for .net. But it's just too easy to get hooked on it and suffer the side effects and never really take that next step to a more mature language, so you get less of high from using it but way more nasty side effects.

(Also the less said about PowerShell ISE the better. I wish MS would just remove it entirely as its difference in behavior from the actual shell wastes so much time in debugging scripts)

The power of shell scripts are the redirects and the pipes, nothing else is as close to the file system and has the same power and expressiveness for system administration tasks.

I completely agree. In fact I blogged about this problem myself. For what it’s worth there are a few indie shells out there that are trying to solve this problem:

- Elvish (non-POSIX)

- Oil (Bash superset)

- murex (non-POSIX)

Oil is probably the most interesting on this list because it aims to be 100% Bash compatible while supporting additional syntax to make it less ugly. Thus an upgrade path from Bash.

Elvish and Murex are similar in they they’re typed shells (like Powershell but less ugly and works with existing Linux / UNIX CLI tools) but have slightly different approaches in solving that similar domain.

My dream shell is not a bash superset, in fact it's as far from bash as possible (because I don't know bash, and won't ever know bash). I dream of a python/nodejs shell that can list files, and run and pipe programs.

Like xonsh, but even less bash-y.

I hear this opinion a lot but the reason such shells don’t take off is because most of the time in a shell you’re writing the same short snippets over and over. The burden of doing that becomes annoying after a while in some of the more verbose languages. Thus shells favour read once and write many syntaxes.

I also agree. In fact, I have a feeling it is not simply a matter of allure, but one of the most decisive and important factors if not the single most.

I think we tend to underestimate the importance of this kind of uniformity (aka homogeneity, consistency, sameness, equivalence etc) that allows us to freely shift back and forth and work across different environments (aka contexts, mindsets, etc) without any essential changes and translations. i.e. in a sense, minimizing the boundary such that the difference effectively disappears and it feels as if it's all just one same. In this case the environments being shell <-> script. But I think I see similar patterns in many other places, including outside of tech.

So, similar to as you also mentioned, as long as there is no language that beats the current shell as both a shell language and a scripting language, and one that sufficiently matures for real practical uses as both, I have a hard time imagining the most perfect scripting language alone still being able to make shell scripts go away. At least, I have a hard time imagining myself abandoning shell scripts otherwise.

Reply on news.ycombinator.com