4 ms·

I really thought you were being facetious comparing bash and forking to bitcoin. Shell scripts aren't so terrible and you wouldn't use them in performance criti

by js2 7y ago

I really thought you were being facetious comparing bash and forking to bitcoin. Shell scripts aren't so terrible and you wouldn't use them in performance critical scenarios. It's not like all our CPUs are running at 100% utilization. You're talking to someone who ran a web farm in the 90s so yeah, I saw the evolution from CGI to mod-perl and on. I mean I know the cost of forking. But come on, aren't you taking your criticism a bit far? I also had an Apple ][+. Actually, one wasn't available so we Frankensteined one together from an Apple ][ and an Applesoft language card by swapping the motherboard ROMs and language card ROMs.

DonHopkins 7y ago
As long as people don't understand how wasteful and inefficient bash scripts are, I haven't taken my criticism far enough. ;) We both have some perspective from the Apple ][ days, and can appreciate how astronomically fast computers are compared to how slow they used to be. But doesn't it give you pause (literally and figuratively) when you see people thoughtlessly and casually write code in 2019 that runs slower on a high-end MacBook Pro than the equivalent code would run on an Apple ][ in 1979? People should take a momemt to reflect on what they're trying to accomplish and if there are better ways of going about it, before writing Rube-Goldbergesqe bash scripts heavily punctuated with line noise, haphazardly stringing together Unix processes and temporary files with cryptically abbreviated commands using mysteriously curt flags and parameters (like "dc -l", or is it "bc -l", and is that dash-ell or dash-one? I can't remember, and we haven't even gotten to the part about how I have to quote and escape the arithmetic expression parameter)! It's not as if they're making thoughtful trade-offs, and that as a result of choosing to use bash despite all its weaknesses, they're actually developing more robust, easier to read and maintain code than they would have had they used Python.
- civility 7y ago
  Promoting Python over shell scripts in the name of efficiency is silly. It's like saying you should prefer turtles instead of snails.
  - DonHopkins 7y ago
    Thanks for illustrating how some people still completely miss the point. We are discussing the overhead of forking processes to do math, which Python doesn't have to do. You're making a false equivalence like "there is slow arithmetic on both sides". No: one side is astronomically slow, requiring millions of instructions, the other side is tolerably slow, requiring hundreds of instructions. There is no comparison. Again, this isn't about Python. That's just an example. It's about forking or not forking. You know, the topic of this thread. If you like, I could translate my Python argument to JavaScript, and you could explain how a bash JIT compiler could optimize out all the instructions necessary to fork "bc" to call the cos instruction. Let me head you off at the pass before you ask "Why would I ever want to calculate a cosine in a bash script?" when you should be asking "Why would I ever want to use a language that doesn't let me calculate a cosine? Or even draw a circle?" To illustrate my point: Perhaps you want to write a script that draws a pie chart to illustrate your disk space. That's a typical sysadminy scripty thing to do, right? With bash, you'd have to call out to many other processes to do that. Why is that? Tell me why hasn't anyone come up with a way to draw like the canvas API in bash, without forking off dozens if not thousands of processes? Don't you think floating point would be useful for calculating disk space usage more accurately than integer percentages, and the canvas api would be useful for drawing pie charts? If you think you'd never need to do something like that in bash, then you have an enormous blind spot from bash tragically lowering your expectations, imagination, and productivity as a programmer. Because bash can't even perform the simplest APPLESOFT BASIC floating point math operations or HGR hires graphics HPLOT drawing commands. So you would first have to fork off to one process to multiply and add a few numbers and calculate a cosine, and then you'd have to fork off to another process to multiply and add a few numbers and calculate a sin (because "bc" can only return one result at a time, thank you). Then you would have to pass those numbers to another program to draw them, probably with a here-file, some loops, a bunch of variable substitutions, temporary variables, intermediate files, lots and lots of string concatenation, converting back and forth between binary floating point numbers and strings, all meticulously decorated with a phalanx of quotes, escapes, double and triple backslashes, back-ticks, colons and exclamation marks before single character codes, and double secret parenthesis.
    - 7y ago

by js2 7y ago

DonHopkins 7y ago

As long as people don't understand how wasteful and inefficient bash scripts are, I haven't taken my criticism far enough. ;) We both have some perspective from the Apple ][ days, and can appreciate how astronomically fast computers are compared to how slow they used to be. But doesn't it give you pause (literally and figuratively) when you see people thoughtlessly and casually write code in 2019 that runs slower on a high-end MacBook Pro than the equivalent code would run on an Apple ][ in 1979? People should take a momemt to reflect on what they're trying to accomplish and if there are better ways of going about it, before writing Rube-Goldbergesqe bash scripts heavily punctuated with line noise, haphazardly stringing together Unix processes and temporary files with cryptically abbreviated commands using mysteriously curt flags and parameters (like "dc -l", or is it "bc -l", and is that dash-ell or dash-one? I can't remember, and we haven't even gotten to the part about how I have to quote and escape the arithmetic expression parameter)! It's not as if they're making thoughtful trade-offs, and that as a result of choosing to use bash despite all its weaknesses, they're actually developing more robust, easier to read and maintain code than they would have had they used Python.

civility 7y ago
Promoting Python over shell scripts in the name of efficiency is silly. It's like saying you should prefer turtles instead of snails.
- DonHopkins 7y ago
  Thanks for illustrating how some people still completely miss the point. We are discussing the overhead of forking processes to do math, which Python doesn't have to do. You're making a false equivalence like "there is slow arithmetic on both sides". No: one side is astronomically slow, requiring millions of instructions, the other side is tolerably slow, requiring hundreds of instructions. There is no comparison. Again, this isn't about Python. That's just an example. It's about forking or not forking. You know, the topic of this thread. If you like, I could translate my Python argument to JavaScript, and you could explain how a bash JIT compiler could optimize out all the instructions necessary to fork "bc" to call the cos instruction. Let me head you off at the pass before you ask "Why would I ever want to calculate a cosine in a bash script?" when you should be asking "Why would I ever want to use a language that doesn't let me calculate a cosine? Or even draw a circle?" To illustrate my point: Perhaps you want to write a script that draws a pie chart to illustrate your disk space. That's a typical sysadminy scripty thing to do, right? With bash, you'd have to call out to many other processes to do that. Why is that? Tell me why hasn't anyone come up with a way to draw like the canvas API in bash, without forking off dozens if not thousands of processes? Don't you think floating point would be useful for calculating disk space usage more accurately than integer percentages, and the canvas api would be useful for drawing pie charts? If you think you'd never need to do something like that in bash, then you have an enormous blind spot from bash tragically lowering your expectations, imagination, and productivity as a programmer. Because bash can't even perform the simplest APPLESOFT BASIC floating point math operations or HGR hires graphics HPLOT drawing commands. So you would first have to fork off to one process to multiply and add a few numbers and calculate a cosine, and then you'd have to fork off to another process to multiply and add a few numbers and calculate a sin (because "bc" can only return one result at a time, thank you). Then you would have to pass those numbers to another program to draw them, probably with a here-file, some loops, a bunch of variable substitutions, temporary variables, intermediate files, lots and lots of string concatenation, converting back and forth between binary floating point numbers and strings, all meticulously decorated with a phalanx of quotes, escapes, double and triple backslashes, back-ticks, colons and exclamation marks before single character codes, and double secret parenthesis.
  - 7y ago