-12 karma · joined May 27, 2019
I'm hooked on SVG's promise of semantic graphics, but every time I tried building something with SVG in a browser the performance just wasn't there, especially on low-end devices.
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.... 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?
Nevertheless, it is you who choose to engage with my comments on such a dismissive note. I am prepared that my statements will initially be called ridiculous, but speaking one's mind is a great way to learn faster and there's always plenty to catch up with.
But of course, scary symbols is scary.
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?
The Node example has zero external dependencies outside of the Node.js standard library.
One of the downsides is that when you show your code to other developers who don't have the necessary visual bandwidth, they get uncomfortable.
One of the few things syntax highlighting actually helps with is for catching typos in keywords. (To the trained eye, this could be replaced with just bolding or italicizing the keywords.)
Today I'm using "the colorful words" again (as non-technical associates have described syntax highlighted code), and still looking for a syntax highlighting theme which does not look like crap. (Gruvbox is the closest I've gotten yet.)
Giving each identifier its own color (e.g. https://medium.com/@evnbr/coding-in-color-3a6db2743a1e) is another interesting idea.
* Familiar syntax and semantics (Bash/Zsh/Fish/Csh/Ksh/Ash/Wtfsh are all way weirder than JS - and they are _only_ scripting languages, while JS is already everywhere)
* Standard library (https://nodejs.org/dist/latest-v12.x/docs/api/fs.html) gives you access to POSIX APIs ("batteries included" - but not bloated)
* Sane packaging, package management, and ecosystem (overreliance on third-party module is a thing exactly because NPM works with much less friction than e.g. the Python situation)
* Asynchronous event model lets you safely do multiple things in parallel without worrying about low-level memory management, or which concurrency boilerplate library to use, etc.
All in all, it's the perfect Unix glue. All it misses is a mature S-expression-based syntax.
For example, take the problem of locking your encrypted partitions before suspending your Linux machine. Since distro developers are too "busy" to provide what one might say is basic functionality, power users took matters in their own hands and wrote this 100-ish line Bash script (https://github.com/vianney/arch-luks-suspend), which evolved into this 1500-ish line Go monstrosity (https://github.com/guns/go-luks-suspend)... as well as these ~75 lines of Node.js (https://github.com/egasimus/node-luks-suspend).
But yeah, sure, hurr durr JaavaaScriipt baad, 0.1+0.2!==0.3, 'true'==true, etc... The horror!