You might be personally offended by XP's insistence you do actual tests of your code, and then fix the code when it breaks, but this requirement hardly qualifies XP as "fragile".
Sigh. More rudeness and condescension for its own sake. If you had looked at any of the other posts I linked to, or at my published writings elsewhere (clue: I wrote this) you would know that I am in fact a very strong advocate of testing at all levels, including but not limited to unit testing. I will not allow you to misrepresent my argument as being in any way opposed to unit testing. Someone said "you weren't doing XP" and I said "we don't know that" without any reference at any point to which part of XP was omitted. I wasn't referring at all to unit testing when I spoke of XP's fragility or inapplicability. I was thinking more of XP's admitted limitations as linked from one of my previous posts.
The XP books, incidentally, do not claim that you have to do all of XP for it to be useful
Indeed they do not, but several people here seem to be using just that argument as an excuse for a failure when XP was applied.
Let me know when you come up with a better methodology than XP.
Take your strawman and shove it. I don't need to come up with a better methodology. It's not necessary for anybody to come up with a better methodology before we can consider XP's limitations or slashdotters' attempts to ram it down people's throats, but in fact quite a few smart people have managed it (if we define better as "more robust and/or applicable") over the last few decades of software engineering study. Yes, Virginia, there was software engineering before XP. Most elements of XP predate XP itself by decades. Good programming methodologies vary quite a bit, but one thing they have in common is that their authors admit there's no magic bullet. If only people here would believe them.
As I pointed out in a previous post, which you should have read before responding, XP is great but it's no panacea. Great things can still be overhyped, and right now - for all its good points - XP is being overhyped. What I seek to do is not debunk XP entirely, but just to bring the expectations down to a realistic level.
Yes, that is probably true. However, I still worry about the fragility of a methodology that fails to provide benefits - or that actually makes things worse - if it's not followed precisely in every exacting detail (in short, religiously) by highly skilled people. When people are saying that A sucks, and A+B sucks too, and A+B+C sucks, but A+B+C+D will somehow turn out to be really cool, I think it's normal to be just a little bit skeptical. It's like continuing to buy a declining stock because "it has to rebound soon". Most often it's an exercise in denial, not synergy or honest evaluation of results. Maybe this is a false alarm, but don't expect me to adjust the sensitivity on my BS detector because it has served me well at its current setting.
It sounds like they weren't really doing extreme programming then.
What a convenient and obnoxious rationalization. This idea that if you're not doing all of XP you can expect failure is offensive enough. Besides the Inquisitorial insistence on total adherence to every minor tenet of The One True Faith, if a methodology is so fragile that the tiniest deviation leads to failure then that methodology is worthless in the real world.
What's worse than that, though, is the way that, without knowing anything about what this fellow's GF's company did, you reason backward from the fact that they failed to the conclusion that they must not have been doing XP "properly". That's just nauseating.
FYI, we just had a fairly detailed discussion of XP here last week, in the Making Software Suck Less thread. Of particular interest might be my XP is no panacea post, which contains a lot that would be directly on-topic in this thread (but I prefer linking to copying).
I've seen more bugs introduced by gratuitous rewriting than by any other single cause. You see, there's a lot of code out there that really does mostly work, even if it's poorly designed, except for a couple of bugs. You can fix those couple of bugs - patching a bad design - or you can replace it with a new version which fixes those two bugs but introduces twenty new ones. I've seen it time and time again.
In fact, "rewrite fever" mostly seems to afflict programmers whose egos far exceed their skills. They assume that if code is hard to understand it's because the previous author was an idiot, not because they themselves lack knowledge. They also believe that they can replace in half a day what took someone else weeks to write and debug. What usually happens is that they only realize after they've done the rewrite that the old code solved or avoided some problems they hadn't even been aware of, so they start patching the new version. The net result is new code that's every bit as messy as the old, and nowhere near as well tested.
Better programmers prefer surgery to amputation. It takes far more skill to develop the thorough and subtle understanding of code required to fix it in place, but when possible it's preferable. Rewrites should not be attempted without knowing exactly what the new code needs to do (ideally expressed in the form of thorough regression tests), and that usually requires careful study of the old code. You just can't get around that need to understand the original, and anyone too lazy or too proud to try definitely shouldn't be allowed to write any new code.
Yes, there is a point where a particular piece of code collapses under the weight of all the patches and workarounds and needs to be replaced outright. Amputations are sometimes necessary, but only a skilled surgeon should be allowed to make that call. Patching a bad design is often the best - and certainly the most cost-effective - way to get better code than you started with.
I wonder if Linus and the core kernel developers could benefit from the help of a Project Manager.
I don't wonder. They would.
Linus is a technical genius, and there is no better way to waste everyone's time by tying down a technical genius with project-management tasks. Let Linus do what he's good at, and let someone with the proper skills do the things Linus doesn't do so well. Of course, that person would have to have Linus's full and explicit support to be effective, and Linus would have to resist the temptation to override decisions appropriate to the project-management role, and I'm not sure he's the sort of person who would abide by those terms.
He chose not to have a Linux related job because of this.
His job at Transmeta could hardly be described as "not Linux related". Transmeta gives Linus an incredible amount of leeway to conduct his Linux business, including frequent travel, on corporate time and expense. I very much doubt that Transmeta cares one bit if Linux ever writes one line of code for them, and I wonder how much he really has done for them that's not Linux-related.
I don't even think he thinks of himself as the "leader" of the linux kernel.
Do you read the man's own posts, or just stuff that's written about him? His own words make it very clear that he has a strong sense of territory wrt Linux.
Is Linus killing Linux? Yes. Is this because he's not devoted to Linux full-time or because he's overloaded or for the other sorts of reasons the article covers? No. He's killing Linux because part of a leader's job is to set a good example for others and Linus sets a very bad example. Linus has some very weird ideas about things like debuggers, real-time, enterprise systems, and so forth. He doesn't seem to be a strong believer in things like specs and regression tests and controlled releases. He's not very well read about OS theory and his distrust of ideas from the commercial world borders on paranoia, so a lot of inferior reinvented-wheel proposals get his approval.
Because of the extremely high regard in which many hold Linus, and perhaps rightly so, all of his habits both good and bad tend to be emulated by other developers around the world. When that leads to the widespread adoption of his bad habits, that's bad for Linux. I seriously think that Linux would be healthier if opinions contrary to Linus's own could be expressed freely without hordes of his worshippers acting like the Inquisition.
Linus could ameliorate this problem by recognizing the impact of everything he says and trying to ensure that the impact is a good one. He should be open about the limits of his own expertise, and not make such a habit of shouting down experts in areas where he himself is ill informed. He could actively discourage people from supporting technical viewpoints out of blind loyalty, and from treating dissenters as heretics. His failure to do these things, which are all part of a leader's role and responsibility, is what is killing Linux.
I have several essays providing fuller explanations of these views on my website, for those who are interested.
Past experience and observation would indicate that Open Source projects of high general interest, in the condition of massive disagreement between factions will result in project forking.
You bring up a truly excellent point, but I don't think I totally agree. Two objections immediately come to mind:
There's such a cult of personality around Linus personally that an unblessed fork might have a difficult time getting the sort of recognition and user base needed to survive.
In this case there's also the FreeBSD option providing a "release valve" for the pressure to fork. People who get tired of being pushed around by the Linux cabal often find a new home in FreeBSD, and that allows them to pursue their technical (and possibly other) goals, but that doesn't help to improve Linux...or maybe it does, eventually, considering how much technology Linux is importing from FreeBSD nowadays. I sometimes wonder how we let FreeBSD become the advanced-development OS breaking trail for Linux to follow.
In short, I don't buy the argument that if there were anything wrong Linux would inevitably have forked already, and therefore that the absence of a fork proves the absence of a problem. There are just too many other factors and options that might explain why Linux hasn't forked yet.
BTW, if you follow this link you'll find the head of a discussion tree from just a couple of months ago on this very topic.
That's pretty aggressive for someone who failed to respond in a rational way to any of my questions.
I think most people who read it would say my response was quite rational...even if they disagree with it, or find my tone offensive. That contrasts quite sharply with cid #489, which makes absolutely no attempt whatsoever to support or rebut any relevant claims. I'd love to continue this discussion, but only if you give me something deserving of a response instead of mere meta-argument.
In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.
...but still an evil. As I said, in this particular case the author may have had good reasons for replacing standard routines. In the grand scheme of things that might not make his code bad, but it can't really be listed among the things that make it good. The code's minimalism and modularity, which you also mention, are much more encouraging.
I'm actually having trouble believing that you're serious. Can anyone's view of programming really be so impossibly narrow that they can't see the obvious deficiencies in that code, and actually try to argue on its behalf? Wow. That is just totally sad.
There are 6 places where it catches and reports errors via the "or die" construct. Did you miss that?
No, I damn well didn't miss it; it doesn't matter. Two objections:
"Or die" doesn't really count as error checking. Would you like to hit an "or die" every time you mistype a response at a CLI? Every time a network server got a response it didn't understand? Every time an OS failed to recognize a piece of hardware?
There are more than six ways this code can fail, so six checks are not sufficient. For example, it's immediately obvious that it doesn't check for or respond appropriately to errors from accept or fork. Maybe sometimes those errors will be caught in the next "or die"; often they won't, and all you'll have is an uncontrolled program termination.
I repeat my original statement: the code does not totally lack error checking, but it does lack error checking (relative to what should be present in good code).
it is pretty easy to argue that it is more "extensible" than most web servers because you have to know only two things to extend it:
Perl.
34 lines of Perl.
It is easy to argue that, but wrong - on several levels. You left out IO::Socket, a little bit of UNIX, and a little bit of HTTP, but it doesn't matter. Your argument is a little bit like saying you need to know only one thing to become a doctor, that one thing being medicine. It's absurd.
Even that doesn't matter, though. When it comes to extensibility, anything that requires that you modify existing code is still a level below anything that can be extended without such modification. This code is only extensible according to a definition so lax as to allow any code to be considered extensible.
What part of "the job" did it miss?
All of the parts that distinguish software engineering from mere screwing around. I'm not talking about functionality, I'm talking about the things that make some code that performs a function better than other code that performs the same function. This code may indeed fulfill its requirements (chiefly brevity) and do so admirably, and I do think it's pretty cool. However, as an example of "beautiful code" - the topic of this article - it totally and utterly fails. I wouldn't be surprised if even its author agrees. It's not beautiful, it's not supposed to be beautiful, that's not its purpose, and however cool it may be it has no place in a discussion of beautiful code.
This guy basically didn't trust the standard C library routines for security
In this particular case the author might have had good reasons, but in general reinventing the wheel is not a mark of good code. I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.
That's actually an example of very bad code. Besides its obvious aesthetic shortcomings, it lacks error checking, it embeds hidden and unnoted dependencies, it's not extensible, etc. Brevity is a characteristic of much great code, but brevity achieved by doing only half the job doesn't count.
I've been a team co-leader and had to deal with those programmers who don't have CS degrees. There are a few, a very few, who figure out that they don't know anything and who take steps to remedy it, but most are legends in their own mind.
The above would have been just as true without the phrase "who don't have CS degrees"; it's a common trait among programmers, degreed or not. I've seen the kinds of behavior you describe from many people with degrees, many times. In fact, I'd say that in my experience the people with degrees - particularly advanced degrees from "good schools" - are the most likely to have the attitude that they already know everything and don't need to learn anything else ever again.
Another advantage to programmers without degrees: they're never snobbish prigs about their or other people's academic backgrounds.
The fact is you CAN'T judge everyone on a case-by-case basis. There's no time. You need to filter when hiring.
I've had to wade through some pretty deep stacks of resumes in my time, and I've never had to resort to filtering criteria as superficial as what you suggest. There is always enough time to look beyond the name of the school (if any); every candidate puts something on their resume besides a school name, that they think will help convince you to hire them. If you don't look beyond the alma mater you are shortchanging both the candidate and your employer, and failing in your professional responsibility.
OK. With all due respect to its creators and proponents, I think this XP meme has just gotten out of hand. Even some of XP's most ardent supporters admit, in moments of much-appreciated honesty, that its value depends on a certain set of assumptions about project type, size and environment. Check out this article for an example.
XP uses iteration as a central theme. Iteration is great. I've hardly ever seen a program that wasn't significantly better on the second try than the first. Many older methodologies are based more on decomposition as a central theme...and you know what? Decomposition is great too! Divide and conquer, oh yeah. These are both incredibly useful tools which should be considered to complement rather than compete with one another. Any experienced programmer knows to use both, instead of being seduced by the abstract simplicity of methodologies based on only one.
I see it as an issue of "step size". XP and other iteration-oriented methodologies work best in systems where functionality can be added in small increments without requiring deep structural changes every time. A very large class of programming tasks, including GUIs, meets this requirement. XP tends to fall down, though, in cases where a huge number of things all have to work in concert to get any positive results at all. OS kernels come to mind. Decomposition should be the first tool you reach for in those cases. Maybe you can apply XP or other iteration techniques once you've broken things down, but there's no way around the fact that you have to break them down first.
Another difference is that XP is experiential and interactive, while other methodologies attempt to be more predictive. We all know the problem of trying to predict the unpredictable. However, prediction is not entirely without value. A thorough familiarity with the problem domain, combined with some elementary application of statistical principles, can yield predictions that are startlingly accurate for most projects. Those predictions can be used to achieve near-optimal resource allocations throughout the life of the project, instead of keeping "excess capacity" available for the project's peaks and troughs. Much of standard methodology is about making such predictions as accurate as possible. Nobody expects them to be perfect, but the better they are the saner life will be - not only for managers and customers but also for developers who won't have to put up with absurd expectations during an extended "crunch time" at the end of the project when everything they punted on comes back to haunt them.
I guess what I'm saying is that XP is half a solution. It's great, get the word out by all means, but adopting XP will not solve all "software sucks" problems and in some cases it will make things worse. If you know anything about horizon effects and hill-climbing problems from AI, you should know the dangers of incrementalism, and XP is an incremental approach.
One issue that this article doesn't bring up, and that many software engineering books ignore, is that sometimes all of the processes in the world won't help your software be more stable because of reliance on other software.
Excellent point! Many of us spend most of our professional lives working on software to extend an existing system in directions that its designers never intended it to be extended. Most kernel software fits into this category, for example, and we all know that's the only kind of software Real Men worry about, right?;-) In any case, it often feels like we're in hostile territory, and there really are few guidelines as to how it can be done safely and cleanly. Too many of the well-known methodologies assume total control over one's environment, making them relatively useless for many environments.
[As long as non-coders are involved in coding...] software will continue to suck.
Non-coders can not and do not, by definition, get involved in coding. If what you mean is that non-coders should not influence coding, I'd have do disagree. If anything, many of our problems are caused by non-coders not being involved enough in the development processes. QA should be involved in the requirements phase to ensure that something's testable, support should be involved to ensure that it's supportable, and users should be involved to ensure that it's usable. Often this involvement would be beneficial in the design phase as well. Obviously it's wrong to let these people determine how the actual code gets written, so long as it meets requirements, but non-coders do have useful expertise that we can and should use to make products better.
Seems to me that it'd be pretty cool to write to the native Crusoe architecture
Yes, it would be cool. It would also be impractical. The native Crusoe ISA is strikingly similar to "horizontal" microcode[1] from a long-ago era. Even I came on the scene too late to hack that kind of microcode, but I was close enough to know that it had a couple of interesting characteristics:
It was very unsafe. Horizontal microcode was characterized by a very high level of parallelism even within one instruction ("molecule" for Crusoe), with little interlocking or safety checks. Programmers were expected to know which micro-op was compatible with what. Forget, and you could lock up or permanently damage the processor.
Getting anything to work at all was hard. Trying to optimize was mind-bendingly hard.
The micro-ISA kept changing every time a new chip implementing the same macro-ISA came out, meaning that you'd have to go through all that incredible pain all over again.
Having said all that, I still think it would be cool.
[1] For those unfamiliar with such ancient terminology, there were two trends in microcode. "Horizontal" microcode was characterized by fewer, longer lines on a program listing compared to "vertical" microcode. RISC and VLIW assembler are strongly reminiscent of vertical and horizontal microcode respectively. Of course, microcode didn't quite have the same "view" of things like registers or exceptions, and all of that OOI/OOC/renaming kinda stuff just didn't apply at all, but the similarities are still there.
I'm with rho on this one...sort of. Employers and creditors have a right to know about this kind of stuff. I don't think privacy extends to the covering up of criminal acts. As for how much weight they give it, well, that's a different issue. Personally, I'd probably be pretty forgiving of many "youthful indiscretions", and I wouldn't want to be dealing with anyone who wasn't at least willing to hear an explanation of the circumstances. But that's just me. Others may view things differently, and I don't think we solve anything by allowing people to hide arbitrary amounts of past misbehavior behind dubious claims of privacy. Let people have the information, but hold them accountable for how they use it. What seems to be missing in the current picture is accountability.
Joe White Boy in freshman engineering is definitelymore likely to be priviliged.
"More likely" doesn't mean squat in an individual case. Joe White Boy who's from a poor family might not give a damn about how anomalous or improbable he seems to you. What you have expressed is simply a stereotype, not morally different from any other stereotype. Judge Joe White Boy on what Joe White Boy does, and don't assume anything because he's white.
Other filesystems (VMS did this ?) had versioning right in the file-system. I think its a good idea. FS support for solutions to things like DLL hell ? Count me in!
I believe Whistler does something like this, without FS versioning. As someone who has worked on several filesystems, including distributed and cluster filesystems, I can say in all candor that filesystems do enough of other people's work for them already. I think versioning is a wonderful feature to have, but it can be done perfectly well outside the filesystem.
Whoa there. Have you tried to work through this before ?
I can't speak for the person to whom you were responding, but I have.
distributed algorithms are not trivial
Not trivial, but also not impossible. Designing chips and writing OS kernels are not trivial either, but people do those and even expect to make a profit from it. OceanStore is a research project. They're supposed to break new ground, and if anyone is qualified to make the attempt it's those guys.
Slashdot Mirror
Sigh. More rudeness and condescension for its own sake. If you had looked at any of the other posts I linked to, or at my published writings elsewhere (clue: I wrote this) you would know that I am in fact a very strong advocate of testing at all levels, including but not limited to unit testing. I will not allow you to misrepresent my argument as being in any way opposed to unit testing. Someone said "you weren't doing XP" and I said "we don't know that" without any reference at any point to which part of XP was omitted. I wasn't referring at all to unit testing when I spoke of XP's fragility or inapplicability. I was thinking more of XP's admitted limitations as linked from one of my previous posts.
Indeed they do not, but several people here seem to be using just that argument as an excuse for a failure when XP was applied.
Take your strawman and shove it. I don't need to come up with a better methodology. It's not necessary for anybody to come up with a better methodology before we can consider XP's limitations or slashdotters' attempts to ram it down people's throats, but in fact quite a few smart people have managed it (if we define better as "more robust and/or applicable") over the last few decades of software engineering study. Yes, Virginia, there was software engineering before XP. Most elements of XP predate XP itself by decades. Good programming methodologies vary quite a bit, but one thing they have in common is that their authors admit there's no magic bullet. If only people here would believe them.
As I pointed out in a previous post, which you should have read before responding, XP is great but it's no panacea. Great things can still be overhyped, and right now - for all its good points - XP is being overhyped. What I seek to do is not debunk XP entirely, but just to bring the expectations down to a realistic level.
Agreed. Thank you, rblum.
Yes, that is probably true. However, I still worry about the fragility of a methodology that fails to provide benefits - or that actually makes things worse - if it's not followed precisely in every exacting detail (in short, religiously) by highly skilled people. When people are saying that A sucks, and A+B sucks too, and A+B+C sucks, but A+B+C+D will somehow turn out to be really cool, I think it's normal to be just a little bit skeptical. It's like continuing to buy a declining stock because "it has to rebound soon". Most often it's an exercise in denial, not synergy or honest evaluation of results. Maybe this is a false alarm, but don't expect me to adjust the sensitivity on my BS detector because it has served me well at its current setting.
This isn't about my GF. I try not to talk about my GF in public because it really annoys my wife. ;-)
What a convenient and obnoxious rationalization. This idea that if you're not doing all of XP you can expect failure is offensive enough. Besides the Inquisitorial insistence on total adherence to every minor tenet of The One True Faith, if a methodology is so fragile that the tiniest deviation leads to failure then that methodology is worthless in the real world.
What's worse than that, though, is the way that, without knowing anything about what this fellow's GF's company did, you reason backward from the fact that they failed to the conclusion that they must not have been doing XP "properly". That's just nauseating.
FYI, we just had a fairly detailed discussion of XP here last week, in the Making Software Suck Less thread. Of particular interest might be my XP is no panacea post, which contains a lot that would be directly on-topic in this thread (but I prefer linking to copying).
I've seen more bugs introduced by gratuitous rewriting than by any other single cause. You see, there's a lot of code out there that really does mostly work, even if it's poorly designed, except for a couple of bugs. You can fix those couple of bugs - patching a bad design - or you can replace it with a new version which fixes those two bugs but introduces twenty new ones. I've seen it time and time again.
In fact, "rewrite fever" mostly seems to afflict programmers whose egos far exceed their skills. They assume that if code is hard to understand it's because the previous author was an idiot, not because they themselves lack knowledge. They also believe that they can replace in half a day what took someone else weeks to write and debug. What usually happens is that they only realize after they've done the rewrite that the old code solved or avoided some problems they hadn't even been aware of, so they start patching the new version. The net result is new code that's every bit as messy as the old, and nowhere near as well tested.
Better programmers prefer surgery to amputation. It takes far more skill to develop the thorough and subtle understanding of code required to fix it in place, but when possible it's preferable. Rewrites should not be attempted without knowing exactly what the new code needs to do (ideally expressed in the form of thorough regression tests), and that usually requires careful study of the old code. You just can't get around that need to understand the original, and anyone too lazy or too proud to try definitely shouldn't be allowed to write any new code.
Yes, there is a point where a particular piece of code collapses under the weight of all the patches and workarounds and needs to be replaced outright. Amputations are sometimes necessary, but only a skilled surgeon should be allowed to make that call. Patching a bad design is often the best - and certainly the most cost-effective - way to get better code than you started with.
I don't wonder. They would.
Linus is a technical genius, and there is no better way to waste everyone's time by tying down a technical genius with project-management tasks. Let Linus do what he's good at, and let someone with the proper skills do the things Linus doesn't do so well. Of course, that person would have to have Linus's full and explicit support to be effective, and Linus would have to resist the temptation to override decisions appropriate to the project-management role, and I'm not sure he's the sort of person who would abide by those terms.
His job at Transmeta could hardly be described as "not Linux related". Transmeta gives Linus an incredible amount of leeway to conduct his Linux business, including frequent travel, on corporate time and expense. I very much doubt that Transmeta cares one bit if Linux ever writes one line of code for them, and I wonder how much he really has done for them that's not Linux-related.
Do you read the man's own posts, or just stuff that's written about him? His own words make it very clear that he has a strong sense of territory wrt Linux.
Is Linus killing Linux? Yes. Is this because he's not devoted to Linux full-time or because he's overloaded or for the other sorts of reasons the article covers? No. He's killing Linux because part of a leader's job is to set a good example for others and Linus sets a very bad example. Linus has some very weird ideas about things like debuggers, real-time, enterprise systems, and so forth. He doesn't seem to be a strong believer in things like specs and regression tests and controlled releases. He's not very well read about OS theory and his distrust of ideas from the commercial world borders on paranoia, so a lot of inferior reinvented-wheel proposals get his approval.
Because of the extremely high regard in which many hold Linus, and perhaps rightly so, all of his habits both good and bad tend to be emulated by other developers around the world. When that leads to the widespread adoption of his bad habits, that's bad for Linux. I seriously think that Linux would be healthier if opinions contrary to Linus's own could be expressed freely without hordes of his worshippers acting like the Inquisition.
Linus could ameliorate this problem by recognizing the impact of everything he says and trying to ensure that the impact is a good one. He should be open about the limits of his own expertise, and not make such a habit of shouting down experts in areas where he himself is ill informed. He could actively discourage people from supporting technical viewpoints out of blind loyalty, and from treating dissenters as heretics. His failure to do these things, which are all part of a leader's role and responsibility, is what is killing Linux.
I have several essays providing fuller explanations of these views on my website, for those who are interested.
You bring up a truly excellent point, but I don't think I totally agree. Two objections immediately come to mind:
In short, I don't buy the argument that if there were anything wrong Linux would inevitably have forked already, and therefore that the absence of a fork proves the absence of a problem. There are just too many other factors and options that might explain why Linux hasn't forked yet.
BTW, if you follow this link you'll find the head of a discussion tree from just a couple of months ago on this very topic.
I think most people who read it would say my response was quite rational...even if they disagree with it, or find my tone offensive. That contrasts quite sharply with cid #489, which makes absolutely no attempt whatsoever to support or rebut any relevant claims. I'd love to continue this discussion, but only if you give me something deserving of a response instead of mere meta-argument.
...but still an evil. As I said, in this particular case the author may have had good reasons for replacing standard routines. In the grand scheme of things that might not make his code bad, but it can't really be listed among the things that make it good. The code's minimalism and modularity, which you also mention, are much more encouraging.
I'm actually having trouble believing that you're serious. Can anyone's view of programming really be so impossibly narrow that they can't see the obvious deficiencies in that code, and actually try to argue on its behalf? Wow. That is just totally sad.
No, I damn well didn't miss it; it doesn't matter. Two objections:
I repeat my original statement: the code does not totally lack error checking, but it does lack error checking (relative to what should be present in good code).
It is easy to argue that, but wrong - on several levels. You left out IO::Socket, a little bit of UNIX, and a little bit of HTTP, but it doesn't matter. Your argument is a little bit like saying you need to know only one thing to become a doctor, that one thing being medicine. It's absurd.
Even that doesn't matter, though. When it comes to extensibility, anything that requires that you modify existing code is still a level below anything that can be extended without such modification. This code is only extensible according to a definition so lax as to allow any code to be considered extensible.
All of the parts that distinguish software engineering from mere screwing around. I'm not talking about functionality, I'm talking about the things that make some code that performs a function better than other code that performs the same function. This code may indeed fulfill its requirements (chiefly brevity) and do so admirably, and I do think it's pretty cool. However, as an example of "beautiful code" - the topic of this article - it totally and utterly fails. I wouldn't be surprised if even its author agrees. It's not beautiful, it's not supposed to be beautiful, that's not its purpose, and however cool it may be it has no place in a discussion of beautiful code.
In this particular case the author might have had good reasons, but in general reinventing the wheel is not a mark of good code. I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.
That's actually an example of very bad code. Besides its obvious aesthetic shortcomings, it lacks error checking, it embeds hidden and unnoted dependencies, it's not extensible, etc. Brevity is a characteristic of much great code, but brevity achieved by doing only half the job doesn't count.
The above would have been just as true without the phrase "who don't have CS degrees"; it's a common trait among programmers, degreed or not. I've seen the kinds of behavior you describe from many people with degrees, many times. In fact, I'd say that in my experience the people with degrees - particularly advanced degrees from "good schools" - are the most likely to have the attitude that they already know everything and don't need to learn anything else ever again.
Another advantage to programmers without degrees: they're never snobbish prigs about their or other people's academic backgrounds.
I've had to wade through some pretty deep stacks of resumes in my time, and I've never had to resort to filtering criteria as superficial as what you suggest. There is always enough time to look beyond the name of the school (if any); every candidate puts something on their resume besides a school name, that they think will help convince you to hire them. If you don't look beyond the alma mater you are shortchanging both the candidate and your employer, and failing in your professional responsibility.
OK. With all due respect to its creators and proponents, I think this XP meme has just gotten out of hand. Even some of XP's most ardent supporters admit, in moments of much-appreciated honesty, that its value depends on a certain set of assumptions about project type, size and environment. Check out this article for an example.
XP uses iteration as a central theme. Iteration is great. I've hardly ever seen a program that wasn't significantly better on the second try than the first. Many older methodologies are based more on decomposition as a central theme...and you know what? Decomposition is great too! Divide and conquer, oh yeah. These are both incredibly useful tools which should be considered to complement rather than compete with one another. Any experienced programmer knows to use both, instead of being seduced by the abstract simplicity of methodologies based on only one.
I see it as an issue of "step size". XP and other iteration-oriented methodologies work best in systems where functionality can be added in small increments without requiring deep structural changes every time. A very large class of programming tasks, including GUIs, meets this requirement. XP tends to fall down, though, in cases where a huge number of things all have to work in concert to get any positive results at all. OS kernels come to mind. Decomposition should be the first tool you reach for in those cases. Maybe you can apply XP or other iteration techniques once you've broken things down, but there's no way around the fact that you have to break them down first.
Another difference is that XP is experiential and interactive, while other methodologies attempt to be more predictive. We all know the problem of trying to predict the unpredictable. However, prediction is not entirely without value. A thorough familiarity with the problem domain, combined with some elementary application of statistical principles, can yield predictions that are startlingly accurate for most projects. Those predictions can be used to achieve near-optimal resource allocations throughout the life of the project, instead of keeping "excess capacity" available for the project's peaks and troughs. Much of standard methodology is about making such predictions as accurate as possible. Nobody expects them to be perfect, but the better they are the saner life will be - not only for managers and customers but also for developers who won't have to put up with absurd expectations during an extended "crunch time" at the end of the project when everything they punted on comes back to haunt them.
I guess what I'm saying is that XP is half a solution. It's great, get the word out by all means, but adopting XP will not solve all "software sucks" problems and in some cases it will make things worse. If you know anything about horizon effects and hill-climbing problems from AI, you should know the dangers of incrementalism, and XP is an incremental approach.
Excellent point! Many of us spend most of our professional lives working on software to extend an existing system in directions that its designers never intended it to be extended. Most kernel software fits into this category, for example, and we all know that's the only kind of software Real Men worry about, right? ;-) In any case, it often feels like we're in hostile territory, and there really are few guidelines as to how it can be done safely and cleanly. Too many of the well-known methodologies assume total control over one's environment, making them relatively useless for many environments.
Non-coders can not and do not, by definition, get involved in coding. If what you mean is that non-coders should not influence coding, I'd have do disagree. If anything, many of our problems are caused by non-coders not being involved enough in the development processes. QA should be involved in the requirements phase to ensure that something's testable, support should be involved to ensure that it's supportable, and users should be involved to ensure that it's usable. Often this involvement would be beneficial in the design phase as well. Obviously it's wrong to let these people determine how the actual code gets written, so long as it meets requirements, but non-coders do have useful expertise that we can and should use to make products better.
Yes, it would be cool. It would also be impractical. The native Crusoe ISA is strikingly similar to "horizontal" microcode[1] from a long-ago era. Even I came on the scene too late to hack that kind of microcode, but I was close enough to know that it had a couple of interesting characteristics:
Having said all that, I still think it would be cool.
[1] For those unfamiliar with such ancient terminology, there were two trends in microcode. "Horizontal" microcode was characterized by fewer, longer lines on a program listing compared to "vertical" microcode. RISC and VLIW assembler are strongly reminiscent of vertical and horizontal microcode respectively. Of course, microcode didn't quite have the same "view" of things like registers or exceptions, and all of that OOI/OOC/renaming kinda stuff just didn't apply at all, but the similarities are still there.
I'm with rho on this one...sort of. Employers and creditors have a right to know about this kind of stuff. I don't think privacy extends to the covering up of criminal acts. As for how much weight they give it, well, that's a different issue. Personally, I'd probably be pretty forgiving of many "youthful indiscretions", and I wouldn't want to be dealing with anyone who wasn't at least willing to hear an explanation of the circumstances. But that's just me. Others may view things differently, and I don't think we solve anything by allowing people to hide arbitrary amounts of past misbehavior behind dubious claims of privacy. Let people have the information, but hold them accountable for how they use it. What seems to be missing in the current picture is accountability.
"More likely" doesn't mean squat in an individual case. Joe White Boy who's from a poor family might not give a damn about how anomalous or improbable he seems to you. What you have expressed is simply a stereotype, not morally different from any other stereotype. Judge Joe White Boy on what Joe White Boy does, and don't assume anything because he's white.
I believe Whistler does something like this, without FS versioning. As someone who has worked on several filesystems, including distributed and cluster filesystems, I can say in all candor that filesystems do enough of other people's work for them already. I think versioning is a wonderful feature to have, but it can be done perfectly well outside the filesystem.
I can't speak for the person to whom you were responding, but I have.
Not trivial, but also not impossible. Designing chips and writing OS kernels are not trivial either, but people do those and even expect to make a profit from it. OceanStore is a research project. They're supposed to break new ground, and if anyone is qualified to make the attempt it's those guys.