> well, they aren't doing the demanding, if you're the one who wants those shiny features!
That's just the thing: they use all of these browser based UI technologies, these slower scripting languages and other ways to ship software in a reasonable time and so i could have the actual fancy features that pertain to the logic...
...except that I'd be far happier if they hadn't cut those corners and I'd have a fully native app using the OS UI frameworks and so on. Of course, that isn't possible, if I want the software in the next few years, not a decade from now, or much more expensive (at least that's the prevailing argumentation).
In my eyes, it is the coupling between the desirable bits (what the software actually does) and the undesirable bits (mostly how it does it). But it's all about tradeoffs, similarly to how we often choose to ship code that isn't thoroughly tested just to meet some deadline.
Those technologies that make the IDE slow are the ones that improved the productivity of the developers of the IDE and let them deliver those features in a fraction of the time they would have needed 20 years ago. So their productivity improved. The productivity of their customers, I don't know. I'm not one of them and I can't judge. I guess it's a matter of the tradeoffs you wrote about.
IDEs 20 years ago were not vastly insufficient and there were many “RAD” (rapid application development) tools for those that leaned towards high level languages. Some were abominable like Visual Basic, but many of the web platforms used today are equally poor performers.
The modern GUI designers in IDEs are notably better, but many shops don’t take advantage of them due to issues with slow performance (eg storyboads in xcode) and issues with multiple developers modifying the resource files simultaneously.
Refactoring and static analysis tools are improved as well, but none of these improvements afford orders of magnitude in efficiency.
The biggest gains in efficiency come from the extended libraries, open source code, ORMs, and the fact that most of what is coded has already been built by someone into a framework or library.
Software development does not now require the expertise of knowing the intimate details of the code and how it works. Many modern apps are plugging together libraries that developers do not understand and are unable to fix any issues in those libraries. The default now is to Copy / paste from Stackoverflow or submit an issue to the library maintainer on github and pray that it gets fixed; or find another library and swap that in. Software development (especially web development) has become a more decentralized effort usually resulting into in a mishmash of layers and dependencies whose inefficiencies are allowed by the amazing hardware. Unfortunately, performance and user experience are sacrificed to the interests of “efficiency” and using the latest language/platform fad of the year.
That's just the thing: they use all of these browser based UI technologies, these slower scripting languages and other ways to ship software in a reasonable time and so i could have the actual fancy features that pertain to the logic...
...except that I'd be far happier if they hadn't cut those corners and I'd have a fully native app using the OS UI frameworks and so on. Of course, that isn't possible, if I want the software in the next few years, not a decade from now, or much more expensive (at least that's the prevailing argumentation).
In my eyes, it is the coupling between the desirable bits (what the software actually does) and the undesirable bits (mostly how it does it). But it's all about tradeoffs, similarly to how we often choose to ship code that isn't thoroughly tested just to meet some deadline.