3 ms·

Different tools serve different purposes. Just because you wouldn't write a web browser/server/IDE/OS in a shell scripting language doesn't mean they don't have

Different tools serve different purposes. Just because you wouldn't write a web browser/server/IDE/OS in a shell scripting language doesn't mean they don't have value or are failed paradigms. I've written tons of shell scripts for one-off jobs or simple work that would've taken 2, 3, maybe 4 times the amount the time to write in a "real" programming language. (E.g. throwaway code to generate 10,000 test files that are slightly different would take me 5-10 minutes in bash, but maybe half an hour in node or python.) Passing around strings isn't the BEST paradigm but it's extremely flexible when you need flexibility. There are times when you need something more solid and that's fine too. And fwiw I'd bet a majority of the software you listed uses bash somewhere in either their build process or SAAS stack.

shatteredgate 5y ago
On the projects I've hacked on, a lot of time has been spent trying to replace bash and autotools in the build process and reduce its usage. They are brittle and nobody really likes to maintain giant shell scripts filled with fragile regular expressions and other unreadable awk invocations. Plus I've lost count of the number of build scripts I've seen that do strange things like failing to handle spaces in paths because something is not escaped correctly. They are really not a good solution. This can be caught with CI, but if you use any kind of CI then you have even more incentive to get rid of it because bash and makefiles (which fork an additional shell on every command) are very slow.
throw10920 5y ago
Different tools serve different purposes, yes. However, some tools have much narrower uses than others. For instance, most developers agree that writing programs in assembly language is a very bad idea for about 99.9% of programs (1 out of 1000 - which is generous). And, from both empirical evidence, and reasoning from first principles (stringly-typed, quoting and escaping issues, lack of tooling, low performance, implementation-defined behaviors, poor ecosystem, try-to-continue instead of fail-quick design), we can see that shell is entirely unsuited for everything except interactive use. Moreover, "time to write script" by itself is a bad metric, for several reasons: (1) the cost of understanding and maintaining the script is ignored (and obviously higher for bash than Python) (2) you're not including the higher likelihood of bugs in your bash programs (and all it takes is a single bug that requires 20 minutes to find and fix...) (3) if you had more experience with Python (or with specific libraries useful for writing shell-script-like things - this often goes overlooked) then your development time would probably be shorter and (4) the pool of Python devs is far greater than the pool of bash devs. > Passing around strings...[is] extremely flexible when you need flexibility This isn't accurate. Passing around typed data is just as flexible as strings - except that it adds a bunch of extra safety and type-checks. All data in "string" format, with the singular exception of actual English text that is being passed to an NLP system or something, is actually in a structured text format (the operations that you perform on which are merely isomorphic to existing operations on structured data)...that is very likely under-specified relative and more brittle than actual typed data. All that using a string representation does is make errors easier to make and harder to find. > And fwiw I'd bet a majority of the software you listed uses bash somewhere in either their build process or SAAS stack. Yes, because bash is a (bad) habit for tooling devs, not because it scales well or adds safety/performance/maintainability - as evidenced by the fact that there aren't any large pieces of software written in it. That is - bash is used "somewhere" and not "everywhere" because you can only get away with it at small scales - at large scales, it just falls apart.

shatteredgate 5y ago

On the projects I've hacked on, a lot of time has been spent trying to replace bash and autotools in the build process and reduce its usage. They are brittle and nobody really likes to maintain giant shell scripts filled with fragile regular expressions and other unreadable awk invocations. Plus I've lost count of the number of build scripts I've seen that do strange things like failing to handle spaces in paths because something is not escaped correctly. They are really not a good solution. This can be caught with CI, but if you use any kind of CI then you have even more incentive to get rid of it because bash and makefiles (which fork an additional shell on every command) are very slow.

throw10920 5y ago

Different tools serve different purposes, yes. However, some tools have much narrower uses than others. For instance, most developers agree that writing programs in assembly language is a very bad idea for about 99.9% of programs (1 out of 1000 - which is generous). And, from both empirical evidence, and reasoning from first principles (stringly-typed, quoting and escaping issues, lack of tooling, low performance, implementation-defined behaviors, poor ecosystem, try-to-continue instead of fail-quick design), we can see that shell is entirely unsuited for everything except interactive use. Moreover, "time to write script" by itself is a bad metric, for several reasons: (1) the cost of understanding and maintaining the script is ignored (and obviously higher for bash than Python) (2) you're not including the higher likelihood of bugs in your bash programs (and all it takes is a single bug that requires 20 minutes to find and fix...) (3) if you had more experience with Python (or with specific libraries useful for writing shell-script-like things - this often goes overlooked) then your development time would probably be shorter and (4) the pool of Python devs is far greater than the pool of bash devs. > Passing around strings...[is] extremely flexible when you need flexibility This isn't accurate. Passing around typed data is just as flexible as strings - except that it adds a bunch of extra safety and type-checks. All data in "string" format, with the singular exception of actual English text that is being passed to an NLP system or something, is actually in a structured text format (the operations that you perform on which are merely isomorphic to existing operations on structured data)...that is very likely under-specified relative and more brittle than actual typed data. All that using a string representation does is make errors easier to make and harder to find. > And fwiw I'd bet a majority of the software you listed uses bash somewhere in either their build process or SAAS stack. Yes, because bash is a (bad) habit for tooling devs, not because it scales well or adds safety/performance/maintainability - as evidenced by the fact that there aren't any large pieces of software written in it. That is - bash is used "somewhere" and not "everywhere" because you can only get away with it at small scales - at large scales, it just falls apart.