6 ms·

I don't understand the downvotes. This is a fair criticism. The author even points out "programs as pipelines" which is literally the UNIX philosophy. There are

by zer8k 3y ago

I don't understand the downvotes. This is a fair criticism. The author even points out "programs as pipelines" which is literally the UNIX philosophy. There are tools that already exist on UNIX-likes more people should use instead of reaching for a script. I can sympathize with the author w.r.t wanting to use a single language you like for everything. However, after decades I've found this to be untenable. There are languages that are just simply better for one-off scripting (Perl, Python), and languages that aren't (anything compiled). Trying to bolt an interpreter onto a compiled language from the outside seems like a lot of work for questionable gain.

karmakaze 3y ago
The 'scripting' vs 'compiled' language is a false dichotomy. Awk, Perl, Python are compiled programs. What makes a 'scripting' language special? Dynamic typing? Lack of compile step/delay? I could imagine a lifetime of collecting scripting macros/libs in lisp to be as good or better.
- tempusr 3y ago
  Python is not a compiled language. However, the reason Bash is so prolific amongst Sys Admins such as myself is the fact that they are portable and reliable to use across Debian, Arch or RHEL based distributions. You don't have to import extra libraries, ensure that you are running the proper python environment, or be certain that pip is properly installed and configured for whatever extra source code beyond what is included out of the box. Bash is the most consistent code you can write to perform any task you need when you have to work with Linux.
  - dragonwriter 3y ago
    > Python is not a compiled language. Python is (at least in the CPython implementation) compiled, to python byte code which runs on the python virtual machine. Its not compiled to native code. (Unless you use one of the compilers which do compile it to native code, though they tend to support only a subset of python.)
  - LeBit 3y ago
    Bash is fine for small scripts. Once you use it to manage complex data structures and flow, you are simply wasting time because you will have to rewrite it in Python or Go.
  - pdimitar 3y ago
    Another commenter beat me to it but still: sh / bash / zsh are quite fine up until certain complexity (say 500 lines), after which adding even a single small feature becomes a huge drag. We're talking hours for something that would take me 10 minutes in Golang and 15 in Rust.
    - sgarland 3y ago
      I can actually agree with this take. Most of the opinions I've seen in this vein take some absurdly small limit, like 5 lines. 500, though? Yeah. My team rewrote a ProxySQL handler in Python because the bash version had gotten out of hand, and there were only a handful of people who could understand what it was doing. It passed 100% of spellcheck tests, and was as modular as it could possibly be, but modifying it was still an exercise in pain.
      - ruraljuror 3y ago
        > It passed 100% of spellcheck tests Just like your post does! :)
        sgarland 3y ago
        Ugh… Safari being overly helpful.
  - mbreese 3y ago
    > portable and reliable to use across Debian, Arch or RHEL based distributions Until you try to use a newer feature or try the script in a Mac or BSD or any older bash. SH code is completely portable, but bash itself can have quite a few novel features. Don’t get me wrong - I’m happy the language is dynamic and still growing. But it can make things awkward when trying to use a script from a newer system on an older server (and the author has been “clever”).
    - rascul 3y ago
      > SH code is completely portable Not exactly. https://stackoverflow.com/questions/11376975/is-there-a-minimally-posix-2-compliant-shell/16376043#16376043 https://stackoverflow.com/questions/11376975/is-there-a-mini...
  - sigjuice 3y ago
    The phrase "compiled language" doesn't mean anything. Python compilers exist.
  - DanielHB 3y ago
    Also the bash runtime is quite small, I think <2mb uncompressed so it is pretty much included in every distro Installing python or nodejs into your distro will inflate it by at least 30mb, quite crucial when dealing with containers
- paulddraper 3y ago
  Static typing is the key differentiator. That requires a level of bookkeeping which is helpful for large programs and a nuicense for small programs.
  - karmakaze 3y ago
    Closer to the truth is that static typing is a nuisance to a sole dev working in a short temporal period. Many successful startups get stuck with overgrown 'scripts' as platforms because it started as a one-man-programming shop. I do have to add that Python more than any other language I've used results in working the first try that it's not surprising.
- riku_iki 3y ago
  > Dynamic typing? actually amount of reasoning, which program requires to perform in run time is close to interpretion.
- heresie-dabord 3y ago
  > The 'scripting' vs 'compiled' language is a false dichotomy. Not false, but perhaps in need of better definition. The term script has often denoted a trivial set of commands run by $interpreter. "Scripting languages" have been seen as being in contrast to C, C++, Pascal, Java, SmallTalk, &c. The scripting languages remove from the user the need: -a- to think about an extensive type system, -b- to compile the logic, and -c- to build for a specific architecture.
  - fuzztester 3y ago
    >> The 'scripting' vs 'compiled' language is a false dichotomy. https://news.ycombinator.com/item?id=37206428 https://news.ycombinator.com/item?id=37206428
ajross 3y ago
> There are languages that are just simply better for one-off scripting (Perl, Python), and languages that aren't (anything compiled). Trying to bolt an interpreter onto a compiled language from the outside seems like a lot of work for questionable gain. One reason is deployment. Writing code in python/node/etc... implies the ability of the production environment to bootstrap a rather complicated installation tree for the elaborate runtimes required by the code and all its dependencies. And so there are elaborate tools (npm, venv, Docker, etc...) that have grown up around those requirements. Compiled languages (and Go in particular shines here) spit out a near-dependency-free[1] binary you can drop on the target without fuss. I deal with this in my day job pretty routinely. Chromebooks have an old python and limited ability to pull down dependencies for quick test runs. Static test binaries make things a lot easier. [1] Though there are shared libraries and runtime frameworks there too. You can't deploy a Gnome 3 app with the same freedom you can a TCP daemon, obviously.
- LeBit 3y ago
  I agree with you. But I think for python you could also deploy a binary with pyinstaller.
- nijave 3y ago
  > Compiled languages (and Go in particular shines here) spit out a near-dependency-free[1] binary you can drop on the target without fuss I think it's more accurate to say "static binaries" instead of "compiled languages." The same headaches exist with dynamically linked, compiled binaries (and sometimes they're worse since you don't have a dependency manager, unless you add one) > Static test binaries make things a lot easier I think this really depends on your target environment and how much control you have over it. If you're in a Ruby or Python shop, for example, all your servers already have the stack installed. If you're targeting end user devices, those can have a huge mess of different configs to account for
  - ajross 3y ago
    Meh. In my experience version churn with shared library dependencies is pretty minor. You have to worry about and work at it if you're doing stuff like deploying a single binary across a bunch of different linux distros. But the straightforward case of "build on your desktop and copy the file up to the host" is a routine thing you can expect to work. It's nothing like that with Python or Node. The rule there is that you get something working locally and then spend a while reverse engineering a pip/venv recipe or manifest or whatever to make it work somewhere else. It's decidedly non-trivial.
sgarland 3y ago
> The author even points out "programs as pipelines" which is literally the UNIX philosophy. Yes, and if the thing I'm trying to do has a small input, it will only be done once, etc. I will often just pipe `grep` to `sort` or whatever, because it's less typing, it's generally clearer to a wider range of people, etc. But on larger inputs, or even things like doing a single pattern inversion mixed with a pattern match, I like awk.
tomcam 3y ago
One reason the author could be doing this is to reduce dependencies. Maybe they deploy to Windows or to some other environment not guaranteed to have those utilities. Also testing probably gets simplified.

by zer8k 3y ago

karmakaze 3y ago

The 'scripting' vs 'compiled' language is a false dichotomy. Awk, Perl, Python are compiled programs. What makes a 'scripting' language special? Dynamic typing? Lack of compile step/delay? I could imagine a lifetime of collecting scripting macros/libs in lisp to be as good or better.

tempusr 3y ago
Python is not a compiled language. However, the reason Bash is so prolific amongst Sys Admins such as myself is the fact that they are portable and reliable to use across Debian, Arch or RHEL based distributions. You don't have to import extra libraries, ensure that you are running the proper python environment, or be certain that pip is properly installed and configured for whatever extra source code beyond what is included out of the box. Bash is the most consistent code you can write to perform any task you need when you have to work with Linux.
- dragonwriter 3y ago
  > Python is not a compiled language. Python is (at least in the CPython implementation) compiled, to python byte code which runs on the python virtual machine. Its not compiled to native code. (Unless you use one of the compilers which do compile it to native code, though they tend to support only a subset of python.)
- LeBit 3y ago
  Bash is fine for small scripts. Once you use it to manage complex data structures and flow, you are simply wasting time because you will have to rewrite it in Python or Go.
- pdimitar 3y ago
  Another commenter beat me to it but still: sh / bash / zsh are quite fine up until certain complexity (say 500 lines), after which adding even a single small feature becomes a huge drag. We're talking hours for something that would take me 10 minutes in Golang and 15 in Rust.
  - sgarland 3y ago
    I can actually agree with this take. Most of the opinions I've seen in this vein take some absurdly small limit, like 5 lines. 500, though? Yeah. My team rewrote a ProxySQL handler in Python because the bash version had gotten out of hand, and there were only a handful of people who could understand what it was doing. It passed 100% of spellcheck tests, and was as modular as it could possibly be, but modifying it was still an exercise in pain.
    - ruraljuror 3y ago
      > It passed 100% of spellcheck tests Just like your post does! :)
      - sgarland 3y ago
        Ugh… Safari being overly helpful.
- mbreese 3y ago
  > portable and reliable to use across Debian, Arch or RHEL based distributions Until you try to use a newer feature or try the script in a Mac or BSD or any older bash. SH code is completely portable, but bash itself can have quite a few novel features. Don’t get me wrong - I’m happy the language is dynamic and still growing. But it can make things awkward when trying to use a script from a newer system on an older server (and the author has been “clever”).
  - rascul 3y ago
    > SH code is completely portable Not exactly. https://stackoverflow.com/questions/11376975/is-there-a-minimally-posix-2-compliant-shell/16376043#16376043 https://stackoverflow.com/questions/11376975/is-there-a-mini...
- sigjuice 3y ago
  The phrase "compiled language" doesn't mean anything. Python compilers exist.
- DanielHB 3y ago
  Also the bash runtime is quite small, I think <2mb uncompressed so it is pretty much included in every distro Installing python or nodejs into your distro will inflate it by at least 30mb, quite crucial when dealing with containers
paulddraper 3y ago
Static typing is the key differentiator. That requires a level of bookkeeping which is helpful for large programs and a nuicense for small programs.
- karmakaze 3y ago
  Closer to the truth is that static typing is a nuisance to a sole dev working in a short temporal period. Many successful startups get stuck with overgrown 'scripts' as platforms because it started as a one-man-programming shop. I do have to add that Python more than any other language I've used results in working the first try that it's not surprising.
riku_iki 3y ago
> Dynamic typing? actually amount of reasoning, which program requires to perform in run time is close to interpretion.
heresie-dabord 3y ago
> The 'scripting' vs 'compiled' language is a false dichotomy. Not false, but perhaps in need of better definition. The term script has often denoted a trivial set of commands run by $interpreter. "Scripting languages" have been seen as being in contrast to C, C++, Pascal, Java, SmallTalk, &c. The scripting languages remove from the user the need: -a- to think about an extensive type system, -b- to compile the logic, and -c- to build for a specific architecture.
- fuzztester 3y ago
  >> The 'scripting' vs 'compiled' language is a false dichotomy. https://news.ycombinator.com/item?id=37206428 https://news.ycombinator.com/item?id=37206428

ajross 3y ago

> There are languages that are just simply better for one-off scripting (Perl, Python), and languages that aren't (anything compiled). Trying to bolt an interpreter onto a compiled language from the outside seems like a lot of work for questionable gain. One reason is deployment. Writing code in python/node/etc... implies the ability of the production environment to bootstrap a rather complicated installation tree for the elaborate runtimes required by the code and all its dependencies. And so there are elaborate tools (npm, venv, Docker, etc...) that have grown up around those requirements. Compiled languages (and Go in particular shines here) spit out a near-dependency-free[1] binary you can drop on the target without fuss. I deal with this in my day job pretty routinely. Chromebooks have an old python and limited ability to pull down dependencies for quick test runs. Static test binaries make things a lot easier. [1] Though there are shared libraries and runtime frameworks there too. You can't deploy a Gnome 3 app with the same freedom you can a TCP daemon, obviously.

LeBit 3y ago
I agree with you. But I think for python you could also deploy a binary with pyinstaller.
nijave 3y ago
> Compiled languages (and Go in particular shines here) spit out a near-dependency-free[1] binary you can drop on the target without fuss I think it's more accurate to say "static binaries" instead of "compiled languages." The same headaches exist with dynamically linked, compiled binaries (and sometimes they're worse since you don't have a dependency manager, unless you add one) > Static test binaries make things a lot easier I think this really depends on your target environment and how much control you have over it. If you're in a Ruby or Python shop, for example, all your servers already have the stack installed. If you're targeting end user devices, those can have a huge mess of different configs to account for
- ajross 3y ago
  Meh. In my experience version churn with shared library dependencies is pretty minor. You have to worry about and work at it if you're doing stuff like deploying a single binary across a bunch of different linux distros. But the straightforward case of "build on your desktop and copy the file up to the host" is a routine thing you can expect to work. It's nothing like that with Python or Node. The rule there is that you get something working locally and then spend a while reverse engineering a pip/venv recipe or manifest or whatever to make it work somewhere else. It's decidedly non-trivial.

sgarland 3y ago

> The author even points out "programs as pipelines" which is literally the UNIX philosophy. Yes, and if the thing I'm trying to do has a small input, it will only be done once, etc. I will often just pipe `grep` to `sort` or whatever, because it's less typing, it's generally clearer to a wider range of people, etc. But on larger inputs, or even things like doing a single pattern inversion mixed with a pattern match, I like awk.

tomcam 3y ago

One reason the author could be doing this is to reduce dependencies. Maybe they deploy to Windows or to some other environment not guaranteed to have those utilities. Also testing probably gets simplified.