Code Cleanup Culls LibreOffice Cruft 317
mikejuk writes with an interesting look at what coders can get around to after a few years of creating a free office suite: dealing with many thousands of lines of deprecated code: "Thanks to the efforts of its volunteer taskforce, over half the unused code in LibreOffice has been removed over the past six months. It's good to see this clean-up operation but it does raise questions about the amount of dead code lurking out there in the wild. The scale of the dead code in LibreOffice is shocking, and it probably isn't because the code base is especially bad. Can you imagine this in any other engineering discipline? Oh yes, we built the bridge but there are a few hundred unnecessary iron girders that we forgot to remove... Oh yes, we implemented the new chip but that area over there is just a few thousand transistors we no longer use... and so on." Well, that last one doesn't sound too surprising at all. Exciting to think that LibreOffice (which has worked well for me over the past several years, including under the OpenOffice.org name) has quite so much room for improvement.
Automate it (Score:4, Insightful)
Sounds like they already put a lot of work into this, but someone should tell them that you can automate things like removing unused code.
A Natural Consequence of Change (Score:4, Insightful)
...lots of stuff is left lying about which might not be used any longer on the off chance that it might be adapted to some future purpose. Sounds like genetics.
Still no update system... (Score:4, Insightful)
Physical to virtual comparison (Score:5, Insightful)
Can you imagine this in any other engineering discipline? Oh yes, we built the bridge but there are a few hundred unnecessary iron girders that we forgot to remove...
Those would be perfectly valid if upon discovering your girder was 3 inches too short you could instantly create a copy of it, set the original aside, then alter and test that copy of the girder. Then you might leave a few extras lying around.
Bad examples (Score:5, Insightful)
Bridges often have unused structural elements: walk-ways made unsafe by modern traffic levels, maintenance accesses unused for safety reasons, supports made redundant beyond the factor of safety by bridge improvements, etc. Chips and boards too: FPGAs with 10% utilization, chip designs re-purposed with functional components disabled, subsystems replaced in boards by new designers not confident enough to remove the old design, etc.
Cruft in software is more often removed because (1) software has a potentially longer lifetime than hardware and (2) it's a lot easier to remove an uncalled function from a program than a girder from a bridge! Software cleanup should be an expected and planned part of a project's life cycle.
Re:Not at all. I've had a house built. (Score:5, Insightful)
I've seen chemical plants built with millions of dollars worth of unnecessary piping and valves, because the project timeframe meant that it was cheaper to install extra connections that might never be used and save engineering time than waste time re-engineering it.
If removing unnecessary items can save thirty thousand dollars (say) at the cost of three days, removing the cruft is only worth it if the delay costs less than ten thousand a day.
Re:It doesn't matter (Score:0, Insightful)
Except for the fact that the machine I'm on right now is running Win 7/64 and is using 900megs with apps running. Thanks for trolling though.
Remember kiddos, when you have to make up fake numbers to support your point of view you're normally wrong. And an asshat.
Re:Bad examples (Score:4, Insightful)
It's not crazy. A major board redesign will set a schedule back three months or more, so if you have two options and aren't sure which one will work, it's not uncommon to design for both if you have the room. Maybe you're evaluating two vendors. There are also usually components that are only used during development. Sometimes there's an experimental or premium feature that requires an extra chip, but you don't want to make two boards. Of course, most of the time unused components get left off in mass production, but developer's boards or ones from prototype runs might still have them.
Re:Not at all. I've had a house built. (Score:5, Insightful)
No, a better analogy is to build a house (full of extra materials as the parent said), and then use a giant replicator machine to mass-produce the house, almost instantly, and create thousands and thousands of new homes using that house as the basis. The wasted material in the one house is bad, but not that bad because it's one house, and it takes extra time and labor to do it more efficiently. But multiplied across thousands of identical copies, that wasted material adds up a lot. Plus, it's inefficient and you could have a better-performing house by doing a better job with the small details (better at energy efficiency for example). The slight increase in energy efficiency with that one house, realized by spending a bunch of extra time and effort removing wasted materials and doing a better job with various small details (like making sure the house wrap is applied extremely well rather being hurried and missing some staples in important places), won't amount to much with just the one house. However, multiplied across many thousands of houses, those energy savings add up to a lot.
The fact that software is easily and quickly replicated with perfect precision and little or no effort or time really makes it hard to make good analogies for it without resorting to Star Trek-style replicators; it's the only technology we have that's like that. And because it can be and is copied so easily, very different dynamics apply to it than to many other fields of endeavor.
Comment removed (Score:5, Insightful)
Re:Worked Well? (Score:4, Insightful)
"WORKSFORME"
The most unhelpful response to a bug report ever.
But very helpful response on trolling.
Re:Automate it (Score:4, Insightful)
I'm pretty sure that they don't want to automate it. One of the first things Libre Office did after they forked from OO.o was to come up with a list of "easy hacks" for people who wanted to get involved but didn't know where to start. That includes stuff like dead code removal and translating comments from German to English. By leaving that stuff marked out but undone, they hope to ease new people into the project. That may not be the most efficient way of doing this kind of thing, but if it helps to recruit new developers it will do a lot more for the project in the long run than just getting rid of the cruft. It's a big difference between a project run by paid coders on a tight budget and one that depends on a variable number of volunteers.
Re:Not at all. I've had a house built. (Score:3, Insightful)
"Wooooosh"
Re:It doesn't matter (Score:4, Insightful)
Re:I'd bet there is. (Score:2, Insightful)
I always wonder why OOP advocates think that making structured and modular code is not possible in anything else than OOP languages. Truth is, those concepts appeared long before them, and, in fact, were some of the ideas that drove the birth of languages like C
If your C programs are not modular and structured you can bet I'm not going to hire you.
Re:Don't know about LibreOffice (Score:2, Insightful)
Re:It doesn't matter (Score:5, Insightful)
Many its GUI controls are using very bad confusing abstractions. For example, audio, networking, etc.
They are necessary abstractions because these subsystem themselves are abstractions.
If you want confusing audio subsystems, look at the mess in Linux right now.. most Linux installs literally have multiple audio subsystems that can output to each other in very confusing master/slave relationships.
Re:Not at all. I've had a house built. (Score:4, Insightful)
This is true in Europe too. I'm in Scotland. I live in a small but comfortable house I built for myself on my own land last year. It cost in total more than I earn in one month, but less than I earn in two. I'm a senior geek, I get a good wage - but I'm not a banker or a pop-star.
What makes housing expensive is partly labour, but it is mainly that planning policy creates a form of artificial scarcity, and partly also that government support for home ownership creates a speculative bubble, further inflating the cost. Housing is not intrinsically expensive.