5 ms·

1. Most people who interact with a shell know how to make it run one command with arguments; some eventually learn about IO redirection. Many such people who us

1. Most people who interact with a shell know how to make it run one command with arguments; some eventually learn about IO redirection. Many such people who use Bash as a "command prompt" would find the way it does even simple things like variables and conditionals exceedingly arcane. Readability is important, and, for better or worse, a compact curly bracket syntax is seen as "the norm". 2. Different languages' standard libraries have different scopes. Node's is just right for the task at hand. 3. I know many people who disagree with me, too. That doesn't make me wrong (or right ;-)). 4. Why not? Doing a task and displaying a rich progress indicator is doing two tasks. Glue is a continuum - for me, the concept includes orchestration of external "heavy lifting" tasks according to the desired logic, as well as processing intermediary outputs in simple ways so the whole pipeline fits together. 5. Well, I've evaluated it and found it to my liking. I guess you grow to like the tools you use to accomplish things, and if everyone who went out of their way to publicly dismiss Node.js instead went out of their way to use it in place of Bash scripting, they might find it to their liking as well. 6. Yet ironically, it has been the most reliable in achieving its purpose of locking my encrypted partitions when my computer goes to sleep, not to mention unlocking them when I wake it up. 7. Exactly - but people keep pulling this and other quirks out of their ass as "proof" JavaScript is some horrible language. Show me a shell scripting language that even has floating point arithmetic! But maybe glue code can't ever need that, either?

hnlmorg 7y ago
> Readability is important, and, for better or worse, a compact curly bracket syntax is seen as "the norm". Python seems pretty popular. > I know many people who disagree with me, too. That doesn't make me wrong The problem isn't that you're saying node is well suited. The problem was your suggestion that node was uniquely well suited when actually the CLI is a solved problem in most languages. > Well, I've evaluated it and found it to my liking. That's all that really matters when it comes to your own personal usage. Just don't expect everyone to have those same preferences nor argue with other developers that your preferences are any kind of "fact". > I guess you grow to like the tools you use to accomplish things, and if everyone who went out of their way to publicly dismiss Node.js instead went out of their way to use it in place of Bash scripting, they might find it to their liking as well. Personally I don't like node and find Bash easier however it's thankfully not an "either/or" argument where your only options are Javascript or Bash. There's a whole plethora of options out there. > Yet ironically, it has been the most reliable in achieving its purpose of locking my encrypted partitions when my computer goes to sleep, not to mention unlocking them when I wake it up. That's a pretty meaningless anecdote because it could be the result of a whole plethora of reasons outside of the language's control (including but not limited to user error) or even completely made up (like your point about floating point arithmetic (see below) or your other comment about one liners being more readable than multi-lined code). > Show me a shell scripting language that even has floating point arithmetic! Quite a few do: ksh93, yash, zsh and murex (disclaimer: I wrote that shell) are all interactive shells which support floating point arithmetic. In terms of shell scripting languages, you can add the following to the above group: awk, bc, dc and perl. Even those shells that don't support floating point arithmetic can still do pseudo floating point maths by using powers of 10 multipliers and printf to place the decimal point: printf %.10f\\n "$((1000000000 * 365/7))e-9" Ok, I'll grant you that is rather ugly. Thankfully you can call other shell scripting languages from within your POSIX/C shell: bc <<< "scale=10; 365/7" This isn't a hard thing to research either; which suggests to me you haven't done your homework before making your arguments.
- deleted 7y ago
  [deleted]
- w56rjrtyu6ru 7y ago
  > Python seems pretty popular. One reason it's so popular: even though it skips the actual curly brackets (thus making itself more accessible), it doesn't stray too far from the general syntactic paradigm of "curly-bracket languages'" - even though I've also seen people being alienated by the idea of "significant whitespace", again for no other reason but that it "seems wrong" to them. > The problem was your suggestion that node was uniquely well suited No, just much better suited than people give it credit for. And this ecosystem brings new things to the table, too. > when actually the CLI is a solved problem in most languages. Being able to build a CLI at all? I guess, sure. Being able to quickly build an accessible CLI? Hardly so. Everything in the area of HCI is in flux, and gatekeeping the CLI domain for does more harm than good. Btw do you know anyone doing this sort of interface before Yeoman? https://github.com/synox/youtube-dl-interactive/raw/master/d.. https://github.com/synox/youtube-dl-interactive/raw/master/d.... before JS. > There's a whole plethora of options out there. Which is why you've got to take into account opportunity cost, choice paralysis, etc. All of the options out there are positively fascinating, but if I have the options to solve problems in multiple contexts with the same familiar tool, I tend to usually go for it. > Quite a few do: ksh93, yash, zsh and murex (disclaimer: I wrote that shell) are all interactive shells which support floating point arithmetic. None of which are POSIX, or common defaults? > In terms of shell scripting languages, you can add the following to the above group: awk, bc, dc None of which are shells - they're DSLs you can call into from the shell. > perl Again, not really a shell. Though I wouldn't be surprised if anyone's using it as one. > bc <<< "scale=10; 365/7" > 365/7 Even though these tools have a good reason to be like this, having to _research_ how to _call out to an external executable_ to do something as trivial as floating point division (in the sense of "cmon man I can do this in my head, why does is it have to be so hard to tell a computer to do it") is hardly on anyone's list of priorities. At this point, nearly anyone would rather reach for the scripting language they're already familiar with, rather than learn an unfamiliar one just because it has historically dominated the problem domain. > one liners being more readable than multi-lined code Admittedly, that was a pretty bullshit argument. Not any less nuanced than "[l]ine counts mean jack shit", either - I take it as a general rule that one would prefer to write less code. And I'm not weighing any of the examples against "[c]ode golfing, minifified code, shell 1 liners, Perl, etc. I didn't really take into account the extra functionality of the Go version - it was just as unreliable as the Bash one so I quickly discarded it when I found something that worked. There's a story behind this comparison. It was likely user error, in the sense I failed to prepare my initramfs correctly using mkinitcpio or dracut (incidentally, both of those being shell scripts - insufficiently documented and not very readable to my untrained eye, either) But the JavaScript version worked for me because it didn't even try to chroot into the initramfs - it just moves a tiny handful of required binaries into a ramdisk, and works from that. Since that solution _works_, I am hard pressed not to commend its minimalism. Is it inconceivable that that the author was not more clever, but the tools that they used enabled them to come up with a simpler solution in the time that would've otherwise been spent googling `bc` or poring over the sources of initramfs builders?

hnlmorg 7y ago

> Readability is important, and, for better or worse, a compact curly bracket syntax is seen as "the norm". Python seems pretty popular. > I know many people who disagree with me, too. That doesn't make me wrong The problem isn't that you're saying node is well suited. The problem was your suggestion that node was uniquely well suited when actually the CLI is a solved problem in most languages. > Well, I've evaluated it and found it to my liking. That's all that really matters when it comes to your own personal usage. Just don't expect everyone to have those same preferences nor argue with other developers that your preferences are any kind of "fact". > I guess you grow to like the tools you use to accomplish things, and if everyone who went out of their way to publicly dismiss Node.js instead went out of their way to use it in place of Bash scripting, they might find it to their liking as well. Personally I don't like node and find Bash easier however it's thankfully not an "either/or" argument where your only options are Javascript or Bash. There's a whole plethora of options out there. > Yet ironically, it has been the most reliable in achieving its purpose of locking my encrypted partitions when my computer goes to sleep, not to mention unlocking them when I wake it up. That's a pretty meaningless anecdote because it could be the result of a whole plethora of reasons outside of the language's control (including but not limited to user error) or even completely made up (like your point about floating point arithmetic (see below) or your other comment about one liners being more readable than multi-lined code). > Show me a shell scripting language that even has floating point arithmetic! Quite a few do: ksh93, yash, zsh and murex (disclaimer: I wrote that shell) are all interactive shells which support floating point arithmetic. In terms of shell scripting languages, you can add the following to the above group: awk, bc, dc and perl. Even those shells that don't support floating point arithmetic can still do pseudo floating point maths by using powers of 10 multipliers and printf to place the decimal point: printf %.10f\\n "$((1000000000 * 365/7))e-9" Ok, I'll grant you that is rather ugly. Thankfully you can call other shell scripting languages from within your POSIX/C shell: bc <<< "scale=10; 365/7" This isn't a hard thing to research either; which suggests to me you haven't done your homework before making your arguments.

deleted 7y ago
[deleted]
w56rjrtyu6ru 7y ago
> Python seems pretty popular. One reason it's so popular: even though it skips the actual curly brackets (thus making itself more accessible), it doesn't stray too far from the general syntactic paradigm of "curly-bracket languages'" - even though I've also seen people being alienated by the idea of "significant whitespace", again for no other reason but that it "seems wrong" to them. > The problem was your suggestion that node was uniquely well suited No, just much better suited than people give it credit for. And this ecosystem brings new things to the table, too. > when actually the CLI is a solved problem in most languages. Being able to build a CLI at all? I guess, sure. Being able to quickly build an accessible CLI? Hardly so. Everything in the area of HCI is in flux, and gatekeeping the CLI domain for does more harm than good. Btw do you know anyone doing this sort of interface before Yeoman? https://github.com/synox/youtube-dl-interactive/raw/master/d.. https://github.com/synox/youtube-dl-interactive/raw/master/d.... before JS. > There's a whole plethora of options out there. Which is why you've got to take into account opportunity cost, choice paralysis, etc. All of the options out there are positively fascinating, but if I have the options to solve problems in multiple contexts with the same familiar tool, I tend to usually go for it. > Quite a few do: ksh93, yash, zsh and murex (disclaimer: I wrote that shell) are all interactive shells which support floating point arithmetic. None of which are POSIX, or common defaults? > In terms of shell scripting languages, you can add the following to the above group: awk, bc, dc None of which are shells - they're DSLs you can call into from the shell. > perl Again, not really a shell. Though I wouldn't be surprised if anyone's using it as one. > bc <<< "scale=10; 365/7" > 365/7 Even though these tools have a good reason to be like this, having to _research_ how to _call out to an external executable_ to do something as trivial as floating point division (in the sense of "cmon man I can do this in my head, why does is it have to be so hard to tell a computer to do it") is hardly on anyone's list of priorities. At this point, nearly anyone would rather reach for the scripting language they're already familiar with, rather than learn an unfamiliar one just because it has historically dominated the problem domain. > one liners being more readable than multi-lined code Admittedly, that was a pretty bullshit argument. Not any less nuanced than "[l]ine counts mean jack shit", either - I take it as a general rule that one would prefer to write less code. And I'm not weighing any of the examples against "[c]ode golfing, minifified code, shell 1 liners, Perl, etc. I didn't really take into account the extra functionality of the Go version - it was just as unreliable as the Bash one so I quickly discarded it when I found something that worked. There's a story behind this comparison. It was likely user error, in the sense I failed to prepare my initramfs correctly using mkinitcpio or dracut (incidentally, both of those being shell scripts - insufficiently documented and not very readable to my untrained eye, either) But the JavaScript version worked for me because it didn't even try to chroot into the initramfs - it just moves a tiny handful of required binaries into a ramdisk, and works from that. Since that solution _works_, I am hard pressed not to commend its minimalism. Is it inconceivable that that the author was not more clever, but the tools that they used enabled them to come up with a simpler solution in the time that would've otherwise been spent googling `bc` or poring over the sources of initramfs builders?