[jibal]

Failure to understand something is not a virtue. That it does get a lot of love strongly suggests that there are reasons for that. Of course it has flaws, but that alone doesn't tell us anything; only comparisons do. Create a comprehensive pro/con list and see how it fares. Then compare that to pro/con lists for other languages.

[xelxebar]

> That it does get a lot of love strongly suggests that there are reasons for that.

Reasons, sure, but whether those reasons correlate with things that matter is a different question altogether.

Python has a really strong on-ramp and, these days, lots of network effects that make it a common default choice, like Java but for individual projects. The rub is that those same properties—ones that make a language or codebase friendly to beginners—also add friction to expert usage and work.

> Failure to understand something is not a virtue.

This is what I want to say to all the Bash-haters that knee-jerk a "you should use a real language like Python" in the comments to every article that shows any Bash at all. It's a pet peeve of mine.

[pnt12]

I'm not a hater, but also not the biggest fan of bash. What do you consider its pros and cons?

Pros: easy to interact with different tools, included in many Unix OSs, battle tested.

Cons: complex stuff gets messy, with weird syntax, hard to do logic, hard to escape everything correctly

[xelxebar]

I think you did a good job delineating top complaints people have about shell, but I have to reject the pro/con framing.

Shell operates quite naturally under stream-oriented data-centric design patterns. But that's an architectural familiar to almost nobody in our OOP- and FP-happy industry these days. Try using Python like a relational database language (e.g. SQL), and complex stuff gets messy, the syntax starts feeling hostile, logic becomes obscure, etc. The purported ickyness of shell stems not from shell per se but from trying to force it into a foreign design space.

Principles that work well with shell: Heavily normalize your data; Organize it into line-oriented tables with whitespace-separated fields; Use the filesystem as a blob store; Filenames can be structured data as well; positional parameters form a bona fide list.

> hard to escape everything correctly

IME, all of the really painful escape patterns can always be avoided. You see these a lot when people try to build commands and pass them off to exec. That's mostly unnecessary when you can just shove the arguments in the positional parameters via the set builtin: e.g.

    set -- "$@" --file 'filename with spaces.pdf'
    set -- "$@" 'data|blob with "dangerous" characters'
    set -- "$@" "$etc"
    some_command "$@"

which is functionally equivalent to

    some_command "$@" --file 'filename with spaces.pdf' \
        'data|blob with "dangerous" characters' \
        "$etc"

It also helps to rtfm and internalize the parsing steps that happen between line of input and the eventual execve call.

[sophacles]

Pro - there is still not another language (generalizing to "shell" here) that allows you to easily write a series of commands and/or pipelines as concisely and understandably as shell.

This is the biggest reason to use shell - if your task is shaped like a command line session with a bit of looping or a few conditionals, shell is perfect.

If you start nesting loops or conditionals in shell, then start considering another language.

[jibal]

"Reasons, sure, but whether those reasons correlate with things that matter is a different question altogether."

Thus my word "suggests". Thus the comprehensive pro/con list.

I'm not here to defend tiresome strawmen.

[xelxebar]

It's not so much a matter of exhaustively listing pros and cons, but more a matter of appropriateness to the desired goal or goals IME. I seriously doubt that a comprehensive pro/con list can even be coherent. Is dynamic typing a pro or a con? Depends on to whom and even in what decade you ask. List comprehensions? Interpreted language? First class OOP? Any cost-benefit anaylsis will be highly context-dependent.

> I'm not here to defend tiresome strawmen.

I won't point out that you already tried to (contradiction intended). Perhaps a more interesting discussion would result if we defaulted to a more collaborative[0] stance here?

[0]:https://en.wikipedia.org/wiki/Cooperative_principle

[aquariusDue]

I don't have anything useful to add per se but I'd like to thank you for validating my intuition that pros and cons lists not only don't generalize as to be useful universally but also that the more "rigorous" you get with it the whole things evolves into an exercise of ridiculousness.

An example I like to give is the wood chipper. Pros it can do a lot of useful things around the yard (that you can list individually), cons it can chop your arm off. How many pros do you need to overcome that con? Though I'll admit there's a difference between "can" and "will", the latter hinging on improper use.

tl;dr I'm a bit tired with people glorifying a semi-useful cognitive device.

[9rx]

> Of course it has flaws, but that alone doesn't tell us anything; only comparisons do.

Comparisons won't tell us anything. If Python were the only programming language in existence, that doesn't imply that it would be loved. Or, if we could establish that Python is the technically worst programming language to ever be created, that doesn't imply that wouldn't be loved. Look at how many people in the world love other people who are by all reasonable measures bad for them (e.g. abusive). Love isn't rational. It is unlikely that it is possible for us to truly understand.

[jibal]

> Comparisons won't tell us anything.

If you insist.

> If Python were the only programming language in existence, that doesn't imply that it would be loved.

I'm not here to defend bizarre strawmen.

> It is unlikely that it is possible for us to truly understand.

If you insist.

[jibal]

Perhaps I shouldn't have been snide, and should instead have straightforwardly explained how gawdawful their reasoning was.