5 ms·

> Jonathan Blow, in a talk about how software is getting worse, points to the example of Ken Thompson's text editor, which Ken built in a single week. This kin

> Jonathan Blow, in a talk about how software is getting worse, points to the example of Ken Thompson's text editor, which Ken built in a single week. This kind of sentiment drives me crazy. Yes, internationalization makes things harder and more complex than they were in the old days. But, back then, only people who lived in one small part of the world were able to usefully use computers in their language. (Simply supporting the Unicode character set is not enough.) Nostalgia for the simplicity of the past ends up having ugly cultural implications. It's easy to say "let's go back to the time when things were simple"; it's a lot harder to say "folks in (e.g.) Israel shouldn't be able to type in their native language".

hannasanarion 5y ago
Especially since the text editor in question is `ed`, which is not exactly a pinnacle of utility. We're really comparing apples to moon rockets here.
- qsort 5y ago
  `ed` was developed in 1969. That's a remarkably uncharitable take, considering `ed` itself and its derivatives (like `sed`) are still useful today.
  - hannasanarion 5y ago
    No more uncharitable than saying that modern developers suck at their jobs because they can't make Sublime Text in the same time as it took Ken Thompson to make ed.
    - qsort 5y ago
      That's not the point of the article, not even remotely.
  - Groxx 5y ago
    This is accurate in the same way as saying "a rock chiseled into a wheel with a stick as an axle is still useful today". Or maybe "a mechanical calculator and a book of logarithms is still useful today". Sure, it still exists and still does what it used to do, and its derivatives surround us. But nobody does that any more because nearly everything else is so superior, it'd be ridiculous to do so, except as an art piece or when you literally have no alternative.
    - qsort 5y ago
      That's not a fair analogy at all. sed is basically the stream interface for ed and it's one of the most common unix text utilities, and even ed has its uses today. I remember using it on a machine I was remotely connected to. For some reason the terminal output was garbled and neither vi nor emacs would render properly, but ed worked fine. Obviously you wouldn't use it day to day, and yeah, you wouldn't use if you have any alternative at all, either. But the fact that it still has some form of (admittedly very limited) competitive advantage over modern tools makes it useful to have /bin/ed handy, even if you actually use it once in a blue moon.
colllectorof 5y ago
>Nostalgia for the simplicity of the past ends up having ugly cultural implications. It's easy to say "let's go back to the time when things were simple"; it's a lot harder to say "folks in (e.g.) Israel shouldn't be able to type in their native language". This is a ridiculous mischaracterization of what Jonathan Blow was talking about. Here is the full presentation. Very much worth watching in its entirety and thinking about: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk
- slmjkdbtl 5y ago
  > This is a ridiculous mischaracterization of what Jonathan Blow was talking about. I watched the full presentation and agree with almost everything he said, but I can't find a part matching the conflict between "Simple text editor Vs. Complicated character encoding scheme / rendering / formatting". How would JB make a text editor that works with any kind of character?
  - alistairw 5y ago
    I agree with the sentiment you're getting at about nostalgia for the past sometimes ignores the homogeneity of the people using those systems and how that reduced complexity. I do think there's an argument there that needs to be explored further to identify what is actually simple and hard/complex in computing. However, I think this point about how JB specifically would make one with any type of character is not the best direction for exploring that. He's made games and his own presentation software (Used in the presentation linked above) which is able to do that. I doubt he would classify that as one of the actually hard aspects of computing.
    - slmjkdbtl 5y ago
      Yeah I agree making an editor that supports any type of character is not the best way to explore this subject, but I doubt the result of this exploration can solve that editor problem. I follow a similar mindset of JB and have being making / using my own tools, even my personal character encoding (I have Chinese as my first language and want to use Chinese in my works but Unicode is too messy and it's impossible to make a font that supports thousands of characters so been developing my subset of Chinese that fits in a byte), also my own game engine / renderers / programming language (similar to JB's stack) My experience is these softwares are too personal and not applicable the the real general public. JB also makes personal softwares and won't consider about generality. Personal softwares are inherently better, because the bloat and bad about current state almost all comes from derailed generalization effort. If we take the beautiful DOOM editor and make it general, it'll be real hard to not make it another Unity, and that's the real under-explored problem.
titzer 5y ago
> It's easy to say "let's go back to the time when things were simple"; it's a lot harder to say "folks in (e.g.) Israel shouldn't be able to type in their native language". Is writing a text editor literally so hard that we can't do it twice (or three, or five times)? There are literally trillions of lines of code in existence now. Instead of making a five hundred thousand line text editor because are terrified of writing one again, maybe we make five ten thousand line editors? Of course, I'm exaggerating, but do you get my point? There are worse things than duplicated code. Narrowing the requirements for latin and cyrillic left-to-right languages so their code can be made radically simpler seems well worth it! The specialization necessary to make a text editor do Hebrew well, or Chinese or Arabic well is probably way different, and frankly, better done by experts in those languages. From their perspective, to completely flip it around, why should their editors be encumbered by the need to support English? Instead we end up with the proverbial "Jack of all trades, master of none". And we end up with radically complicated, hard to test, terrified-of-breaking-a-language-I-don't understand code that serves no one well. Editors don't have have to completely diverge in features and feel just because they might have different code bases. Surely we can try to make copy&paste and select all and the common things operate in a fairly standard way across a few different programs.
- skybrian 5y ago
  People who work in multiple languages probably wouldn't be too happy with this. (Particularly not with dropping English since it's the most common second language.) This also isn't going to work economically for companies selling consumer apps because they aren't going to want to limit their market to a one country, particularly if it's a small one. There's more money in targeting the world, so programmers just have to deal. (The support matrix is often complicated already with multiple platforms to support.) I think it's fine in many cases to target limited audiences. Companies often have internal apps that aren't internationalized. But the popular apps that we all use have to be very complicated because they actually do try to be universal.
  - abecedarius 5y ago
    Conceivably we'd be better off with a compound-document standard, like the 90s attempts OLE and OpenDoc but somehow nicer. Then multilanguage documents, with specialized editors, would fall out as one use for compound documents.
LeftTriangle 5y ago
Natively supporting Hebrew and other RTL languages is absolutely not worth the misery it has inflicted on programmers. > Nostalgia for the simplicity of the past ends up having ugly cultural implications Or maybe people's instinctive nostalgia is correct and the artificial culture of postmodern globalism actually sucks.

hannasanarion 5y ago

Especially since the text editor in question is `ed`, which is not exactly a pinnacle of utility. We're really comparing apples to moon rockets here.

qsort 5y ago
`ed` was developed in 1969. That's a remarkably uncharitable take, considering `ed` itself and its derivatives (like `sed`) are still useful today.
- hannasanarion 5y ago
  No more uncharitable than saying that modern developers suck at their jobs because they can't make Sublime Text in the same time as it took Ken Thompson to make ed.
  - qsort 5y ago
    That's not the point of the article, not even remotely.
- Groxx 5y ago
  This is accurate in the same way as saying "a rock chiseled into a wheel with a stick as an axle is still useful today". Or maybe "a mechanical calculator and a book of logarithms is still useful today". Sure, it still exists and still does what it used to do, and its derivatives surround us. But nobody does that any more because nearly everything else is so superior, it'd be ridiculous to do so, except as an art piece or when you literally have no alternative.
  - qsort 5y ago
    That's not a fair analogy at all. sed is basically the stream interface for ed and it's one of the most common unix text utilities, and even ed has its uses today. I remember using it on a machine I was remotely connected to. For some reason the terminal output was garbled and neither vi nor emacs would render properly, but ed worked fine. Obviously you wouldn't use it day to day, and yeah, you wouldn't use if you have any alternative at all, either. But the fact that it still has some form of (admittedly very limited) competitive advantage over modern tools makes it useful to have /bin/ed handy, even if you actually use it once in a blue moon.

colllectorof 5y ago

>Nostalgia for the simplicity of the past ends up having ugly cultural implications. It's easy to say "let's go back to the time when things were simple"; it's a lot harder to say "folks in (e.g.) Israel shouldn't be able to type in their native language". This is a ridiculous mischaracterization of what Jonathan Blow was talking about. Here is the full presentation. Very much worth watching in its entirety and thinking about: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk

slmjkdbtl 5y ago
> This is a ridiculous mischaracterization of what Jonathan Blow was talking about. I watched the full presentation and agree with almost everything he said, but I can't find a part matching the conflict between "Simple text editor Vs. Complicated character encoding scheme / rendering / formatting". How would JB make a text editor that works with any kind of character?
- alistairw 5y ago
  I agree with the sentiment you're getting at about nostalgia for the past sometimes ignores the homogeneity of the people using those systems and how that reduced complexity. I do think there's an argument there that needs to be explored further to identify what is actually simple and hard/complex in computing. However, I think this point about how JB specifically would make one with any type of character is not the best direction for exploring that. He's made games and his own presentation software (Used in the presentation linked above) which is able to do that. I doubt he would classify that as one of the actually hard aspects of computing.
  - slmjkdbtl 5y ago
    Yeah I agree making an editor that supports any type of character is not the best way to explore this subject, but I doubt the result of this exploration can solve that editor problem. I follow a similar mindset of JB and have being making / using my own tools, even my personal character encoding (I have Chinese as my first language and want to use Chinese in my works but Unicode is too messy and it's impossible to make a font that supports thousands of characters so been developing my subset of Chinese that fits in a byte), also my own game engine / renderers / programming language (similar to JB's stack) My experience is these softwares are too personal and not applicable the the real general public. JB also makes personal softwares and won't consider about generality. Personal softwares are inherently better, because the bloat and bad about current state almost all comes from derailed generalization effort. If we take the beautiful DOOM editor and make it general, it'll be real hard to not make it another Unity, and that's the real under-explored problem.

titzer 5y ago

> It's easy to say "let's go back to the time when things were simple"; it's a lot harder to say "folks in (e.g.) Israel shouldn't be able to type in their native language". Is writing a text editor literally so hard that we can't do it twice (or three, or five times)? There are literally trillions of lines of code in existence now. Instead of making a five hundred thousand line text editor because are terrified of writing one again, maybe we make five ten thousand line editors? Of course, I'm exaggerating, but do you get my point? There are worse things than duplicated code. Narrowing the requirements for latin and cyrillic left-to-right languages so their code can be made radically simpler seems well worth it! The specialization necessary to make a text editor do Hebrew well, or Chinese or Arabic well is probably way different, and frankly, better done by experts in those languages. From their perspective, to completely flip it around, why should their editors be encumbered by the need to support English? Instead we end up with the proverbial "Jack of all trades, master of none". And we end up with radically complicated, hard to test, terrified-of-breaking-a-language-I-don't understand code that serves no one well. Editors don't have have to completely diverge in features and feel just because they might have different code bases. Surely we can try to make copy&paste and select all and the common things operate in a fairly standard way across a few different programs.

skybrian 5y ago
People who work in multiple languages probably wouldn't be too happy with this. (Particularly not with dropping English since it's the most common second language.) This also isn't going to work economically for companies selling consumer apps because they aren't going to want to limit their market to a one country, particularly if it's a small one. There's more money in targeting the world, so programmers just have to deal. (The support matrix is often complicated already with multiple platforms to support.) I think it's fine in many cases to target limited audiences. Companies often have internal apps that aren't internationalized. But the popular apps that we all use have to be very complicated because they actually do try to be universal.
- abecedarius 5y ago
  Conceivably we'd be better off with a compound-document standard, like the 90s attempts OLE and OpenDoc but somehow nicer. Then multilanguage documents, with specialized editors, would fall out as one use for compound documents.

LeftTriangle 5y ago

Natively supporting Hebrew and other RTL languages is absolutely not worth the misery it has inflicted on programmers. > Nostalgia for the simplicity of the past ends up having ugly cultural implications Or maybe people's instinctive nostalgia is correct and the artificial culture of postmodern globalism actually sucks.