While software bloat is undeniably a problem, in my experience it's not that clear-cut.
E.g., a messanger app built on Elector is a pure bloat. At least, from technical perspective -- maybe Electron brings in business value that outweighs the technical downsides.
But an IDE from around 2005 is nothing more than a dumb notepad in comparison to a modern JetBrains IDE. Even though I often find their IDEs extremely frustrating in terms of consumed computational resources, I'd rather upgrade my hardware than go back to something less "smart". After all, hardware is just a means to an end of solving whatever task at hand.
Cut to 20 years from now, you may remember JetBrains as the best thing you had worked on - and that some other JavaScript IDE in 2043, which requires a bare minimum 128GB of RAM to run - will be the means to that end for those developers.
See you in 20 years. :-)
As was Netbeans in 2005, or Delphi, VB, Visual Studio,....
JetBrains gets too much praise.
Please excuse me copying the relevant portion from my other comment.
VS 6's support of C++ back in 2005 wasn't that great, at leat the way I remember it now.
Code navigation was very primitive, and you were lucky if it didn't consider the code too complex to offer any navigation around it at all.
Its built-in debugger often wouldn't let you inspect a string's content because it was just another pointer from the debugger's perspective.
And there was a bug, where the editor would slow down so much it would be littery unusable -- e.g., it'd take a couple seconds to react to a key stroke. The reason was it kept a file with the workspace's (solution in today's terms) code metadata and that file grew too big over time. So you had to remember to delete it regularly.
But VS 6 had a great plugin -- Visual Tomato, if memory serves -- that made things so much better in terms of code navigation/refactoring/etc.
Anyway, I sure see how my comment may sound that way, but I didn't really mean to contrast JB vs others. Comparing a modern IDE to its old version in the context of software bloat is the whole point I'm trying to make.
I think bloat is not the only reason for increased hw requirements. Modern software is often way more capable than its old versions and adding capabilities seems like a good use of added hw power.
Visual Assist being a well known one.
It isn't as if JetBrains products aren't full of plugins as well.
I see how my comment may sound that way, but I didn't really mean to contrast JB vs others.
A better idea woud've been comparing a modern version of VS with VS 6, for example.
Anyway, my point is bloat is not the only reason for increased hw requirements. Modern software is often way more capable than the old and adding capabilities seems like a good use of added hw power.
This is a bit similar to the concept of accidental vs inherent complexity in sw engineering. There's accidental bloat and inherent "bloat", so to speak:)
My impression is people don't usually acknowledge the existence of inherent "bloat" in discussions like this one.
VS 6's support of C++ back in 2005 wasn't that great, at leat the way I remember it now.
Code navigation was very primitive, and you were lucky if it didn't consider the code too complex to offer any navigation around it at all.
Its built-in debugger often wouldn't let you inspect a string's content because it was just another pointer from the debugger's perspective.
But VS 6 had a great plugin -- Visual Tomato, if memory serves -- that made things so much better in terms of code navigation/refactoring/etc.
Writing C++ in Eclipse CDT or KDevelop was simply a pain.
Actually, a plain editor with syntax highlight was probably a better option because it was not even pretending to have "smart" features that would inevitably break on each non-trivial piece of code -- better no promises than false promises.
Delphi, and C++ Builder for that matter, were great as a package: fast GUI builder, editor, debugger, etc. That said, I don't remember them offering much in terms of working with code: finding an identifier usages, refactoring, etc.
As to praising JB, it wasn't my intent to single them out, surely there're other great IDEs. Their products is just something I'm personally familiar with. If something better happens to cross my way, I'll have no problems switching.
It was still mainstream in 2005, I think. Do you remember if I get that right? At least we were using it at work in 2005.
VS release cadence is much faster nowadays, isn't it? :)
The in my opinion the much more important reason was that Visual Studio 6 was the last version of Visual Studio that was capable of running under Windows 9x (every version of Visual Studio that was released after required some Windows-NT-based Windows version; Visual Studio .NET 2002 was the last version to run under Windows NT 4.0: Visual Studio .NET 2003 required at least Windows 2000; keep in mind that Windows XP came only out end of October 2001).
Which IDE is this?
I've used IDEs from the mid 90s (Watcom C/C++, Visual Studio 5.5, Delphi, C++ Builder) and from 2005, and they did a lot more than just let you edit code and run make.
In 2005, all major IDEs had autocomplete, for example. They also had jump to definition, jump to help (remember help pages? .chm files?), syntax highlighting, source-level debugging, inline with the source code ...
I mean, what exactly do you think they are missing that makes them a rudimentary text editing tool?
# Syntax highlight
Something seemingly as basic as syntax highlighting can be implemented based on syntactic or semantic analysis of the code.
There's even a more primitive way of implementing it, where an editor would just highlight the language's keyword and not much else. If memory serves, back at the time, most editors and IDEs would do the latter -- just highlight the keywords and be done with it.
Nowadays, semantic highlight is usually the default. Each identifier gets colored with the color of the symbol it resolves to. A constant name is rendered as constant throughout the file, not just in its declaration. Same applies for parameter, property, class, function names and so on.
# Semantic "grep"
As in, find all usages of, for example, a function across the project:
- If the function is passed as an argument somewhere (to be invoked as a callback later) this is going to be included in the search results.
- If another class has a function with the same name, this isn't going to end up in the search results.
- If the function is overloaded, it's possible to search for usages of a specific overload or all of them.
- And so on.
I don't remember this being a thing in old IDEs either at all or it didn't work for anything but the most trivial code. Although software like GNU Global did aim to implement this functionality, my memory is it was very limited in practice.
# Semantic code completion
While IDEs from mid 90s did have code completion, a modern IDE improves on that too. E.g., if you invoke auto-completion while writing a bit of code that passes an argument to a function, a modern IDE is able to form a list of suggestions containing only symbols that are currently in scope and match the function's parameter type.
# Refactoring
I think this goes without explanation, would you agree? Modern IDEs offer more refactorings, theses refactorings are way more complex and work much more reliably.
# Dependencies source code browsing/decompilation
Editing to add in this one. How could I forget? Basically, if I want to go to the definition of a symbol that comes from a library, the IDE will either download the source code if available or decompile the binary and and take me to the definition. To me personally, this is huge.
Syntax-highlighting - sure, nice to have based on semantic meaning of code, but keyword syntax highlighting works fine +90% of the time when you are reading code.
Semantic search - once again, now it's better than simple grep, but ctags provides 90% of that functionality too (I still use ctags daily in Vim).
Semantic code-completion - nice, but code completion in VS circa 2005 (and other IDEs, like eclipse) were partially semantic as well. They did not autocomplete a `#define` keyword when you typed the '.' after an instance variable, the completion was still limited to only those fields that were relevant to those instance variables. Once again I feel that the partially semantic autocompletion did maybe 90% of what Jetbrains does today.
As far as decompilation/third-party library support goes, in 2005 the languages did not have package management, so not automatically downloading the 3rd party library is not a fault of the IDE - where would it download from?
In those cases, like VS, where you were using the Windows SDK, VS itself knew where to get those libraries from (because they were stored locally), and I have many memories of the VS debugger in 2005 stepping into the Microsoft SDK libraries.
To me, comparing 2005 IDEs as the equivalent of a dumb text editor when they had 90% of what you have now, is an inaccurate comparison.
(Of course, all of the above is just my opinion, so feel free to disregard it with prejudice :-))
The only things that really need more resources are video capabilities and web technos.
For example there are window managers that were considered bloat 20-25y ago and that are considered lightweight. Icewm takes something like 16MB on a 64bit distro nowadays. It would have been considered bloat back in the days but is very far than what you are using with a default kde plasma or gnome desktop running idle without apps. There are still cli or gui lightweight music players, image viewers, word processors, spreadsheets tools, file managers, etc. Until you start a web browser and as long as you are using a lightweight DE you can run many modern linux distros with only 256MB of ram.
You would also need to ask how many people here actually use Raspberry Pis as their daily driver to claim the power benefits that they should be realizing today.
I think that viewing this as a pure power consumption exercise is very reductive at best. Then, in that spirit, you should also be going behind the people running the H100s today and asking why they aren't running their model training on a RPi 4 yet.