4 ms·

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,

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.

mumblemumble 5y ago
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.
- rileymat2 5y ago
  It is funny, one of the things that has bothered me for quite a while is that diffs don’t understand code. For example if I add an additional usage to a global variable to a file, while someone else renames it in other files, git happily merges with no conflict. Tighter language integration can help with that.
  - k1ll3r 5y ago
    you can write a diff tool that talks to an LSP server
  - nick__m 5y ago
    This tight integration between language and general purpose tool is a nice idea with a terrible price. It would make tools a lot harder to develop and they would be a lot slower as they now have to perform significantly more work.
  - rfw300 5y ago
    That strikes me as outside the scope of a feasible version control tool (and is probably undecidable in most cases). Seems like you’d be much better off handling that with a test suite and CI.
    - rileymat2 5y ago
      I kind of agree, but if you have a very tight coupling, you could version control objects of the language and not text files. For example, a function could be versioned as a function, not a chunk of text. For example, I have seen cases with diffing where based on whatever algorithm, a very small logical change, (like moving a function up or down in the file along with a minor edit), creates a very confusing side by side diff based on whatever similar lines it think match up.
  - isoprophlex 5y ago
    There's automated testing in a ci/cd pipeline to catch that, I suppose...
  - mananaysiempre 5y ago
    It can, but like with other “rich” structures (type systems, data schemas, IDLs...) there is usually no single good solution, and when you need different ones to interoperate (either because you hit the limits of one of them or because you need to bridge two preexisting systems) you need to write a lot of tedious boilerplate at best and are completely stuck at worst. AFAICS that’s why amorphous sequences of bytes won as the fundamental (absence of an) abstraction in many places (files, networks, RAM, etc.). I would very much like for this not to be true, but there doesn’t seem to be a good solution. With syntax trees in particular, it’s also frequently difficult to find even a single good option for what you would reasonably want a diff to be: last I checked rich-text diffs usable over arbitrary HTML (even sans CSS) still sucked in half the cases you’d want. Line- and word-based diffs over the source also suck, naturally, but at least they do so uniformly. It’s not an accident Stack Overflow will usually try to show you a rich-text diff when editing but will occasionally fall back to word-diffing the Markdown. And a version control system needs to interoperate above all. Unlike, say, an IDE, and you do see attempts at semantic and even structured editing in IDEs. /me continues to fantasize about interbreeding Paredit and Pijul one day
  - smasher164 5y ago
    Git allows you to use a custom diff tool for a specific file format. The problem is that these centralized source hosting/review tools only let you do about half of what Git can do.
- Dylan16807 5y ago
  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.)
  - b3morales 5y ago
    How would GitHub or Bitbucket go about "installing" Microsoft's or Apple's proprietary tools on their website?
    - jodrellblank 5y ago
      On Microsoft Github, in a repository such as https://github.com/nodejs/node https://github.com/nodejs/node press `.` (the full stop key) and it will take you away to github.dev, load Microsoft's VS Code in-browser to view and edit code with VS Code plugins and highlighting. And from there you can use GitHub Codespace to "develop in a cloud-hosted, customizable environment" to run and debug.
      - junon 5y ago
        And you can't even hit the back button. Incredible.
        junon 5y ago
        Apologies, I just read my comment again... To be clear, I'm talking about the VSCode app. Once you visit it they hijack the browser history and hitting back causes the entire app to reload, over and over again, until you manually drop down the history menu and jump 2+ pages back. I realize now my comment sounded rude and pointed toward the parent (not at all the intent) - I can't edit it so here I am again.
        5y ago
- indymike 5y ago
  > 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. Smalltalk has always went in the amazing language to look for inspiration from. Commercial implementations were pretty pricey (I think in the thousands). Ultimately, smalltalk really fell out of favor because: * Bad story on concurrency and multiprocessing. * Wasn't really all that portable. * Tightly bound with development environment. * Resource hungry mostly due to being tightly bound to the ide, and many implementations required the IDE to ship with the product. * Expensive I learned a lot about object oriented development from playing with smalltalk, and was able to employ a lot of what I learned using Java, Python, C#, Objective C, and C++. To this day, you really see a lot of code editing and management concepts that started in smalltalk in your favorite IDE.
  - igouy 5y ago
    > * Bad story on concurrency and multiprocessing. Mostly non-premptive lightweight concurrency (with the multiprocessor exception Actra) > * Wasn't really all that portable. iirc Just copying files from MacOS to MSWin to Unices was enough to port software. > * Tightly bound with development environment. That was considered to be a feature not a bug. > Resource hungry mostly due to being tightly bound to the ide, and many implementations required the IDE to ship with the product. The IDE could be stripped-out. > * Expensive Everything is expensive when the alternative is free-as-in-beer. > Ultimately, smalltalk really fell out of favor because: "The Rise and Fall of Commercial Smalltalk (2020)" https://news.ycombinator.com/item?id=29223880 https://news.ycombinator.com/item?id=29223880
overgard 5y ago
I don't really understand this perspective, I remember using Smalltalk VisualWorks back in 2005 and it didn't even have syntax highlighting. I'm unclear why an IDE is more needed than another language. If anything java and c++ are way more IDE dependent because it's hard to know what parameters mean by their position, whereas in smalltalk they're named.
- igouy 5y ago
  The IDE presents code in context — a method source is presented within the context of a class; a class source is presented within the context of superclass and sublcasses. And then the fun starts — https://www.researchgate.net/publication/3422160_Tools_for_making_impossible_changes_-_experiences_with_a_tool_for_transforming_large_Smalltalk_programs https://www.researchgate.net/publication/3422160_Tools_for_m... "Tools for making impossible changes - experiences with a tool for transforming large Smalltalk programs"

mumblemumble 5y ago

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.

rileymat2 5y ago
It is funny, one of the things that has bothered me for quite a while is that diffs don’t understand code. For example if I add an additional usage to a global variable to a file, while someone else renames it in other files, git happily merges with no conflict. Tighter language integration can help with that.
- k1ll3r 5y ago
  you can write a diff tool that talks to an LSP server
- nick__m 5y ago
  This tight integration between language and general purpose tool is a nice idea with a terrible price. It would make tools a lot harder to develop and they would be a lot slower as they now have to perform significantly more work.
- rfw300 5y ago
  That strikes me as outside the scope of a feasible version control tool (and is probably undecidable in most cases). Seems like you’d be much better off handling that with a test suite and CI.
  - rileymat2 5y ago
    I kind of agree, but if you have a very tight coupling, you could version control objects of the language and not text files. For example, a function could be versioned as a function, not a chunk of text. For example, I have seen cases with diffing where based on whatever algorithm, a very small logical change, (like moving a function up or down in the file along with a minor edit), creates a very confusing side by side diff based on whatever similar lines it think match up.
- isoprophlex 5y ago
  There's automated testing in a ci/cd pipeline to catch that, I suppose...
- mananaysiempre 5y ago
  It can, but like with other “rich” structures (type systems, data schemas, IDLs...) there is usually no single good solution, and when you need different ones to interoperate (either because you hit the limits of one of them or because you need to bridge two preexisting systems) you need to write a lot of tedious boilerplate at best and are completely stuck at worst. AFAICS that’s why amorphous sequences of bytes won as the fundamental (absence of an) abstraction in many places (files, networks, RAM, etc.). I would very much like for this not to be true, but there doesn’t seem to be a good solution. With syntax trees in particular, it’s also frequently difficult to find even a single good option for what you would reasonably want a diff to be: last I checked rich-text diffs usable over arbitrary HTML (even sans CSS) still sucked in half the cases you’d want. Line- and word-based diffs over the source also suck, naturally, but at least they do so uniformly. It’s not an accident Stack Overflow will usually try to show you a rich-text diff when editing but will occasionally fall back to word-diffing the Markdown. And a version control system needs to interoperate above all. Unlike, say, an IDE, and you do see attempts at semantic and even structured editing in IDEs. /me continues to fantasize about interbreeding Paredit and Pijul one day
- smasher164 5y ago
  Git allows you to use a custom diff tool for a specific file format. The problem is that these centralized source hosting/review tools only let you do about half of what Git can do.
Dylan16807 5y ago
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.)
- b3morales 5y ago
  How would GitHub or Bitbucket go about "installing" Microsoft's or Apple's proprietary tools on their website?
  - jodrellblank 5y ago
    On Microsoft Github, in a repository such as https://github.com/nodejs/node https://github.com/nodejs/node press `.` (the full stop key) and it will take you away to github.dev, load Microsoft's VS Code in-browser to view and edit code with VS Code plugins and highlighting. And from there you can use GitHub Codespace to "develop in a cloud-hosted, customizable environment" to run and debug.
    - junon 5y ago
      And you can't even hit the back button. Incredible.
      - junon 5y ago
        Apologies, I just read my comment again... To be clear, I'm talking about the VSCode app. Once you visit it they hijack the browser history and hitting back causes the entire app to reload, over and over again, until you manually drop down the history menu and jump 2+ pages back. I realize now my comment sounded rude and pointed toward the parent (not at all the intent) - I can't edit it so here I am again.
      - 5y ago
indymike 5y ago
> 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. Smalltalk has always went in the amazing language to look for inspiration from. Commercial implementations were pretty pricey (I think in the thousands). Ultimately, smalltalk really fell out of favor because: * Bad story on concurrency and multiprocessing. * Wasn't really all that portable. * Tightly bound with development environment. * Resource hungry mostly due to being tightly bound to the ide, and many implementations required the IDE to ship with the product. * Expensive I learned a lot about object oriented development from playing with smalltalk, and was able to employ a lot of what I learned using Java, Python, C#, Objective C, and C++. To this day, you really see a lot of code editing and management concepts that started in smalltalk in your favorite IDE.
- igouy 5y ago
  > * Bad story on concurrency and multiprocessing. Mostly non-premptive lightweight concurrency (with the multiprocessor exception Actra) > * Wasn't really all that portable. iirc Just copying files from MacOS to MSWin to Unices was enough to port software. > * Tightly bound with development environment. That was considered to be a feature not a bug. > Resource hungry mostly due to being tightly bound to the ide, and many implementations required the IDE to ship with the product. The IDE could be stripped-out. > * Expensive Everything is expensive when the alternative is free-as-in-beer. > Ultimately, smalltalk really fell out of favor because: "The Rise and Fall of Commercial Smalltalk (2020)" https://news.ycombinator.com/item?id=29223880 https://news.ycombinator.com/item?id=29223880

overgard 5y ago

I don't really understand this perspective, I remember using Smalltalk VisualWorks back in 2005 and it didn't even have syntax highlighting. I'm unclear why an IDE is more needed than another language. If anything java and c++ are way more IDE dependent because it's hard to know what parameters mean by their position, whereas in smalltalk they're named.

igouy 5y ago
The IDE presents code in context — a method source is presented within the context of a class; a class source is presented within the context of superclass and sublcasses. And then the fun starts — https://www.researchgate.net/publication/3422160_Tools_for_making_impossible_changes_-_experiences_with_a_tool_for_transforming_large_Smalltalk_programs https://www.researchgate.net/publication/3422160_Tools_for_m... "Tools for making impossible changes - experiences with a tool for transforming large Smalltalk programs"