>It will be interesting to see if the SaaS subscription/rental model changes this.
I think the rental model will slow this down, but not get rid of it entirely: not as long as people still want to write blogs about the "new version of our product". I think JetBrains will make a good case study: their products are feature complete and they seemed to struggle to find new features to add lately (plus they have switched to rental model).
What we really need is something similar to API versioning: when GMail has a new version, bump up the version to 24, but keep version 23 accessible to those who prefer it.
> I think JetBrains will make a good case study: their products are feature complete and they seemed to struggle to find new features to add lately (plus they have switched to rental model).
What Jetbrains MUST do: improve the performance! Replacing my MBPs spinning rust disk with a SSD helped, but it's still eating up CPU when running on battery with indexing... it's a text editor for fucks sake.
Acrually, it's not a text editor: it's an IDE. How do you think all the fancy find usages, highlighting errors, and general contextual knowledge works? The IDE is constantly reparsing every time you make a change.
It totally is a glorified text editor + some support tools and I'm pretty sure the reason it's eating that CPU is because of piles of unoptimized cruft. Like every other big project in contemporary "it's nil until you ship it" culture.
PhpStorm/WebIDE is definitely not a glorified text editor.
Editor is definitely the core but all the support tools make a big chunk of features and usage. Sure, I can get quite a lot of those features in Sublime with some packages but they aren't that well integrated and easy to use!
I use Emacs for almost everything, so I'm pretty aware where text editing ends and support processing starts.
That said, consider Microsoft Word. Since forever, it's been doing similar - if not greater - amount of work processing and reprocessing text every keystroke than IDEs contemporary to it. Yet somehow, it is not bloated, it does - and always did - work well on even low-tier machines. Also compare with OpenOffice, which does more-less the same things, only much slower and buggier. If M$ can keep Word functional and performant, I'm pretty sure Eclipse and IntelliJ could be made fast as well.
You were doing well, right up to the moment you stated that Word is not bloated and compared it to OpenOffice (who even uses OpenOffice? Everyone with any clue uses LibreOffice!).
P.S. as someone who has commit access to LibreOffice (and much to everyone else's chagrin, sometimes uses it), I could be a little bit biased.
In my experience of using Word - since mid-90s 'till today - I've never felt it's bloated. It has a lot of features, yes. I don't know what half of them do, true. Recent versions hide them in random places and made the thing a bit confusing to use. But it almost never locks up, it lets me enter text as fast as I type even in very large documents, and generally feels... slick. Not something I could say about OpenOffice when it was "the thing", not something I can say about LibreOffice (sorry). I know that M$ has a pile of hacks going on there, but hey, it works.
OTOH, all Java IDEs I've used so far lag by default. It's often about the little things - like those 1 second delays in menus, or 100ms delays between keystroke and letter appearing on screen, etc. Enough to make the experience frustrating. If I keep using them it's only because some advanced features don't have an equivalent (or easily installable equivalent) in Emacs. But it's a tradeoff between having a powerfool tool that I use every once in a while vs. enduring the constant experience of bloat.
Features of IDEs are cool, but they seriously need to optimize them. And to stop assuming that every developer gets to work on a brand-new machine. Maybe it's true in the US, but it's not true in other places (sometimes because managers don't see a problem with paying developers $lot but then being cheap on the equipment those same developers have to work on).
Your first paragraph is pretty much my definition of bloat. I've just come back to Word (work uses it) after a 10 year break. Things have got a lot worse (slower, hard to find, massive bloat, irritating layout) in that time imho.
Word 97 ran and opened faster on my old Pentium Windows 95 machine than Word 07 runs on my i5 Windows 7 machine. New features are great, but there is sluggishness and its unacceptable on modern hardware.
I don't know if this is the case for the parent post, but some people use LibreOffice while referring to it as OpenOffice.
I personally use LibreOffice quite a bit, but something about the name sounds silly to me, so I avoid speaking it. I usually refer generically to "a word processor" instead.
It is. After it being pointed out to me, I've recalled that I've been using LibreOffice for some time. Maybe I'm ignorant about the actual history, but I've always considered LibreOffice to be the continuation and rebranding of OpenOffice.
or use both: write (enter and rearrange text) in an editor, manage (refactor and debug projects) in an ide. i've found emacs + intellij to support a workflow for java that i couldn't easily duplicate with either on its own.
Off topic to bloated web sites, but: I like the subscription models of JetBrains, Office 365, etc. Long term, I think this business model will enable tighter more focused products because the "add new features to get update revenue" goes away.
So selling good feature-complete software is insufficient. People must be forced to keep paying for it at regular intervals, whether they need updates or not.
Software is the perfect product - it doesn't wear out, it doesn't go bad, if you really need to you'll be able to use software you got in 1990 in 2090.
For the software creator, once you've sold someone your software, the only way to make more money is to sell it to someone else, or create and sell a new version. Eventually you run out of someone-elses to sell to and can make new versions or go out of business.
... or sell a support contract or a subscription model.
I don't like it from a user's point of view, but squaring my preferences as a user with preferences of business isn't easy.
It's not just software. Most of the things we buy and use are being purposefully broken because otherwise they wouldn't wear out fast enough. That's the sick side of capitalism.
Well sure, but there's an ultimately sustainable business model if your product needs replacing in 30 or 50 years. (Leaving aside the things like marketing claims of a "30 year" or "lifetime" warranties from a company with a 10-year lifespan.) Capital needed for initial production is then the only issue. But there isn't such a model if the product never needs replacing again.
30-50 years of replacement time is apparently not sustainable, since most of the things we buy have 3-5 years of expected lifetime tops. As for software, the entire tech industry, including its hardware areas, is nowhere near stabilizing yet. Most software has to be replaced after at most 10-15 years, either because of security issues or just because it's no longer supported by hardware. There are exceptions, yes - software written for Windows 95+ is still alive and kicking, but because most software has to interact with other software eventually (even if by exchanging files), it has to keep up. The rise of web and mobile applications has sadly only sped it up.
Maybe one day we'll reach the times when programming is done by "programmer-archaeologists", as described by Vernor Vinge in "A Fire Upon the Deep", whose job is to dig through centuries of legacy code covering just about any conceivable need, to find the snippets they need and glue them together. But right now, software gets obsolete just as fast as physical products.
> 30-50 years of replacement time is apparently not sustainable, since most of the things we buy have 3-5 years of expected lifetime tops.
In practice, yes, most things we buy are designed to fail. But in principle 30 years is possible, if anyone is willing to pay for it. Lots of people aren't, for many reasons including time cost of money, fashion, or just not caring.
> Most software has to be replaced after at most 10-15 years, either because of security issues or just because it's no longer supported by hardware.
Yes, so there's the answer for why the software upgrade treadmill exists: it's for software not important enough to run on dedicated separated hardware. Few people are upgrading CNC controllers or power plant controllers or aeroplane controllers because of security issues or because the hardware is no longer available.
Anyway, even on the consumer side the lifespans are rapidly lengthening. In the 1990s running current software on five-year-old computers or using a five-year-old OS would have been basically unheard of in the mainstream. Today a five-year-old computer is only a step behind current and Windows 7 has turned 6 years old and is still extremely widely used.
> n practice, yes, most things we buy are designed to fail. But in principle 30 years is possible, if anyone is willing to pay for it.
My mom is still using a cooking stove she bought in 1982, as a second hand purchase. Parts of it have been repaired/replaced, but I don't think they make em like they used to: I doubt a 2016 stove will make it to 2049.
It's not that creating more durable products is significantly more expensive (it could, and was done in the 80s), its that manufacturers cut costs of manufacturing and their B.o.M. in the interest of maximising profit.
The "rot" is because the environment is changing (the hardware you're running it on, other software you need to interact with) or the software is being carelessly updated.
If you need to, software rot can be eliminated. It takes effort but it can be done.
To give an example: you can run a space station with software installed in the 1980s, but you probably can't run a space station with seals or pumps installed in the 1980s.
I think the rental model will slow this down, but not get rid of it entirely: not as long as people still want to write blogs about the "new version of our product". I think JetBrains will make a good case study: their products are feature complete and they seemed to struggle to find new features to add lately (plus they have switched to rental model).
What we really need is something similar to API versioning: when GMail has a new version, bump up the version to 24, but keep version 23 accessible to those who prefer it.