4 ms·
"This 'Worse is Better' notion that only incremental change is possible, desirable, or even on the table for discussion is not only impractical, it makes no sen
by cwyers 12y ago
"This 'Worse is Better' notion that only incremental change is possible, desirable, or even on the table for discussion is not only impractical, it makes no sense."
It makes all kinds of sense. Consider for a second the sort-of parable of Chesterton's fence. As G.K. Chesterton wrote:
"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don’t see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'"
It's basically that whole Spolsky think about why you shouldn't rewrite code from scratch[1]:
"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."
Broadly speaking: you, for ANY definition of you, are unable to design a perfect system at the first go. You will not account for all use cases, there will be edge cases you don't consider, so on and so forth. But it goes further than that: if you want to design something better than C++, you need to understand why so many people use C++. If you want to replace CSS, you need to understand why CSS is popular. If your thinking on the matter hasn't evolved much past "CSS is unnecessary" and blaming a single catchy essay for every decision you disagree with, then instead of writing essays about how everyone else is doing it wrong, maybe you should spend more time trying to understand what everyone is trying to do, why they're trying to do it and what resources they have to do it with. And THEN maybe I'll let you tear that fence down.
1) http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- empthought 12y ago"If you want to design something better than C++, you need to understand why so many people use C++." No, you don't. You just need to design something better than C++. "If you want to replace CSS, you need to understand why CSS is popular." No, you don't. You just need to replace CSS. Now, having people adopt better-than-C++ and better-than-CSS might take a little bit of the psychoanalysis (marketing?) you propose. But understanding why someone uses C++ is not really relevant at all in order to design a superior replacement. I assure you, the designers of Java did not really care why people used COBOL for so much banking code, and yet here we are, with Java having supplanted COBOL for much of that work. Every time someone trots out Chesterton's fence, I trump it with Sturgeon's law. Edit: heck, an even better example is JavaScript app frameworks. Do you think their designers understand why people programmed in Smalltalk or Swing or VB.NET or Delphi? No. Judging from their approach and idiom, obviously not. And yet here we are.
- cwyers 12y ago"Now, having people adopt better-than-C++ and better-than-CSS might take a little bit of the psychoanalysis (marketing?) you propose." I don't mean marketing, I mean actually designing something better. A lot of people don't actually know what better means. It's like the Betamax myth. A lot of people believe that Betamax was the technologically superior version, and it lost because of other reasons. This is bunk. Betamax's edge in picture quality over VHS, all else being equal, was slim to nonexistant. But Betamax was locked to a relatively fast tape speed to keep quality from degrading. VHS let people run at much slower tape speeds in order to fit more video on the same tape. Betamax allowed you record about an hour worth of video programming on a standard tape. VHS originally allowed two, and then they just said the heck with it and let you record four hours of bad-looking video. It turns out, though, that it's far more important to most people to have the ENTIRETY of a movie or (in the case of a four-hour tape, an NFL game) than it was to have the part of it you recorded look pristine. The lesson everyone draws from Betamax is that we can't have nice things and technological superiority is trumped by other considerations. The lesson everyone SHOULD draw from Betamax is that to win, you have to be better at the right things to actually be better.