6 ms·

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 const

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 classic OS compatibility layers still present, like all the HFS stuff). Not bashing bash here. Surely our computers have very different models of operation than PDP-11, yet we are sometimes pretending it doesn’t

throwaway_pdp09 7y ago
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).
- zokier 7y ago
  Structured data and tools that operate on that structure. Maybe steal a thing or two from LISP machines. I remember the one time I had to work on an AS/400 (iirc) how interesting it was that one of the fundamental building blocks were records instead of dumb files. PowerShell has interesting ideas too, but it'd need to be far more built-in and integrated to the OS to truly shine.
- JdeBP 7y ago
  I suggest learning from history. The doing better has already happened. The 1960s terminal I/O model evolved into the console I/O model during the 1980s; from firmware-mediated access to CGA, through the VIO+KBD+MOU subsystems of OS/2, to Windows NT console objects. * http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html * https://news.ycombinator.com/item?id=17238350 https://news.ycombinator.com/item?id=17238350
  - throwaway_pdp09 7y ago
    That seems to have nothing to do with text processing, only screen addressability.
    - JdeBP 7y ago
      If you actually read the whole discussion to this point, you'll see that the discussion started with being constrained to the models of teleprinters, not text processing.
Lio 7y ago
It’s because fundamentally, when you get right down to it, we’re manipulating text files. Text is a very dense way to represent logic and ideas. This is not like legacy software that you can rewrite. You can add a GUI based on ideas from the late 70s/80s if you like but you’re still unlikely to come up with a more succinct way to represent logic than can be held in a text file. So it follows that small tools that deal directly with manipulating text will be useful as long as text is useful.
- zokier 7y ago
  I'd say that fundamentally we are manipulating streams or arrays of numbers. Everything is built on top of that. Each character in a tex is a number. Each pixel is a number. Each sample of sound is a number. For computers how the number ends up being transferred to the puny meatbag is completely incidental. In more practical terms at least for me, vast majority of stuff I mangle through shell is not really text but structured data, typically either some sort of tree or a table, or something in-between. Sometimes the structure is more ad-hoc, sometimes it is very rigidly defined, but it's still there
enriquto 7y ago
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.
- hnlmorg 7y ago
  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 behaviour of the TTY requires either terminal emulator support or OS support depending on the behaviour you require because the TTYs are defined partially via kernel drivers (which requires syscalls to alter) and partially by escape sequences, - and in the case of kernel behaviour, those syscalls vary from one OS to another. Some OS's don't even support from TTY behaviours that other OSs do so you can't even guarantee that logic is cross platform and that you just wrap around specific differences in syscalls, - resizing terminals UIs can be a nightmare -- often requiring capturing RPC signals and redrawing -- because there's no native layout system for drawing to the TTY, This isn't meant as a criticism though because there's a lot the general design of terminals gets right (eg the kernel driver for TTY allows us to kill processes over remote shells like SSH and mosh). But I think terminals are one of those things that work "good enough" that most of the ugliness is hidden from everyday users. However if we were to redesign UNIX terminals from the ground up there is a lot of things most engineers would like to change and of lot of places where things could be improved. Like having an out-of-band channel for sending meta-data describing the pipeline but shouldn't be mixed in with the byte stream.
  - JdeBP 7y ago
    ... and pretty much all of those were addressed, outwith Unix, by the evolution of the 1960s terminal I/O model into the console I/O model during the 1980s. 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.
BaltoRouberol 7y ago
Author here. Quick sidenote: this is chapter 2 of a book aiming at teaching the terminal and related tooling (make, jq, regular expressions, etc) to beginners and people trying to become developers. I've been on the job for 10 years and I still use these tools daily. For example, I sent a PR yesterday that was adding a configuration entry on 150+ config files by using find, grep and sed. I'm not pretending these are the only tools that exist, but darn are they handy sometimes, and good to have in your toolbelt.
- shp0ngle 7y ago
  Please don’t take it wrong, I like what I read so far! It was just my random observation
a3n 7y ago
> and actually going sometimes back to the 70s Try 1725, especially for those of us who (still) set their editors to favor 80 columns. https://en.m.wikipedia.org/wiki/Punched_card https://en.m.wikipedia.org/wiki/Punched_card
- dublin 7y ago
  Remember to start your FORTRAN statements in Column 7!
ekianjo 7y ago
> 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.
- Timpy 7y ago
  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 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.
  - kortex 7y ago
    If anything, c should be /ʃ/ and tc should be /tʃ/. Looks funny but it's very phoenetic. But people have tried this (spelling reforms/re-phoenetification of English). A lot. Language drifts, that's just what it does.
  - Koshkin 7y ago
    This has been done before: http://www.davidpbrown.co.uk/jokes/european-commission.html http://www.davidpbrown.co.uk/jokes/european-commission.html.
  - ken 7y ago
    Turkish did this right, IMHO, when it adopted a Latin alphabet. No diphthongs at all. One letter, one sound. The “sh“ sound is spelled ş, and “ch” is ç. You also need to add more vowels, as there are way more than 5 vowel sounds, but that’s not hard. Umlauts are already common in many languages.
- 7y ago
petepete 7y ago
The beauty of it is that these old tools play extremely nicely with their modern counterparts. ag, fzf, fd and tmux are key tools I use to aid my work on a daily basis alongside many of the classics listed in this article.
0xdeadbeefbabe 7y ago
Sure it's hard for us, but what about creatures that have 28 eyes and 14 brains? In other words, we also have more CPU cores now. I'm not sure I'm keeping all my CPU cores happy. And no I don't think it's just a problem for the OS. Although, that's probably a popular idea.
robenkleene 7y ago
Why do you find this strange? There’s a pattern across all fields: Different paradigms compete early on, and the best paradigm wins and we build on it incrementally for years (forever?) after. Every once in awhile a new workflow emerges based on increases in hardware capabilities: Ableton Live, Adobe Lightroom, and Figma are all examples of this. Notably these new tools usually split the market rather than replace the previous version: Logic, Photoshop, and Sketch are still popular.
pixelmonkey 7y ago
If you think of UNIX tools the way a chef thinks about kitchen tools (like chefs’ knives and cutting boards, or mixing bowls and frying pans), you won’t be as surprised to be using stuff that dates back decades. Good design is built to last and to enhance the skills of an experienced craftsperson. I wrote a little on this here: https://amontalenti.com/2012/06/22/unix-kitchen https://amontalenti.com/2012/06/22/unix-kitchen

throwaway_pdp09 7y ago

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).

zokier 7y ago
Structured data and tools that operate on that structure. Maybe steal a thing or two from LISP machines. I remember the one time I had to work on an AS/400 (iirc) how interesting it was that one of the fundamental building blocks were records instead of dumb files. PowerShell has interesting ideas too, but it'd need to be far more built-in and integrated to the OS to truly shine.
JdeBP 7y ago
I suggest learning from history. The doing better has already happened. The 1960s terminal I/O model evolved into the console I/O model during the 1980s; from firmware-mediated access to CGA, through the VIO+KBD+MOU subsystems of OS/2, to Windows NT console objects. * http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html http://jdebp.uk./FGA/tui-console-and-terminal-paradigms.html * https://news.ycombinator.com/item?id=17238350 https://news.ycombinator.com/item?id=17238350
- throwaway_pdp09 7y ago
  That seems to have nothing to do with text processing, only screen addressability.
  - JdeBP 7y ago
    If you actually read the whole discussion to this point, you'll see that the discussion started with being constrained to the models of teleprinters, not text processing.

Lio 7y ago

It’s because fundamentally, when you get right down to it, we’re manipulating text files. Text is a very dense way to represent logic and ideas. This is not like legacy software that you can rewrite. You can add a GUI based on ideas from the late 70s/80s if you like but you’re still unlikely to come up with a more succinct way to represent logic than can be held in a text file. So it follows that small tools that deal directly with manipulating text will be useful as long as text is useful.

zokier 7y ago
I'd say that fundamentally we are manipulating streams or arrays of numbers. Everything is built on top of that. Each character in a tex is a number. Each pixel is a number. Each sample of sound is a number. For computers how the number ends up being transferred to the puny meatbag is completely incidental. In more practical terms at least for me, vast majority of stuff I mangle through shell is not really text but structured data, typically either some sort of tree or a table, or something in-between. Sometimes the structure is more ad-hoc, sometimes it is very rigidly defined, but it's still there

enriquto 7y ago

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.

hnlmorg 7y ago
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 behaviour of the TTY requires either terminal emulator support or OS support depending on the behaviour you require because the TTYs are defined partially via kernel drivers (which requires syscalls to alter) and partially by escape sequences, - and in the case of kernel behaviour, those syscalls vary from one OS to another. Some OS's don't even support from TTY behaviours that other OSs do so you can't even guarantee that logic is cross platform and that you just wrap around specific differences in syscalls, - resizing terminals UIs can be a nightmare -- often requiring capturing RPC signals and redrawing -- because there's no native layout system for drawing to the TTY, This isn't meant as a criticism though because there's a lot the general design of terminals gets right (eg the kernel driver for TTY allows us to kill processes over remote shells like SSH and mosh). But I think terminals are one of those things that work "good enough" that most of the ugliness is hidden from everyday users. However if we were to redesign UNIX terminals from the ground up there is a lot of things most engineers would like to change and of lot of places where things could be improved. Like having an out-of-band channel for sending meta-data describing the pipeline but shouldn't be mixed in with the byte stream.
- JdeBP 7y ago
  ... and pretty much all of those were addressed, outwith Unix, by the evolution of the 1960s terminal I/O model into the console I/O model during the 1980s. 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.

BaltoRouberol 7y ago

Author here. Quick sidenote: this is chapter 2 of a book aiming at teaching the terminal and related tooling (make, jq, regular expressions, etc) to beginners and people trying to become developers. I've been on the job for 10 years and I still use these tools daily. For example, I sent a PR yesterday that was adding a configuration entry on 150+ config files by using find, grep and sed. I'm not pretending these are the only tools that exist, but darn are they handy sometimes, and good to have in your toolbelt.

shp0ngle 7y ago
Please don’t take it wrong, I like what I read so far! It was just my random observation

a3n 7y ago

> and actually going sometimes back to the 70s Try 1725, especially for those of us who (still) set their editors to favor 80 columns. https://en.m.wikipedia.org/wiki/Punched_card https://en.m.wikipedia.org/wiki/Punched_card

dublin 7y ago
Remember to start your FORTRAN statements in Column 7!

ekianjo 7y ago

> 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.

Timpy 7y ago
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 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.
- kortex 7y ago
  If anything, c should be /ʃ/ and tc should be /tʃ/. Looks funny but it's very phoenetic. But people have tried this (spelling reforms/re-phoenetification of English). A lot. Language drifts, that's just what it does.
- Koshkin 7y ago
  This has been done before: http://www.davidpbrown.co.uk/jokes/european-commission.html http://www.davidpbrown.co.uk/jokes/european-commission.html.
- ken 7y ago
  Turkish did this right, IMHO, when it adopted a Latin alphabet. No diphthongs at all. One letter, one sound. The “sh“ sound is spelled ş, and “ch” is ç. You also need to add more vowels, as there are way more than 5 vowel sounds, but that’s not hard. Umlauts are already common in many languages.
7y ago

petepete 7y ago

The beauty of it is that these old tools play extremely nicely with their modern counterparts. ag, fzf, fd and tmux are key tools I use to aid my work on a daily basis alongside many of the classics listed in this article.

0xdeadbeefbabe 7y ago

Sure it's hard for us, but what about creatures that have 28 eyes and 14 brains? In other words, we also have more CPU cores now. I'm not sure I'm keeping all my CPU cores happy. And no I don't think it's just a problem for the OS. Although, that's probably a popular idea.

robenkleene 7y ago

Why do you find this strange? There’s a pattern across all fields: Different paradigms compete early on, and the best paradigm wins and we build on it incrementally for years (forever?) after. Every once in awhile a new workflow emerges based on increases in hardware capabilities: Ableton Live, Adobe Lightroom, and Figma are all examples of this. Notably these new tools usually split the market rather than replace the previous version: Logic, Photoshop, and Sketch are still popular.

pixelmonkey 7y ago

If you think of UNIX tools the way a chef thinks about kitchen tools (like chefs’ knives and cutting boards, or mixing bowls and frying pans), you won’t be as surprised to be using stuff that dates back decades. Good design is built to last and to enhance the skills of an experienced craftsperson. I wrote a little on this here: https://amontalenti.com/2012/06/22/unix-kitchen https://amontalenti.com/2012/06/22/unix-kitchen