> 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".
>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:
> 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?
I don't agree with almost anything he said. He doesn't know what he's talking about. He comes from games. I too came from games. I had all the same opinions as him. Then I worked on a browser on a team with hundreds programmers (browsers are huge). The article is a perfect example. He hasn't solved the actual problems being solved so he has no clue why the solutions used are the ones that were chosen.
Could some parts be re-written to be more efficient? Maybe. Could they be made efficient and still be easy for any of those hundreds of programmers to follow and modify? Probably not, even if all of them were of his caliber.
Games just don't have to deal with the same issues. Take Unicode fonts. Just the emoji font is 221meg! I'm pretty sure if you ask JBlo about it he'll give some flippant and asian bashing "emoji shouldn't exist in the first answer". He won't actually "solve the problem that's actually being solved", he'll solve some simpler problem in a simpler way in his head and then declare that's all you need.
He's made all kinds of ridiculous and conflicting claims. Example, he believes there should be only one graphics API. To put it another way, he believes in design by committee since that's the only way there would ever be one API. Yet in other areas he rejects design by committee (game engines would be one).
Another issue is security. AFAICT he's never given it a second thought. As one example his JAI language he pointed out he never runs into memory ownership issues so he doesn't want a language that helps with that. Memory ownership issues is one of the top ways security bugs appear. Again, pointing out he doesn't know what problems are actually being solved and is thinking only from his own limited experience.
agreed, I respect what he did but some claims are ridiculous and his "clan" of followers only makes it worse.
BTW: would you be willing to chat from time to time? Im doing something similar (hobby, mostly one-man show so far) to browser and I would really could use some help. I dont need any programming but pointing me in the right direction would be awesome.
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.
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.
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.
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.
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.
> 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.
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.
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.
This is what was done with codepages before the advent of the internet, basically. The problem that arose was transferring information between systems - even without the internet it was needed at areas that were near borders, etc.
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".