91–95 of 95 posts
Earlier quoted context omitted.
I have been a user for many years and it feels like the distro package works at least 51/52 weeks a year, so I'm not sure it's an issue more than with any other package.
Rolling release or every six months?
Earlier quoted context omitted.
In absence of more accessible complexity measurements, line counts do matter somewhat. E.g. the briefer a program is, the more readable it is (last time I checked, brainpower and time is much more expensive than computing power and bandwidth.) The Node example has zero external dependencies outside of the Node.js standard library.
Well, compared to a shell script or a static binary...the Node example requires you to have Node (+ NPM) on your machine and, unless you wrap it all up for homebrew/apt/some other package repo. you're going to be using `npm install -g` to use it as opposed to shoving an executable into your PATH. All of your stated benefits are nice for the maintainer but mean little to the end user. This gushing praise for Node read…
> All of your stated benefits are nice for the maintainer but mean little to the end user. I fail to see how better tools for authors and maintainers don't result in better software for end users.
> This gushing praise for Node reads like nobody has ever built elegant CLI apps until Ryan Dahl turned of age and put JS on a server. And what of it? Node makes building CLI apps accessible to an ever wider audience. I'm just putting my "glowing review" out there to counteract all the naysayers who like to piss on Node because it's JavaScript, usually without even _attempting_ to make an argumented case against it.
Earlier quoted context omitted.
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' sta…
> 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…
Earlier quoted context omitted.
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' sta…
> 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…
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 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?
Earlier quoted context omitted.
> 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…
> 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 suggesti…
All you're describing there is structured programming languages. Of course people like structured languages, that's why nearly every single programming language developed in the last 40 years (that isn't designed to interface directly with hardware) is structured. Even languages of entirely different paradigms such as Common Lisp, LOGO, Prolog, MATLAB and Forth all support structured control flows. Even BASIC - for all it's warts - supported structured logic (even if many implementations lacked proper functions).
So you're not making a convincing argument about curly braces now you've redefined the argument as structured control flows.
> No, just much better suited than people give it credit for. And this ecosystem brings new things to the table, too.
Maybe. My personal opinion is the unmanageable nest of unvetted dependencies makes it a worse solution than people give it credit for. As a pure dev tool for personal use, go for it. But I don't want to read 10k+ lines of code in the dependencies of a tool that's ostensibly just an interactive alias.
I get the whole "standing on the shoulders of giants" thing but it's gotten out of hand with node. Half the time even people writing code in node don't know what dependencies their dependencies are pulling in. All that trust placed in an ecosystem that is very easy to abuse (and has been abused too). So no thanks, I don't think that's the right tool for serious CLI work which often needs to be run on trusted machines.
> Being able to build a CLI at all? I guess, sure. Being able to quickly build an accessible CLI? Hardly so.
Actually yes. I've been writing software for 30 year in well over a dozen different languages. Much, not all but a reasonable amount of that, was writing software for servers.
> Everything in the area of HCI is in flux
Not in terms of the CLI. We're using the same standards that were defined in the 60s. If anything, the problem with the CLI is that it's engineered around design principles which are no longer relevant to modern terminals. For example:
* we no longer need to inline formatting with escape sequences - we have better markups for that.
* ASCII is no longer relevant in our international community with different writing languages and character sets.
* Terminals are no longer teletypes - there's no reason why we shouldn't be able to inline multimedia content
* Terminals are no longer teletypes - we shouldn't need to be defining TTYs/PTYs as an OS abstraction
* Defining TTYs is OS specific and a fucking mess on even some of the better designed UNIXes
* Capturing and sending signals can often be OS specific and a fucking mess to work with on even some of the better designed UNIXes
* Not all OSs even support the same suite of signals
* Signal hotkeys can't even be redefined - which means you can't always compensate for one OS missing a signal that another might have. The best you can do is enable or disable the capture of that hotkey on the TTY. Which again requires OS specific syscalls
* POSIX pipes are just byte streams. Which makes working with structured data a fucking nightmare (hence why Powershell, jq and murex all exist)
* stderr is a lousy way of capturing errors
* in fact error handling on the whole is just terrible on POSIX shells (hence why murex exists)
* POSIX shells don't support any kind of unit testing (again, hence why murex exists)
* exit numbers are a half arsed solution
* named pipes are a file system kludge
* TTY modes can get broken if a fork()ed process changes the mode and crashes for forgets to reset it on exit. Meaning your shell then becomes non-functional without manually fork()ing `reset`
* ANSI escape sequences are anything but standardised. With different terminal emulators often doing significantly different things
So no, the CLI definitely is not in a state of flux. The exact opposite of that in fact.
More likely is the Javascript libraries you're using for CLI work is in a constant state of flux. This was a problem I had when I used to write software in node and it's one of many personal reasons I decided against using it for anything I really cared about.
> 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.
That makes no sense. Last week you were saying it couldn't be done and now you're saying the problem is too much choice. Make your mind up.
> [ksh93, yash, zsh and murex] None of which are POSIX, or common defaults?
You didn't say "POSIX shells", you said "shell scripting languages"
Also node isn't a common default either.
> [Perl] Again, not really a shell. Though I wouldn't be surprised if anyone's using it as one.
Again you didn't say "POSIX shells", you said "shell scripting languages". You can very much use Perl as a shell scripting language (and that is in fact still a common use case for it).
> 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.
Actually computers can't do proper floating point arithmetic (in the sense that humans do) either. That's why a lot of languages (and spreadsheets too) demonstrate seemingly broken logic when comparing floating point numbers.
> 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.
Line counts literally do mean jack shit. There are plenty of examples of where more lines equal better code. As a developer you should already know this.