DRY is indeed not specific to OO. Design by responsibility and collaboration, on the other hand, tends to be.
Many-to-many relationships between classes (verb-to-noun) are often handled the same way you handle many-to-may relationships in a relational database; with an intermediate entity (class) that serves as a go between.
Good point about Prevayler and navigational / network DBs, but as for sharing data, or preferably services, with other applications, messaging protocols can accomplish this.
It might not have been on that page but I thought they discuss problems in changing or repurposing code bases built with a transaction script style (or perhaps I read it somewhere else). I've actually seen such problems in practice (with both procedural and OO implementations), and it's usually the result of bad initial design. So we're back to people again.
You're correct, of course. The principles should be simple. They should be fairly compact, and like all principles, they should come from the well of experience. The principles for good OO design are fairly simple:
Don't Repeat Yourself: knowledge should be represented only once in the system.
Tell, don't ask.
Classify objects in your systems by the messages they respond to, and the responsibilities they hold.
An object should only call features of: a: an object passed into it as an argument, b: an object it creates, or c: itself (I think this is the correct form of the "Law of Demeter")
Prefer short methods.
Apply design patterns according to the problems they are intended to solve.
When using design patterns, find the pattern that sets the context, this will help you identify other companion patterns that typically apply to the problem (or related problems).
Design your code to be tested, or better, write test code to help flush out the design.
Keep a nostril open for code smells, use refactorings and tests to fix the problem.
...
Always remember these are principles and not rules.
Now explaining those principles with code and narrative will fill up 700 pages if you give the whole history of how they came to be. Or you can just visit the pragmatic programmers' web site and read a bit less than 700 pages.
I also agree that the typical notion of encapsulation doesn't necessarily protect the data. When most people think of encapsulating they think of putting a barrier of functions between a data consumer and the provider (I was revolted when I first saw this in Java, I think C# and Delphi do this better with the first class notion of property). But the other meaning for encapsulation is "to embody" the data. I think that ends up being a more powerful concept when properly applied than publishing getters and setters for attirbutes that might as well be public. The idea that some other object must consume (get) the data is the first warning sign that the design is deviating from the OO way of thinking (OK, OK, paradigm, there I typed it again). When an object embodies the data, encapsulation can, in fact, protect it. But I was actually thinking that polymorphism provides a better way to ensure consistent handling of data in an OO system.
Ironically, MDA is closer to your concept of TOP than OOP is, as MDA is metadata-intensive and oriented to the creation of purpose-built syntaxes (modeling languages), although it is not specific to relational database access.
You might find this flabergasting, but I'm tempted to believe that relational databases aren't all that necessary any more. Most modern relational database hold nearly all of their data in memory. That's the only way they can achieve the performance they do. Take Oracle databases for example. In my shop the Oracle instances we run typically hold 98% of their data in memory (we have big Solaris boxen). So why not use some sort of memory snapshot system like Prevayler? The answer, of course, is that too many developers find this scary. The other argument against this is 'reporting tools.'
No, I'm not suggesting we all throw out our relational databases. But I do think there is life beyond relational data.
Also, I didn't build an example of a bad procedural system for this post. I apologize. As you know, that takes a lot of effort. Instead, as a consolation, have a look here: http://www.nakedobjects.org/section6.html Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion. Task-oriented UI design typically goes hand-in-hand with transaction script architecture and falls prey to the same issues (I'll even add an 'IMHO' to that). I think you'll like their spaghetti diagram a bit of the way down the page.
I suspect you'd like C# then. It has C/Java-like syntax, a strong OO paradigm with escape hatches for direct memory manipluation (among other things). If you don't like Microsoft, that's OK too, as the Mono project has made some serious progress in producing an open source C# /.Net platform.
I've been wondering what you might think of n-tier EJB / EDOC style systems. Those styles of systems are actually procedural designs (sad but true). They are task and table oriented, they just happen to be implemented in an OO language.
Well-designed OO code does not degenerate into spaghetti, any more than well-designed procedural code does. So much depends on the quality of the people creating the code that we often forget that the tools they use are less relevant than the skills they leverage.
If there is a consistency to OO design, I have not seen it and/or OO fans don't agree on what it is.
You've written a whole site on "Procedural-Relational Patterns" as a response to the GoF Design Patterns, so you must know that your statement here just sounds like you're ranting. I'll concede that I haven't always seen design, analysis, or architectural patterns applied consistently, but that again comes down to people.
My take on OO? Well it depends on what view of the system you take. You can take an OO conceptual design and implement it in a procedural architecture with an OO language (the typical approach for EJB). You can go completely OO from the UI (NakedObjects)to the underlying language (Java) to the database (I prefer O/R mapping to OO databases myself). This often works quite well in keeping the code small and understandable. I have a background in Pascal but Java is currently my language of choice as I find I'm more productive with it. And no, I don't particularly like EJB.
You mentioned Extreme Programming, a practice which orients the developer to producing small, loosely-coupled, tightly-cohesive modules. And if the code isn't that way the first time you create it, it adds a set of practices that aid the developer it putting it into that condition.
This has little to do with "incremental hacking" but rather factors human cognitive progression (we gradually understand a problem and its solution) into the software creation process. You can apply agile processes to procedural or functional programming just as easily, although you'd be hard-pressed to find an "agile" book with C, Pascal, or COBOL examples in them.
You group code mostly by tasks or events, and a normalized relational database becomes the river that connects all the individual tasks/events.
So how many times must you encode the rules for "contributing" to the river consistently? Relational data constraints often cannot handle complex decisions based on individual values in a record or a set of related records. Business consistency must then be enforced with code in every task accessing the data. You must repeat code, or at best, explicitly call it without fail, to ensure 'the river' does not become polluted. In cases like this, OO languages provide more powerful tools to represent this knowledge and ensure its consistent application.
Of course, there's no guarantee that a given developer will design with these tools (have a look under the covers of your average large EJB application and you'll see what I mean).
Happy coding (or, seeing as how I work on Compuware's OptimalJ, happy generating (grin)). BTW: MDA != OO, although you can produce one with the other.
Well, OK, this particle is already named in the "Theory of Extra Special Relativity":
We start from the foundation of the dopeler effect: Stupid ideas that come at you rapidly seem smarter than they actually are.
Through our observations of individuals exposed to prolonged dopeler-shifted emanations, we can see that emission of dumb ideas tends to attract other dumb ideas, which in turn leads to a chain reaction of idiocy. All minds in the vicinity of high energy dolt fields are warped, consequently all conversations seem to take an infinitely long time.
Experimental evidence suggests that there is a limit to the density of weak grin bozon sources that any given region of space may sustain. Once this limit is passed, all thought in the region collapses in on itself to become a Quantum Imbecilic Singularity, from which no good idea may escape. QIS formations may be detected by searching for accretion disks of broken dreams, and massive jets of anticluons coming from a vector perpendicular to the back end of the accretion disk.
I'm kind of surprised that no one else has offered this speculation. I've been watching the news and hearing about China aiming for the moon.
Am I the only one who thinks that we might be headed for another space race? China might be the only nation with the economic potential to become a super power and nothing says super power better than putting people on the moon, or, say, Mars.
As was mentioned elsewhere, there are temporary job benefits, but the Bush administration has been known to think big before: Hydrogen economy... Global democracy...
I'm not claiming these efforts are "Right" or even fruitful, but they are big. Bush has made decisions to launch efforts that could only pay off long after he leaves office. And no, I'm not interested in debating Bush's intelligence.
Isn't the process of creation, rightly named, a performance? I wonder if that doesn't make pair programming performance art. Granted, at some point, common sense intrudes (not a troll) and the answer comes out "no," even when beauty is experienced in the process.
So what about an actor or actress portraying programming? Never mind...
Well said. I've often found well-written code (my own or that written by others) to be beautiful, but it cannot be called art. I've appreciated a spare user interface that leads the user to natural patterns of work, aiding the user through thoughtful metaphor and tasteful selection of color. But this was not art. As you say, it was the craft of someone artistic.
I've often thought that craftsmanship was an expression of loving care toward those who will use the thing being built; whether conscious or not. Art, from my perspective, is an expression of meaning, an act of exposing (or hiding) one's self to an audience. The intent is different.
I too have created art as well as crafted code. But not at the same time. I think game designers come the closest to doing that (Sid Meier comes to mind).
Agreed, coming up with good names for functions can be very hard. You've got to love design patterns, not only do they lead you to common structures, they lend their names also.
I have a fairly good idea what FooBarFactory.newFoo() is going to do.
Fall not in the trap of recursive disbelief
Where nothing seen is ever true,
For then you will have no relief,
And beauty will be forever beyond you.
Rather pursue balance in your life,
Accept that you are what you make yourself;
Realize that knowing comes from strife,
Not from books found on a library shelf
Always struggle to understand,
But take time to notice beauty;
Not all of life is planned,
And not all of life is duty.
-- Michael Murphree
(copyright 2004 (with apologies to the/. readership))
I don't know what it was, but I couldn't resist responding to this thread in this manner.
It is not so simple, of course. Many of those same third world countries that we (apologies, speaking as an American) do share with block or divert the aid away from the people who need it. It usually boils down to supporting a military that particular country can ill afford. Other times it's fear in the guise of beauracracy (genetically engineered crops come to mind).
The problem, is not that we don't share, the problem is rooted more significantly in greed on both sides. We overproduce (as a nation) and we (as individuals) selfishly take more than we need (see SUV comments above), and this completes the cycle. On the other side (the third world), a greed for power leaches productive capacity to support a military (or something similar in the form of warlords or terror clusters), because the neighbors are doing it also.
And no, government cannot legislate selflessness, that's only a form of totalitarianism. Positive selflessness can be taught, however. Parents can teach their children to think about the consequences of their consumption.
I think the real problem is actually one of scarcity. Scarcity of morality, scarcity of self-control, and scarcity of critical thinking. All of these skills may be taught.
I am a SCO employee (sips cool-aid)
I have seen the code (sniffs powdery substance)
We will own IBM (eyes widen)
Linux is a copy of System V (sweat breaks out on brow)
Space aliens will come to save our stock... (puts on white tennis shoes)
OK, OK, IANASCOE. You have to feel for the developer-types there, though. They must be reading this kind of stuff. They can't use UNIX and not read Slashdot, right?
JBoss allows you to configure the server piecemeal. So if you don't need a JMS implementation, don't configure it. If you don't need distributed transaction support don't configure it... etc. JBoss/Jetty with dead-basic support for web and EJB can be slimmed down fairly well. Granted, you probably will have to pay for the doc to figure out how to do it (~$15).
Your other recourse is to try out something like OpenEJB OpenEJB runs as a component deployed to Tomcat.
My mother can handle user accounts on her machine by clicking the big buttons in XP. She's been able to install applications on her own.
I can't imagine her being able figure out (on her own) that she must unmount a CD-ROM in order to eject it. Nor would she get along well with a command prompt. She understands double-clicking quite well.
For myself, well, I run Red Hat 7.3 with custom built kernel (RAID 0 tweaks). I use Linux for web and e-mail, for software development (mostly J2EE stuff). I use WindowsXP for commercial games. At work I use Windows 2000 because its a corporate standard and I'm stuck with it.
I'm comfortable with finding and using RPMs or building apps from source. I'm comfortable diving through documentation and understanding the Unix tools at my disposal, and I love the flexiblity and freedom that gives me. Were I into cars I'd be tinkering with carburetors and custom paint jobs.
Linux is still for developer-types, in my opinion, and I prefer it that way. Having an OS/OE oriented toward software development is important, and satisfies a different need than the one Windows satisfies for my mother. She wants an appliance for e-mail, web browsing, games, and word processing.
The point I'm making in such a long-winded way, is that if you judge the quality of the OS by what it allows you to accomplish, the "winner" in any contest depends on what the user wants to do.
The economics that allowed for a decline in welfare and a budget surplus were created under a conservative administration and eroded away by the previous liberal administration. The U.S. economy began it's down-turn well before G.W.Bush took office, not after. Bush inherited the economic mess the previous administration left behind.
More pointedly, the economic model of corporations trying to appear profitable as opposed to actually being profitable also hurt America's economy. When stock values went down, all the big corporations resorted to improving their "operations cost" by cutting payroll, hence cutting jobs. Executives did this regardless of how profitable the corporation was at the time.
This is not a problem caused by the current administration, or even the previous one. Nor was Enron, or WorldCom. This was a problem caused by greed (IMHO).
This same problem of greed, both on the part of the MPAA and their cousins in the cable companies, and the lobbyists and politicians, produces rushed laws that do more harm than good. When the laws of the land were first developed, they were considered thoughtfully. Great care was taken to represent the interests of the people. Legislators felt a heavy moral responsibility to make good decisions and good laws on behalf of the people who elected them
The moral impetus to represent public interest has been one or two steps removed from public office for quite a while. The driving force is to get reelected, and so, to make money. Corporate interests form a copious source of money, and hence legislation is passed without thought about the consequences for individuals, or even for the "economic good." Bad motive begets bad law.
Writing law can be like writing code: undesirable coupling yields side effects.
Since when have the free (as in beer) download versions of Linux (any GNU/Linux distribution) been "supportless?"
What do you call all of the documentation projects and forums and mailing lists available out there?
Those distributions may come without phone technical support, but most paid-for phone technical support in this industry has become a matter of brushing off users with real problems. You end up resorting to forums and e-mail to solve problems anyway. The other kind of OS support you might reasonably expect to pay for is on-site consultant support (like IBM), but you don't get that with Windows either.
Slashdot Mirror
DRY is indeed not specific to OO. Design by responsibility and collaboration, on the other hand, tends to be.
Many-to-many relationships between classes (verb-to-noun) are often handled the same way you handle many-to-may relationships in a relational database; with an intermediate entity (class) that serves as a go between.
Good point about Prevayler and navigational / network DBs, but as for sharing data, or preferably services, with other applications, messaging protocols can accomplish this.
It might not have been on that page but I thought they discuss problems in changing or repurposing code bases built with a transaction script style (or perhaps I read it somewhere else). I've actually seen such problems in practice (with both procedural and OO implementations), and it's usually the result of bad initial design. So we're back to people again.
Regards,
Michael
You're correct, of course. The principles should be simple. They should be fairly compact, and like all principles, they should come from the well of experience. The principles for good OO design are fairly simple:
Don't Repeat Yourself: knowledge should be represented only once in the system.
Tell, don't ask.
Classify objects in your systems by the messages they respond to, and the responsibilities they hold.
An object should only call features of: a: an object passed into it as an argument, b: an object it creates, or c: itself (I think this is the correct form of the "Law of Demeter")
Prefer short methods.
Apply design patterns according to the problems they are intended to solve.
When using design patterns, find the pattern that sets the context, this will help you identify other companion patterns that typically apply to the problem (or related problems).
Design your code to be tested, or better, write test code to help flush out the design.
Keep a nostril open for code smells, use refactorings and tests to fix the problem.
...
Always remember these are principles and not rules.
Now explaining those principles with code and narrative will fill up 700 pages if you give the whole history of how they came to be. Or you can just visit the pragmatic programmers' web site and read a bit less than 700 pages.
I also agree that the typical notion of encapsulation doesn't necessarily protect the data. When most people think of encapsulating they think of putting a barrier of functions between a data consumer and the provider (I was revolted when I first saw this in Java, I think C# and Delphi do this better with the first class notion of property). But the other meaning for encapsulation is "to embody" the data. I think that ends up being a more powerful concept when properly applied than publishing getters and setters for attirbutes that might as well be public. The idea that some other object must consume (get) the data is the first warning sign that the design is deviating from the OO way of thinking (OK, OK, paradigm, there I typed it again). When an object embodies the data, encapsulation can, in fact, protect it. But I was actually thinking that polymorphism provides a better way to ensure consistent handling of data in an OO system.
Ironically, MDA is closer to your concept of TOP than OOP is, as MDA is metadata-intensive and oriented to the creation of purpose-built syntaxes (modeling languages), although it is not specific to relational database access.
You might find this flabergasting, but I'm tempted to believe that relational databases aren't all that necessary any more. Most modern relational database hold nearly all of their data in memory. That's the only way they can achieve the performance they do. Take Oracle databases for example. In my shop the Oracle instances we run typically hold 98% of their data in memory (we have big Solaris boxen). So why not use some sort of memory snapshot system like Prevayler? The answer, of course, is that too many developers find this scary. The other argument against this is 'reporting tools.'
No, I'm not suggesting we all throw out our relational databases. But I do think there is life beyond relational data.
Also, I didn't build an example of a bad procedural system for this post. I apologize. As you know, that takes a lot of effort. Instead, as a consolation, have a look here: http://www.nakedobjects.org/section6.html Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion. Task-oriented UI design typically goes hand-in-hand with transaction script architecture and falls prey to the same issues (I'll even add an 'IMHO' to that). I think you'll like their spaghetti diagram a bit of the way down the page.
Thanks for the response, and the discussion.
Michael Murphree
Uhhh... Thanks for all the free advertising, azuroff.
(ducks)
I suspect you'd like C# then. It has C/Java-like syntax, a strong OO paradigm with escape hatches for direct memory manipluation (among other things). If you don't like Microsoft, that's OK too, as the Mono project has made some serious progress in producing an open source C# / .Net platform.
I've been wondering what you might think of n-tier EJB / EDOC style systems. Those styles of systems are actually procedural designs (sad but true). They are task and table oriented, they just happen to be implemented in an OO language.
Well-designed OO code does not degenerate into spaghetti, any more than well-designed procedural code does. So much depends on the quality of the people creating the code that we often forget that the tools they use are less relevant than the skills they leverage.
You've written a whole site on "Procedural-Relational Patterns" as a response to the GoF Design Patterns, so you must know that your statement here just sounds like you're ranting. I'll concede that I haven't always seen design, analysis, or architectural patterns applied consistently, but that again comes down to people.
My take on OO? Well it depends on what view of the system you take. You can take an OO conceptual design and implement it in a procedural architecture with an OO language (the typical approach for EJB). You can go completely OO from the UI (NakedObjects)to the underlying language (Java) to the database (I prefer O/R mapping to OO databases myself). This often works quite well in keeping the code small and understandable. I have a background in Pascal but Java is currently my language of choice as I find I'm more productive with it. And no, I don't particularly like EJB.
You mentioned Extreme Programming, a practice which orients the developer to producing small, loosely-coupled, tightly-cohesive modules. And if the code isn't that way the first time you create it, it adds a set of practices that aid the developer it putting it into that condition.
This has little to do with "incremental hacking" but rather factors human cognitive progression (we gradually understand a problem and its solution) into the software creation process. You can apply agile processes to procedural or functional programming just as easily, although you'd be hard-pressed to find an "agile" book with C, Pascal, or COBOL examples in them.
So how many times must you encode the rules for "contributing" to the river consistently? Relational data constraints often cannot handle complex decisions based on individual values in a record or a set of related records. Business consistency must then be enforced with code in every task accessing the data. You must repeat code, or at best, explicitly call it without fail, to ensure 'the river' does not become polluted. In cases like this, OO languages provide more powerful tools to represent this knowledge and ensure its consistent application.
Of course, there's no guarantee that a given developer will design with these tools (have a look under the covers of your average large EJB application and you'll see what I mean).
Happy coding (or, seeing as how I work on Compuware's OptimalJ, happy generating (grin)). BTW: MDA != OO, although you can produce one with the other.
Michael Murphree
Oh, man! That's so funny I think I just peed on my keyboard!
This explains why the XP technique of using Code Smells is so effective. "This code smells like crap!"
Actually I prefer weak grin bozon.
Well, OK, this particle is already named in the "Theory of Extra Special Relativity":
We start from the foundation of the dopeler effect: Stupid ideas that come at you rapidly seem smarter than they actually are.
Through our observations of individuals exposed to prolonged dopeler-shifted emanations, we can see that emission of dumb ideas tends to attract other dumb ideas, which in turn leads to a chain reaction of idiocy. All minds in the vicinity of high energy dolt fields are warped, consequently all conversations seem to take an infinitely long time.
Experimental evidence suggests that there is a limit to the density of weak grin bozon sources that any given region of space may sustain. Once this limit is passed, all thought in the region collapses in on itself to become a Quantum Imbecilic Singularity, from which no good idea may escape. QIS formations may be detected by searching for accretion disks of broken dreams, and massive jets of anticluons coming from a vector perpendicular to the back end of the accretion disk.
I'm kind of surprised that no one else has offered this speculation. I've been watching the news and hearing about China aiming for the moon.
Am I the only one who thinks that we might be headed for another space race? China might be the only nation with the economic potential to become a super power and nothing says super power better than putting people on the moon, or, say, Mars.
As was mentioned elsewhere, there are temporary job benefits, but the Bush administration has been known to think big before: Hydrogen economy... Global democracy...
I'm not claiming these efforts are "Right" or even fruitful, but they are big. Bush has made decisions to launch efforts that could only pay off long after he leaves office. And no, I'm not interested in debating Bush's intelligence.
Just food for thought.
Maybe I've been a programmer for too long... I completely understood that.
Doesn't TV add ten pounds to your appearance?
I don't need an even stronger reason to never turn the TV off.
Isn't the process of creation, rightly named, a performance? I wonder if that doesn't make pair programming performance art. Granted, at some point, common sense intrudes (not a troll) and the answer comes out "no," even when beauty is experienced in the process.
So what about an actor or actress portraying programming? Never mind...
Wow! A response in one line of code. Declarative programmers must get all the girls.
Then again, they'd have time to... Excuse me, I need to go reexamine my language preference.
Well said. I've often found well-written code (my own or that written by others) to be beautiful, but it cannot be called art. I've appreciated a spare user interface that leads the user to natural patterns of work, aiding the user through thoughtful metaphor and tasteful selection of color. But this was not art. As you say, it was the craft of someone artistic.
I've often thought that craftsmanship was an expression of loving care toward those who will use the thing being built; whether conscious or not. Art, from my perspective, is an expression of meaning, an act of exposing (or hiding) one's self to an audience. The intent is different.
I too have created art as well as crafted code. But not at the same time. I think game designers come the closest to doing that (Sid Meier comes to mind).
Agreed, coming up with good names for functions can be very hard. You've got to love design patterns, not only do they lead you to common structures, they lend their names also.
I have a fairly good idea what FooBarFactory.newFoo() is going to do.
Where nothing seen is ever true,
For then you will have no relief,
And beauty will be forever beyond you.
Rather pursue balance in your life,
Accept that you are what you make yourself;
Realize that knowing comes from strife,
Not from books found on a library shelf
Always struggle to understand,
But take time to notice beauty;
Not all of life is planned,
And not all of life is duty.
-- Michael Murphree
(copyright 2004 (with apologies to the
I don't know what it was, but I couldn't resist responding to this thread in this manner.
It is not so simple, of course. Many of those same third world countries that we (apologies, speaking as an American) do share with block or divert the aid away from the people who need it. It usually boils down to supporting a military that particular country can ill afford. Other times it's fear in the guise of beauracracy (genetically engineered crops come to mind).
The problem, is not that we don't share, the problem is rooted more significantly in greed on both sides. We overproduce (as a nation) and we (as individuals) selfishly take more than we need (see SUV comments above), and this completes the cycle. On the other side (the third world), a greed for power leaches productive capacity to support a military (or something similar in the form of warlords or terror clusters), because the neighbors are doing it also.
And no, government cannot legislate selflessness, that's only a form of totalitarianism. Positive selflessness can be taught, however. Parents can teach their children to think about the consequences of their consumption.
I think the real problem is actually one of scarcity. Scarcity of morality, scarcity of self-control, and scarcity of critical thinking. All of these skills may be taught.
elgoog == Spanish Google?
(ducks)
I am a SCO employee (sips cool-aid)
I have seen the code (sniffs powdery substance)
We will own IBM (eyes widen)
Linux is a copy of System V (sweat breaks out on brow)
Space aliens will come to save our stock... (puts on white tennis shoes)
OK, OK, IANASCOE. You have to feel for the developer-types there, though. They must be reading this kind of stuff. They can't use UNIX and not read Slashdot, right?
JBoss allows you to configure the server piecemeal. So if you don't need a JMS implementation, don't configure it. If you don't need distributed transaction support don't configure it... etc. JBoss/Jetty with dead-basic support for web and EJB can be slimmed down fairly well. Granted, you probably will have to pay for the doc to figure out how to do it (~$15).
Your other recourse is to try out something like OpenEJB OpenEJB runs as a component deployed to Tomcat.
hmmm... "constantly shifting FUD"... that'd be a FUDslide, right?
The answer: it depends.
My mother can handle user accounts on her machine by clicking the big buttons in XP. She's been able to install applications on her own.
I can't imagine her being able figure out (on her own) that she must unmount a CD-ROM in order to eject it. Nor would she get along well with a command prompt. She understands double-clicking quite well.
For myself, well, I run Red Hat 7.3 with custom built kernel (RAID 0 tweaks). I use Linux for web and e-mail, for software development (mostly J2EE stuff). I use WindowsXP for commercial games. At work I use Windows 2000 because its a corporate standard and I'm stuck with it.
I'm comfortable with finding and using RPMs or building apps from source. I'm comfortable diving through documentation and understanding the Unix tools at my disposal, and I love the flexiblity and freedom that gives me. Were I into cars I'd be tinkering with carburetors and custom paint jobs.
Linux is still for developer-types, in my opinion, and I prefer it that way. Having an OS/OE oriented toward software development is important, and satisfies a different need than the one Windows satisfies for my mother. She wants an appliance for e-mail, web browsing, games, and word processing.
The point I'm making in such a long-winded way, is that if you judge the quality of the OS by what it allows you to accomplish, the "winner" in any contest depends on what the user wants to do.
You beat me to clicking the Submit button. Good comment.
That smells like short-term memory to me.
The economics that allowed for a decline in welfare and a budget surplus were created under a conservative administration and eroded away by the previous liberal administration. The U.S. economy began it's down-turn well before G.W.Bush took office, not after. Bush inherited the economic mess the previous administration left behind.
More pointedly, the economic model of corporations trying to appear profitable as opposed to actually being profitable also hurt America's economy. When stock values went down, all the big corporations resorted to improving their "operations cost" by cutting payroll, hence cutting jobs. Executives did this regardless of how profitable the corporation was at the time.
This is not a problem caused by the current administration, or even the previous one. Nor was Enron, or WorldCom. This was a problem caused by greed (IMHO).
This same problem of greed, both on the part of the MPAA and their cousins in the cable companies, and the lobbyists and politicians, produces rushed laws that do more harm than good. When the laws of the land were first developed, they were considered thoughtfully. Great care was taken to represent the interests of the people. Legislators felt a heavy moral responsibility to make good decisions and good laws on behalf of the people who elected them
The moral impetus to represent public interest has been one or two steps removed from public office for quite a while. The driving force is to get reelected, and so, to make money. Corporate interests form a copious source of money, and hence legislation is passed without thought about the consequences for individuals, or even for the "economic good." Bad motive begets bad law.
Writing law can be like writing code: undesirable coupling yields side effects.
Since when have the free (as in beer) download versions of Linux (any GNU/Linux distribution) been "supportless?"
What do you call all of the documentation projects and forums and mailing lists available out there?
Those distributions may come without phone technical support, but most paid-for phone technical support in this industry has become a matter of brushing off users with real problems. You end up resorting to forums and e-mail to solve problems anyway. The other kind of OS support you might reasonably expect to pay for is on-site consultant support (like IBM), but you don't get that with Windows either.