I had the same problem in graduate school until I realized that Smalltalk is not designed to be read outside it's IDE.

Most of the problems with that language, rightfully flagged in this article, are not as problematic when the code is read inside it's native environement.

This seems like one of those spots where Smalltalk is a victim of cultural changes that happened around it.

25 years ago, a tight integration between the language and the IDE like that would have sounded great to me. Nowadays, though, it strikes me as a terrible, terrible flaw.

What's changed is the development of a collaborative development across the Internet, and a stronger emphasis on code review. So now, for a great many projects, the most important code reading typically happens outside the code's native environment. It's done in whatever least-common-denominator view you get in your team's code review tool.

With such powerful computers and networks now, is there really any excuse for the least common denominator view on your team to be bad?

The terrible flaw, to me, sounds like it's the workflow that won't bother installing the right tools for code review. It's not like you're stuck with printouts or something where those tools aren't practical.

(If the IDEs or editors are lacking things needed for code review, then that's a problem, but it's not a problem inherent to the idea of tight integration.)

How would GitHub or Bitbucket go about "installing" Microsoft's or Apple's proprietary tools on their website?

And from there you can use GitHub Codespace to "develop in a cloud-hosted, customizable environment" to run and debug.