3 ms·

I agree with the sentiment of this post and have felt this pain. Interestingly I find that notation and syntax are the first, and most powerful, justification f

I agree with the sentiment of this post and have felt this pain. Interestingly I find that notation and syntax are the first, and most powerful, justification for the new tools. Honest to god blockers to adoption I've witnessed: 1. Makefiles and/or bash scripts are not written in javascript 2. Man pages are not web based 3. The dense syntax of command line tool options is intimidating I also have a strong sympathy with the position that UX matters at all levels of tool building and its hard to argue that older tools are as approachable, literate, or aesthetically appealing as newer tools. The real tragedy is that it is so difficult to update the UX, syntax and aesthetics of older tools while maintaining the hard-won stability and separation of concerns they embody.

Florin_Andrei 9y ago
> Makefiles and/or bash scripts are not written in javascript Why should you rewrite all that stuff every time there's a new fashion out there? By the same token, a rewrite would have been required when Perl was all the rage, or Python. > The dense syntax of command line tool options is intimidating Anything you don't understand very well can be intimidating.
- iandanforth 9y ago
  Next time I have this argument I'll invite you over and maybe we can bring some sense to the issue :)
- smilekzs 9y ago
  Makefile was not originally designed to be a general-purpose language but eventually grew features and pretends to be one. If a proper general-purpose language with a well-designed library (possibly plus a general-purpose data-only configuration language) is capable of performing the core function of an "interpreted DSL", even at some cost of terseness, I would strongly prefer it to the DSL. While having multiple libraries in different languages might contribute to fragmentation, being able to write the build scripts in the same language as the rest of your project provides value. > > The dense syntax of command line tool options is intimidating > Anything you don't understand very well can be intimidating. IMHO what's intimidating is not the CLI itself, but possibly: 1. lack of consistent convention between different tools (only PowerShell attempted to address this) 2. poor discoverability of options, which is often exacerbated by poor quality of documentation 3. naming of things (which is getting better with more modern CLI tools) 4. ...

Florin_Andrei 9y ago

> Makefiles and/or bash scripts are not written in javascript Why should you rewrite all that stuff every time there's a new fashion out there? By the same token, a rewrite would have been required when Perl was all the rage, or Python. > The dense syntax of command line tool options is intimidating Anything you don't understand very well can be intimidating.

iandanforth 9y ago
Next time I have this argument I'll invite you over and maybe we can bring some sense to the issue :)
smilekzs 9y ago
Makefile was not originally designed to be a general-purpose language but eventually grew features and pretends to be one. If a proper general-purpose language with a well-designed library (possibly plus a general-purpose data-only configuration language) is capable of performing the core function of an "interpreted DSL", even at some cost of terseness, I would strongly prefer it to the DSL. While having multiple libraries in different languages might contribute to fragmentation, being able to write the build scripts in the same language as the rest of your project provides value. > > The dense syntax of command line tool options is intimidating > Anything you don't understand very well can be intimidating. IMHO what's intimidating is not the CLI itself, but possibly: 1. lack of consistent convention between different tools (only PowerShell attempted to address this) 2. poor discoverability of options, which is often exacerbated by poor quality of documentation 3. naming of things (which is getting better with more modern CLI tools) 4. ...