Corbet asked, "[A]re we too focused on the accumulation of features at the expense of the design of the system as a whole?"
To this question, I will opine yes, there are many in the industry who focus on adding features rather than fixing what already exists. Take udev, for example. Every time I upgrade udev in my firewall project, it's weeks before it works again. And now udev can't be built by itself; it requires a bunch of stuff I neither want nor need. GCC: I had to change a bunch of C++ source code to handle syntax changes between 3.5 and 4.3. And now 4.6 won't build old grub (last I checked).
It comes down to adherence to the old 'grow or die' adage. Far too many believe their software will die if they don't pile on the features--creeping featuritis. Far too many have forgotten the basic principles of UNIX utilities, one of which is, "Do one thing, and do it well."
Posted Aug 21, 2012 7:26 UTC (Tue) by khim (subscriber, #9252)
[Link]
This is great post. It shows what's really wrong out there.
Well, it's starts in the usual fashion:
To this question, I will opine yes, there are many in the industry who focus on adding features rather than fixing what already exists.
This is usual complaint - nothing new here.
Take udev, for example. Every time I upgrade udev in my firewall project, it's weeks before it works again. And now udev can't be built by itself; it requires a bunch of stuff I neither want nor need.
The fascinating stuff is that as example of "feature creep" we have rare project which concentrates on removing duplicated features.
Basically these two items boil down to: features are evil, we need to ged rid of them… except for the ones I want to use, of course.
GCC: I had to change a bunch of C++ source code to handle syntax changes between 3.5 and 4.3. And now 4.6 won't build old grub (last I checked).
The same tune again: GCC removed features which it was not supposed to have in the first place and now sky is falling. So yes, again: features are evil, but the ones I personally need are vital.
Far too many have forgotten the basic principles of UNIX utilities, one of which is, "Do one thing, and do it well."
Why do you think people forgot about this? They remember that motto. But smart ones remember that it's motto of a system which is dead and buried, as well (it's descendants are alive and some of them are even widely used, but they all violate said motto in one way or another).
Kamp: A Generation Lost in the Bazaar
Posted Aug 21, 2012 15:41 UTC (Tue) by JEFFREY (subscriber, #79095)
[Link]
"But smart ones remember that it's motto of a system which is dead and buried"
*Not* dead and buried. Those of you who wish to write massive bloatware and spend the rest of your lives debugging, have fun.
The real smart ones will settle for "worse is better," and "Doing one thing well [enough]." And those who do will not be stuck in a quagmire of runtime engines and debuggers. They are the ones who will actually get their tasks done and their legacy will be a handful of scripts that are still used years after their authors' deaths.
Kamp: A Generation Lost in the Bazaar
Posted Aug 21, 2012 16:18 UTC (Tue) by khim (subscriber, #9252)
[Link]
The real smart ones will settle for "worse is better," and "Doing one thing well [enough]." And those who do will not be stuck in a quagmire of runtime engines and debuggers. They are the ones who will actually get their tasks done and their legacy will be a handful of scripts that are still used years after their authors' deaths.
You mean things like TeX? Sorry to disappoint you but it was on fast-track to extinction and oblivion before it's descendant embraced "feature creep" approach which may be, just may be, will give a new lease of life.
*Not* dead and buried. Those of you who wish to write massive bloatware and spend the rest of your lives debugging, have fun.
You may spend the rest of lives doing mostly pointless work of writing massive bloatware and debugging it or you can spend your time and write handful of scripts that are still used [many] years after their authors' deaths where many will be equal to two, or, if you are lucky, for ten.
I try to keep scripts intended for my own consumption as small and simple as possible because they are not the point (the result of their work is), but if you want to write some program for someone else then you only have two sensible choices:
Write massive bloatware and hope that it'll be useful in the future.
Write lean and mean system which will not be useful with almost 100% certainity.
Choice is yours, but I'm not sure why you think second outcome is preferable.
Kamp: A Generation Lost in the Bazaar
Posted Aug 21, 2012 17:14 UTC (Tue) by JEFFREY (subscriber, #79095)
[Link]
I was thinking more along the lines of tar.
Kamp: A Generation Lost in the Bazaar
Posted Aug 21, 2012 18:54 UTC (Tue) by rgmoore (subscriber, #75)
[Link]
I'm not sure how well tar fits with the "do one thing and do it well" motto anymore. Source code for the latest version of GNU tar weighs in at 13.5 MB and 825 files. It has more than 40 single letter command line switches and over 100 full command line switches. It may have been a nice, simple program once, but we've kept asking it to do more and more things until it became a monster.
I think this kind of thing is more or less inevitable. We've been asking our computers to do more and more, and you can't do that without adding more complexity somewhere. It can either be at the level of adding more simple, single-purpose programs or at the level of adding complexity to existing programs, but one way or the other the system gets more complex. The only way we can keep the nice, simple, clean Unix that we had 30 years ago is to stop asking it to do more than we did with it 30 years ago.
Kamp: A Generation Lost in the Bazaar
Posted Aug 21, 2012 20:38 UTC (Tue) by raven667 (subscriber, #5198)
[Link]
Well said.
Its always an interesting thought experiment to see how much of what we do with modern systems can fundamentally be done with 30yr old tech. Instead of HTTP and the Web there was Telnet or 3270 which fulfilled much of the same goals as an application delivery platform. Graphics would be right out but the core functionality of apps like Twitter, Facebook, GMail, word processing and office apps etc. could be done on 30yr old systems. Maybe the biggest problem would not be functionality but scale, no system of the day could scale to the many millions of active users that current systems support, AFAIK.
Kamp: A Generation Lost in the Bazaar
Posted Aug 21, 2012 16:23 UTC (Tue) by adobriyan (guest, #30858)
[Link]
Bonus points for getting away with it and not being cursed dozens of years after your handful of scripts being put into production. But I guess dead authors do not care.
Accumulating features is an essential design component
Posted Aug 21, 2012 15:58 UTC (Tue) by southey (subscriber, #9466)
[Link]
Most open source projects pride themselves on backwards compatibility so your overall system design must accumulate features. Somehow the kernel needs to handle a external hard drive using many different interfaces plus one of those also connects to the display (not a reality 21 years ago). Now there is Intel's plan for recharging using WiFi.
Sure, with incredible vision, developers have gone back to change the design (IDE-SCSI?, merging i386 and amd64 subkernels). But that is code refactoring not design.
However backwards compatibility has to end for various reasons. Probably with GCC it is related to handling and enforcing different standards as much as new features. It is not really effective to maintain K&R's 1978, ANSCI's 1983, C89/90 in 1990, C99 in 1999, C11 in 2011 in the same compiler. Also, code should be maintained so depreciated features (or non-standard functionality) are removed. Otherwise you have to go back in the time machine and use the contemporary tools of the same age as the code.
Accumulating features is an essential design component
Posted Aug 21, 2012 22:48 UTC (Tue) by nix (subscriber, #2304)
[Link]
With GCC, with a very few exceptions (the removal of a few ill-thought-out language extensions in 4.0, the removal of 'traditional mode' for complexity, ill-definedness, and no-one-uses-it reasons), most code broken by new GCC releases was simply buggy all along, but GCC was incorrectly accepting it. GCC never supported C83, and nothing post-C89 has ever been removed (nor, likely, ever will be). C78 was never supported either: traditional mode supported C78 plus a bunch of common vendor extensions plus a *lot* of bugs because traditional mode was basically never used by anyone for anything for decades before its removal.