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.
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.)
And from there you can use GitHub Codespace to "develop in a cloud-hosted, customizable environment" to run and debug.
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.
The proposition here is that the IDE provides dev process tooling so you are in fact collaborating with your team, e.g. reviewing your code, but Github (Microsoft) and other centralized services are not necessary and not included in the activity. And yes, if AWS etc goes down, your IDEs will continue to work and you can continue to collaborate.
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.
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.
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
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.
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)"
And then the fun starts —
https://www.researchgate.net/publication/3422160_Tools_for_m...
"Tools for making impossible changes - experiences with a tool for transforming large Smalltalk programs"
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.