-- Leo's gemini proxy
-- Connecting to circadian.gemlog.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
My recent post about proportional fonts triggered a further response which cited a rant about IDEs.
Thanks Sean for the reply! It’s nice to hear how people got here.
Let’s forget about proportional fonts, you raised a much more fun topic: IDE hate.
Just what exactly is going on here? An IDE is an editor with more tools plugged in—it’s “integrated”. It’s an “environment”.
Nobody building an IDE is doing so with the goal of annoying developers, at least I hope not. So why so much negativity?
IDEs aren’t exactly set up to succeed; the promise is right there in the name. They’re supposed to do everything—they are supposed to be the very environment in which you develop.
Because they’re supposed to do everything, IDEs are one of the few projects where there is no such thing as feature creep; any feature you can imagine belongs in an IDE.
Ouch.
If you’ve ever tried an IDE then you’ve probably had an experience like Sean’s; you powered through irrelevant-seeming configuration, broken features and unreasonable hangs and slowdowns, then gave up.
This is more or less the canonical first IDE session.
At that point you have a choice: you can give up and fall back to an editor that just works; or you can persevere and slowly build up the bag of tricks that you need in order to be productive with an IDE. Some things will make sense. Some things won’t. Sometimes there will be an update and it breaks under you and you have to figure out some new tricks.
I’m not going to argue for one of the two options here. It is, of course, and should always remain: entirely up to you.
Be thankful that you had a choice.
I’ve worked in roles where part of my job was to worry about the productivity of all users of a particular language at the company. That made anything that could go wrong in any developer setup—any editor or IDE—my problem.
And so I have a pretty close appreciation for what goes wrong.
There are three extremely hard problems that must be solved for an IDE to work as I want it to work.
When I tried Eclipse, I guess it was around 2010, I measured it at hundreds of milliseconds between keypress and visible response. That’s much too slow—and why I switched to IntelliJ, which clocked in at 20ms or so.
When Sean tried Eclipse in 2012, it crashed. If the IDE is your world and your world crashes, well, that’s a bad time.
Building complex systems in a way that is reliable and fast is hard; I’m not going to minimize it. It requires disciplined design: strict tiers of functionality with fault barriers and performance bailouts.
If an IDE takes hundreds of milliseconds to perform edit operations, those tiers are missing; it’s mixing up critical work with lower priority work. If it can crash, well, that’s the same problem.
An IDE is akin to an OS, and it needs to be built like (a good) one.
There’s a really popular approach to end to end testing and monitoring: don’t.
Testing UIs is hard; testing complex integrated systems is hard. Unfortunately, these are exactly the places you really need testing. Monitoring is the same story.
The difference between a million line codebase that everyone is scared to touch and a million line codebase that is a joy to work on, is end to end testing and monitoring.
One of the dubious pleasures of living in IDE land is that something might break from one day to the next, and you’ll have to work around it until you figure out the fix or someone else does.
If a user flow is important, it must be tested. If it’s important that it’s fast, it must be monitored.
Testing with UIs is an area that is now pretty well understood; I don’t know if web testing was the first to do it well, but the page object pattern:
is an example of treating UI testing as a first class concern. It means that alongside building your UI you also build an API for programmatically manipulating the UI for testing.
This done, adding end to end tests is fast and fun. You’ll have a UI that works and is guaranteed to keep working.
IDEs must be built using large scale engineering best practices and tooling.
Distributed dev tooling configuration is an absolute nightmare, and IDEs are the worst offenders by far.
The problem with any local configuration—by which I mean, configuration that the user must set up and maintain manually—is that it’s very often wrong. They make a wrong choice on one setting and take a 5% productivity hit as a result; they have a stale setting for the next and lose another 2%. And so on, and so on; across a thousand engineers you quickly lose whole teams worth of productivity to misconfiguration.
Then IDEs come onto the scene with unstructured, confusing configuration and no configuration management. Did I say unstructured? It’s probably XML.
The correct way to do this as a large company would be to have known-good configurations, thoroughly covered by end to end tests and automatically pushed to everyone; then with a way to keep your own delta on top, and monitoring for any problems that result.
We never built such a thing, so we relied on guidelines, one-time setup scripts and ad hoc fixes; it still haunts me to this day.
Fortunately, someone has been working on these problems—and it turns out, they were at Microsoft:
VSCode seems to be an IDE I can not just put up with but really like.
I haven’t looked too closely, but it seems that the design is correct for reliability and performance. VSCode is fast when it should be fast, and does not crash. I can only assume that end to end testing and monitoring played some part in achieving this.
They introduced the Language Server Protocol, completely splitting out the most heavyweight part of the IDE “experience”. In fact, as a result, you can now plug “IDE smarts” into whatever editor you like.
There is no long-winded “workspace setup”. Just `code <path>`, or `code -r <path>` to reuse an already-launched window.
Configuration is in JSON, not XML; okay. But the thing that really matters in this problem space is that you can easily view your configuration as a delta on top of the defaults, and edit that as data. Finally: an acknowledgment that just asking everyone to set every individual settings correctly does not work.
IDEs have been around for decades, and disliked for almost as long; I think the root of the issue is that IDEs are very hard to build right, and deeply frustrating when not perfect. Fortunately, there has been some solid progress.
There is still of course personal preference; I’m not arguing for IDEs or for or against any particular editor. I’m just excited to have real progress in the options available.
My post also got a non-reply,
so thanks for that. I do find coding this way extremely pleasant. I hope you all might also find an extremely pleasant way to code, whatever that should mean! It’s great.
So far today, 2024-05-13, feedback has been received 9 times. Of these, 0 were likely from bots, and 9 might have been from real people. Thank you, maybe-real people!
———
/ \ i a
| C a \ D n |
irc \ /
———
-- Response ended
-- Page fetched on Mon May 13 15:58:43 2024