41–50 of 109 posts
Just Don't. Unix-style text stream processing was super cool in 80s-90s but is born tech-debt today.
I love to cook 5-course meals for friends and family. But sometimes when I'm all alone by myself, I slice up a bun and slap meat on it. It's as fast and tastes just as good as in the 80ies.
Earlier quoted context omitted.
Use any modern programming language.
The gnu tools are super fast and do the job. Ive seen people spinning their own solutions which end up being super slow and arguable take more time to develop. With any gnu tools it is great that they will stay there for your life and are usually by default installed on every system
Sometimes I find it strange - in both good and bad way - that we are, in 2020, learning tools and languages designed and build in the 80s, with models and constraints of the time, with 40 years of layers of backwards compatibility, and actually going sometimes back to the 70s I am still learning tools designed around the constraints of teleprinters Sure, it’s the same on Windows side (and macOS side with their classi…
I find these posts annoying that say we're anchored in past tech and we must be able to do better, but never suggest how. Please make a suggestion or two. (NB ultimately our character handling is based on 'writing' which goes back thousands of years, not 50, and it survives well).
* http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html
Sometimes I find it strange - in both good and bad way - that we are, in 2020, learning tools and languages designed and build in the 80s, with models and constraints of the time, with 40 years of layers of backwards compatibility, and actually going sometimes back to the 70s I am still learning tools designed around the constraints of teleprinters Sure, it’s the same on Windows side (and macOS side with their classi…
> I am still learning tools designed around the constraints of teleprinters We are still reading books using a 2k year old alphabet to represent ideas. Not sure why it would be surprising that text manipulation is still the norm pretty much in everything we do, including computing.
I know this sounds diffikult but migraxion to a new system is always diffikult. We're talking about a pretty serious rewrite here so everyone's kooperation will be nesessary. It's not an easy desixion but if you cek into it we can use other languages as a model. Spelling reforms are not a new konsept.
Earlier quoted context omitted.
The English language is several hundreds of years old, and the ADN is several hundreds of millions years old. Everything we are based on is legacy; I do not see why it should be different in computing.
In fairness to the OP, there's a lot of cruft in the way terminal work that really isn't necessary any more but need to be there because of backwards compatibility. Such as - formatting being in-lined via ANSI escape sequences, - and there's a massive disparity between what escape sequences terminal emulators support, - control codes being part of the same character set as printable characters, - changing the behavio…
You even forgot to mention one of the things that was addressed: input. Terminal I/O input, done properly, requires a full ECMA-48 decoder state machine, with bodges to accommodate non-conformant warts from the Linux KVT, SCO Console, and RXVT. This is all too often not done properly, because people do not realize that there is ECMA-48 in both directions; and is a mess, just looking at function keys alone and not even accounting for keypad application/normal modes and a mouse/locator. Console I/O evolved into uniform input event records for HIDs that did not require state machines to decode.
Note that the lack of a layout system is only applicable to character-mode terminals. Block-mode terminals are a quite different kettle of fish.
Earlier quoted context omitted.
> I am still learning tools designed around the constraints of teleprinters We are still reading books using a 2k year old alphabet to represent ideas. Not sure why it would be surprising that text manipulation is still the norm pretty much in everything we do, including computing.
If we're going to update, I think we should stop using C for /s/ and /k/ noises (we already have characters for those). It can exclusively represent /tʃ/, as in "China" would become "Cina". We don't need X either for much the same reason, which is all the better because we'll need a character for /ʃ/. "Delicious" will become "delixious", "shadow" will become "xadow", "nation" will become "naxion". I know this sounds…
But people have tried this (spelling reforms/re-phoenetification of English). A lot.
Language drifts, that's just what it does.
A little suggestion for the authors, they mentioned xargs, I think [GNU parallel]( https://www.gnu.org/software/parallel/ ) might work a mention too, since it is a kind of modern successor that can use many computers to run tasks.