7 ms·

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 se

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.
  - hnlmorg 7y ago
    > ... and pretty much all of those were addressed, [outside?] Unix, by the evolution of the 1960s terminal I/O model into the console I/O model during the 1980s. > 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. Indeed but the point isn't "are these solvable problems?" but rather "why are we still using archaic tech?" Designing a solution to those problems is actually the easy part. It is shifting the ecosystem away from TTYs that's hard. > You even forgot to mention It wasn't intended as an exhaustive list :) There's plenty more issues I hadn't raised. --- In an ideal world I'd love to see UNIX terminals reinvented. The reality is things are "good enough" for most people that they simply don't notice most of the issues and migrating to the next evolution of UNIX terminals would mean a break in backwards compatibility which will be more disruptive (initially in a negative way) than making do with the warts we currently have.
    - dublin 7y ago
      Check out Microsoft's new Windows terminal (https://www.hanselman.com/blog/ItsTimeForYouToInstallWindowsTerminal.aspx https://www.hanselman.com/blog/ItsTimeForYouToInstallWindows... ) It may be the most modern, capable, and yet compatible terminal I've come across, and works well regardless of the environment you want to run it in/with. (To be fair, a modern Windows terminal is a good 20 years overdue, but MS deserves credit for finally getting it right...)
      - JdeBP 7y ago
        It doesn't really support all of the basics as exemplified in https://github.com/jdebp/terminal-tests/blob/master/PowerShell/Attributes.ps1 https://github.com/jdebp/terminal-tests/blob/master/PowerShe... and https://github.com/jdebp/terminal-tests/blob/master/PowerShell/TabStops.ps1 https://github.com/jdebp/terminal-tests/blob/master/PowerShe... yet. https://github.com/jdebp/terminal-tests/blob/master/PowerShell/ZeroDefaultMode.ps1 https://github.com/jdebp/terminal-tests/blob/master/PowerShe... is arguable, and depends from whether one sides with old actual DEC VTs or the ECMA-48:1986 standard, which the DEC VTs didn't keep up with. There are at least two existing terminal emulators that side with the new 1986 semantics, nowadays. It really isn't anywhere near the most capable terminal emulator right now. This is acknowledged by its developers, and they even have long to-do lists of missing stuff, both as compared to a DEC VT and compared to the likes of XTerm.
ken 7y ago
And English is terrible as a language! We’ve been making fun of how bad it is for centuries. Compare languages like Turkish or Korean, which are still natural languages but got a well-thought-out tune-up in the not-so-distant past. Why can’t my language have a pluralization rule (for example) that’s so simple and regular it takes 1 minute to teach, and 3 minutes to master? Or an alphabet that looks like how it is pronounced, so we don’t have to waste hours each week as children memorizing thousands of special cases? This is absurd.
- gjm11 7y ago
  It could! Given enough international cooperation, we could all adopt a lightly modified version of English that's more regular and easier to teach and learn. And then, over the coming years, it would absorb words from other languages with different rules, and evolve according to what people find easy or convenient (or just at random), and in a little while it would be irregular once again. As you said, Turkish and Korean were changed recently. Give them time and some of that regularity will get chipped away. (Also, of course: make substantial changes to how the language works and suddenly no one can comfortably read any of the vast quantities of existing writing unless it's translated. And some of that existing writing is really good.)
lordgrenville 7y ago
What do you mean by ADN? Possibly a non-English equivalent for DNA? (My guess based on EN Wikipedia's disambiguation page.)
- enriquto 7y ago
  Yep, sorry, I'm used to this acronym in french.

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.
- hnlmorg 7y ago
  > ... and pretty much all of those were addressed, [outside?] Unix, by the evolution of the 1960s terminal I/O model into the console I/O model during the 1980s. > 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. Indeed but the point isn't "are these solvable problems?" but rather "why are we still using archaic tech?" Designing a solution to those problems is actually the easy part. It is shifting the ecosystem away from TTYs that's hard. > You even forgot to mention It wasn't intended as an exhaustive list :) There's plenty more issues I hadn't raised. --- In an ideal world I'd love to see UNIX terminals reinvented. The reality is things are "good enough" for most people that they simply don't notice most of the issues and migrating to the next evolution of UNIX terminals would mean a break in backwards compatibility which will be more disruptive (initially in a negative way) than making do with the warts we currently have.
  - dublin 7y ago
    Check out Microsoft's new Windows terminal (https://www.hanselman.com/blog/ItsTimeForYouToInstallWindowsTerminal.aspx https://www.hanselman.com/blog/ItsTimeForYouToInstallWindows... ) It may be the most modern, capable, and yet compatible terminal I've come across, and works well regardless of the environment you want to run it in/with. (To be fair, a modern Windows terminal is a good 20 years overdue, but MS deserves credit for finally getting it right...)
    - JdeBP 7y ago
      It doesn't really support all of the basics as exemplified in https://github.com/jdebp/terminal-tests/blob/master/PowerShell/Attributes.ps1 https://github.com/jdebp/terminal-tests/blob/master/PowerShe... and https://github.com/jdebp/terminal-tests/blob/master/PowerShell/TabStops.ps1 https://github.com/jdebp/terminal-tests/blob/master/PowerShe... yet. https://github.com/jdebp/terminal-tests/blob/master/PowerShell/ZeroDefaultMode.ps1 https://github.com/jdebp/terminal-tests/blob/master/PowerShe... is arguable, and depends from whether one sides with old actual DEC VTs or the ECMA-48:1986 standard, which the DEC VTs didn't keep up with. There are at least two existing terminal emulators that side with the new 1986 semantics, nowadays. It really isn't anywhere near the most capable terminal emulator right now. This is acknowledged by its developers, and they even have long to-do lists of missing stuff, both as compared to a DEC VT and compared to the likes of XTerm.

ken 7y ago

And English is terrible as a language! We’ve been making fun of how bad it is for centuries. Compare languages like Turkish or Korean, which are still natural languages but got a well-thought-out tune-up in the not-so-distant past. Why can’t my language have a pluralization rule (for example) that’s so simple and regular it takes 1 minute to teach, and 3 minutes to master? Or an alphabet that looks like how it is pronounced, so we don’t have to waste hours each week as children memorizing thousands of special cases? This is absurd.

gjm11 7y ago
It could! Given enough international cooperation, we could all adopt a lightly modified version of English that's more regular and easier to teach and learn. And then, over the coming years, it would absorb words from other languages with different rules, and evolve according to what people find easy or convenient (or just at random), and in a little while it would be irregular once again. As you said, Turkish and Korean were changed recently. Give them time and some of that regularity will get chipped away. (Also, of course: make substantial changes to how the language works and suddenly no one can comfortably read any of the vast quantities of existing writing unless it's translated. And some of that existing writing is really good.)

lordgrenville 7y ago

What do you mean by ADN? Possibly a non-English equivalent for DNA? (My guess based on EN Wikipedia's disambiguation page.)

enriquto 7y ago
Yep, sorry, I'm used to this acronym in french.