Hacker News Reader

Comment by bombolo | Hacker News Reader

If only all the younger developers were aware of how to properly develop command line applications.

If it wasn’t huge PITA we probably would. Like I try my best to be write well-behaved programs but there’s a cliff of unknown unknowns that is basically bottomless and is known only to people who grew up with the incremental changes.

Stepping through 40 years of organic development by a bunch of different groups whose decisions were based on the limitations of the time is just not gonna happen. But if you don't trying to understand where we ended up will drive you mad. You just pick some closed subset of behaviors / features that exist where your programs run and hope.

I hope someone will create a bridge over the cliff or maybe reinvent a whole landscape without the accumulated cruft over the decades. Till the only the brave will be able to master this space

there’s a cliff of unknown unknowns that is basically bottomless and is known only to people who grew up with the incremental changes.

Don't give this stuff any more reverence than it deserves (which is none). Bob Barton [1] once said "Systems programmers are high priests of a low art."

You don't need to know all the incremental changes, unless the allure of becoming a historian and being able to recount all the developments in the space appeals to you. (Those who do not learn from history are condemned to repeat it.)

There is no mystery except the one you make for yourself. Read books. https://man7.org/tlpi/ is a good place to start. Good luck!

[1] https://en.wikipedia.org/wiki/Robert_S._Barton

Are you also going to do this for the network stack? Graphics? Kernel & syscalls? File systems? DATABASES?? Is there any time left to do work in is there any time left to love your family?

There is also humility in just accepting that my curiosity is greater than my capacity and I'll never know much of anything about anything. I can pick a few things to go deep in but so far it hasn't needed to be terminals and that's not a moral failing.

Being an expert in anything is demanding.

Are we still talking about "command line applications"? Because your comment is exactly how I feel about web development, and somehow all the "younger developers" are more than happy to sit around with seemingly infinitely-complex GUI front-end stacks that only have some indirect relationship to JavaScript.

Tbh I agree with both of you. Things feel fucked all around.

I mean front-end development relies heavily on CLI to compile, optimize, bundle, test stuffs with its gazillion of half baked "make" imitations... every single framework comes with their own CLI tools, and to make everything work together another layer of CLI tools needs to be added on top... which result in slow compilation times, the irony of Javascript in the browser which was designed to be a thin layer of dynamic interactions with HTML documents you only had to refresh the page after editing a script...

It's safe to say that front-end development is now more complex than JEE...

I mean kinda, someone who has been following web development since jQuery and MooTools is going to grok everything way better than someone who is standing today looking backwards, gazing into the labyrinthine nightmare that is the modern JS stack. Either you were around for when each part was introduced and it was a gradual descent into madness where the next step was a natural progression from the previous, or you weren't and now you're in the center of the maze without a map and in your mania you desperately try to invent higher level primitives and metaphors that let you reason about... well anything at all.

But they're all falsehoods that break down eventually and require an elder or time spent with the sacred texts to achieve enlightenment. Repeat the cycle and you get a senior dev in <something: webdev> whose skills are only kinda transferrable to <other thing: CLIs> and you must start your journey over again.

So you have arch mages in webdev who are a acolytes in systems and the only way they'll progress to is write a lot of bad code. I'll get there eventually but how long it takes is dependent on how many opportunities I get to cut my teeth on stuff that requires a more complete understanding.

You don't need to "step through 40 years of organic development" unless you want super-fancy things like an interactive TUI with mouse support or whatnot (and even then, it's not that hard). For most regular CLIs you need a few control codes which are pretty much universal today (setting text attributes, clear line) and that's it.

CLI apps are probably the easiest applications that accept user input to make. Compared to GUI or web apps the amount of knowledge you need is almost trivial.

Decently-sized yet bounded:

- https://en.wikipedia.org/wiki/Advanced_Programming_in_the_Un...

- https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming

I've only read the second cover to cover. Not as much there as you might think, the bulk was laid out in the 70s and 80s when most of an OS could fit in one person's brain.

Not much has been added since, basically extended color and a dozen or so sequences for hypertext links, etc.

I recommend these books. You could use a well-maintained terminal library or two in the meantime.

Every time I pipe the output of `terraform` somewhere I always forgot to append a `-no-color` option.

Every time I also think of just making a wrapper for it, but I never do.

That's kind of what aliases are for.

That's exactly the poor programming I was referring to.

Call isatty()!

The downside of that is that piping to less won't display colours any more either, so then you need "progname -color=always" or some such. Some programs solve that with a built-in "pipe to terminal" feature, but I always find that a bit annoying.

I don't know anything about terraform, but I've written some applications where I intentionally don't automatically change the output (which in my case is usually bold text, I don't use colours much) because I expect no one will ever use the output for scripting . That's not "poor programming", it's a choice because there is no perfect solution that fits 100% of the cases.

I suspect that may probably be the best choice for terraform as well, but I never used it.

But piping to less would display the escape codes, not the colours anyway… which is why this is done.

Imagine grep not working because in between the words that you are searching there is an escape code.

That depends on the settings used for less; AFAIK the default for many distros is to display control characters.

> If only all the younger developers were aware of how to properly develop command line applications.

They are doing just fine. You can't expect them to learn 50 years of technical complexity in a few days and why there are so many different shells and how they behave differently.

edit: replaced debt by complexity

if you want to run with that analogy, command line shells running in terminals are assets, not debt. Not knowing how to use them is poverty, lacking having assets.

you can't just take the word "debt" to mean bad, then just throw it around for things you don't like, especially applied to things that take effort to learn, effort you have not and don't want to expend.

There is no "50 years of technical debt". If anything, a significant amount of complexity has been removed compared to the 70s and 80s when everyone and their mother was making wildly incompatible terminals (actual terminals that is, not software terminal emulators).

You don't really need to know anything about shells to write a CLI app, other than basic shell conventions (- for flags, things like that). You don't even need to know all that much about terminals, just some bare basics if you want to do colours or whatnot. All of this can be summarized in a page or two.

If you want to write a ncurses-like library: that's a different story. But then it's no longer a CLI app.

The parent poster was likey refering to the fact that good apps should suppress colors when output is not a tty, so that all the text-processing tools work properly.

This works identically in all the shells (and even without a shell), and there is no "50 years years of techinical debt" (unless you mean the idea itself of in-band control codes)

Linux's Ncurses Howto it's good.

Reply on news.ycombinator.com