Linux is a development methodology, not a product.
Okay, mod this "-1, Sarcastic" if you want. But I don't find the article to be particularly illuminating or useful. Linux can be viewed in many ways depending on your perspective and assumptions. Declaring that Linux is "not a product" is about as useful as saying the United States is "not a nation". Yeah, you can get some people's attention, but you're not saying much.
How about looking at the value of the "Linux way" of doing things? How about comparing the "Linux way" to other ways? Other people are trying to answer these questions, and those discussions are much more interesting to me than a simplistic "Linux is a process" label.
"Second, the data tables indicate a strong pressure bias - increases in pressure lead to great increases in thermal conductance:"
I can see it now, overclockers looking for ways to increase the pressure applied to the heatsink/die interface. Here's a future post from an overclocking forum:
"Hi peeps, I'm trying to put more pressure on my heat sink and need some advice. I've fabricated some titanium supports for the chip socket and motherboard with holes threaded on all four sides for even pressure, and welded supports onto the heat sink. But I'm not sure what setting to use on my torque wrench when I put the bolts on. Here are some pics of my setup (url1, url2, url3). Any thoughts?"
What others have suggested is ways to either reduce the "pain" associated with the work or increase the "pleasure".
We all work on the pain/pleasure principle: everything we do is an effort to reduce the pain and increase the pleasure in our lives. The pain or pleasure may be happening right now, or it may be some future pain/pleasure that we believe will occur.
Where it gets fun is all the ways we lie to ourselves in order to legitimize increasing our current pleasure. "Oh, I'll just check Slashdot real quick... what's ten minutes compared to the rest of the day?" "Yeah, those donuts are full of calories... but man they are so good, and they're not going to make any real difference." Yeah, sure.
I use a complex strategy to counter my procrastinating habits. I have to; my rationalizing habits and strategies are very ingrained and complex. I have to out-think myself. The details involve adding things to the "pleasure" side and removing things from the "pain" side until "pleasure" is greater than "pain":
- Stop thinking about it as one big project: break it down into pieces that are manageable in a small timespan. (Fifteen minutes to two hours.)
- Find a way to make the work less boring, unpleasant, difficult, etc., and more interesting, fun, personally rewarding.
- Create a meaningful reward system. And commit to it. (I tend to go right from one thing to the next and not reward myself: this is bad, because it increases the benefit of rewarding myself up-front, which makes me procrastinate more.)
- Focus on the unpleasant consequences of procrastination and let that be a spur. (This in combination with breaking the project down is a real winner: the consequences of procrastination are far more severe than the pain of getting one task done.)
There are other things I have to remember, too: it doesn't have to be perfect; it doesn't all have to get done in one session (it's okay to take breaks); getting it done is usually preferable to doing it the "right" way. These are antidotes for the training ("programming") I got from my parents.
Good luck. And be proud of yourself for asking for help!
I'm too young to have seen the development of the most revolutionary advances in climbing: the shoes, ropes, harnesses, belay devices, protection, etc. etc. But I sure do appreciate their benefits -- both in my ability to climb more difficult routes and (more importantly) the safety with which I can climb.
As an example of the benefits of new technology, consider the American climbing ratings system (the Yosemite Decimal System). Originally there were ten difficulty levels, from 5.1 to 5.10, 5.10 being "physically impossible". Today, it goes to 5.15 -- and thanks to the technical advances in gear, an amateur like myself can climb 5.10 or 5.11 (once considered "advanced" climbs).
Well said, Bedouin. I agree entirely -- although I think that while they don't need a sequel there's ample room for one.
What disappointed me most was the amount of silly comedy and the over-the-top gore. I was alternately laughing and rolling my eyes. I would have preferred a more serious, and less graphic, movie. But I'm old-fashioned and realize that doesn't sell to the kiddies.
Lots of good thoughts expressed already. Here's my list of reasons we don't reduce, reuse, recycle code well:
1. It goes against the unwritten rule of "elegance". Using someone else's code often means it just doesn't fit quite right into your program. We'd rather write our own solution that fits "perfectly" into our program than find and use someone else's solution that isn't quite perfect.
2. Trust. If I'm going to use someone else's code, can I trust that it is (relatively) bug-free? Can I trust that it does what it says it'll do? Without unseemly side effects?
3. It's more fun to write code than to search for code.
4. Hubris: I can do it better.
5. I know I can write my own solution. I don't know that I can find another solution, and that if I do it will work well enough for me (or won't require extensive modifications) and there won't be some other issue with it that will keep me from being able to use it. In short, I know I can develop a solution in n time... but if I spend time looking for and integrating another solution it's a crapshoot -- I might spend n/10 time or 10*n time.
Now let's look at some cases where reuse is working:
- Standard libraries. Popular languages come with a fairly large library of standard code. Reuse works here because (1) there's usually little/no choice and (2) being a standard library, there is a degree of trust given to it that is not granted other code.
- Popular add-on packages. Whether it's Log4J, a CPAN module, or a well-used bit of Javascript. Reuse works here because of trust: if lots of people are using it, it must be good.
- Really complicated things. Regex. Who wants to write regex code? Reuse works here because of the belief that you/can't/ do it better than has already been done.
- Really big things. Graphics libraries. Reuse works here because at some point a job becomes too large to tackle, compared to finding and using an existing solution -- even if the existing solution stinks.
In short, in order for code to be reused, it must be findable, usable, trustable, and valuable. The last meaning the time/effort spent in finding and learning existing code will be less than the time/effort spent coding a new solution.
That's 2c off the top of my head, I'm sure I can do better but it's late and I'm tired and I'm going to bed shortly.
You put the latest James Bond movie in your player, and your player (by law) automatically connects with your bank and credit card accounts. It sees you have made several purchases of Pepsi products in the past year, but no Coca Cola products. Unfortunately, as Coca Cola is a major advertiser^Wsponsor of the movie, you are barred from watching it -- it's required by law that you purchase products associated with "sponsors" in order to "protect the artists" who are making films. A pleasant voiceover says you must make a purchase of at least $45.83 in Coca Cola products to be qualified for the film.
Joking aside, the disrespect these organizations (and their backers) show for their consumers is astounding. This bunker mentality is resulting in an unnecessary war which both the recording/movie industries and consumers will lose. The industries will lose because people will stop buying their products. The consumers will lose due to the laws restricting their legal rights.
Move over government, this is the century of the mega-corp.
IMO it's not the corporate culture that's keeping them from supporting it. It's the fact that any kind of legal requirement of quality exposes them to huge liabilities. That impacts the bottom line. Microsoft would be a big fat target for lawsuits, simply because they have deep pockets. Lawyers can smell money like... ugh, please shoot me... like sharks can smell blood. Microsoft's budget for legal counsel will balloon just to keep enough lawyers on staff to handle the cases.
Like most everything else, this falls into a cost-benefit analysis. The Shuttle code, as many of us know, is perhaps the most high-quality code on the planet. Medical software ranks pretty highly as well (with a few exceptions). The script you put together to analyze hits on your corporate webserver was probably not given the same thorough analysis and attention. Why? Because if it fails, all it costs is some embarassment for you, maybe a little financial loss for the company if it based marketing/advertising decisions on your script's incorrect results.
In general, however, software quality is poor. It's usually one of the first things to get thrown out when the schedule slips (as it usually does). I would like to see higher quality standards enforced through an industry-acceptable mechanism.
The proximate cause for each accident was human decision-making. Yes, there are engineering weaknesses in the shuttle. There are also engineering weaknesses in my car. That doesn't mean the car and I share blame if I take a corner too fast.
If the Apollo team had had your attitude, the Apollo 13 capsule would have re-entered the Earth's atmosphere with three dead astronauts. Fortunately, they had a "can-do" attitude.
Both Challenger nor Columbia were caused by human error. In Challenger's case, the politicians/managers made the decision to go despite warnings from the engineers. In Columbia's case, they had the opportunity to take pictures of the shuttle in orbit, per suggestions by the engineers, but decided not to do so. (What they could have done to save the crew is a separate topic.)
So when we talk about the dangers of space flight, or how unreliable the shuttle fleet is, let's not forget how much of an element human decision-making is.
Basically, both OOP and AOP are syntactic niceties for something that you could do in C (if you were willing to jump through hoops to do it).
They are not just syntactic niceties. They are abstractions. (So is C for that matter.) They hide complexity, which lets you think at a higher level. Do not underestimate the power of abstractions. (Insert snide Star Wars comment.)
, do a Google search on "law of Demeter". The basic rule is only talk to your friends. You know about low coupling, right? LoD is perhaps the most well-known idiom exemplifying this rule.
Finally... I can believe, just barely, that it is possible to have a class that has a valid reason for importing from two dozen packages, but I definitely want a tool to point it out to me and ask me if I'm sure that's really what I want. I can choose to ignore it, just like I ignore deprecation warnings. That's not second guessing, that's giving advice.
PMD looks interesting. I'll take a look, thanks. (And if I get real ambitious I'll see about integrating it into Eclipse, assuming it hasn't already been done. But don't hold your breath:).)
Maybe it was just my reading, but I did get a sense that they were at least implying that OOP was being supplanted or perhaps deprecated in favor of XP, patterns, AOP. And I also kept getting a sense of "gee, that's hardly news". Still, I was in a bit of a mood yesterday and so I was more critical than I ought to have been.
There are so many obvious glaring problems with this article I'm surprised it got published. XP as a "replacement" for OOP? Goodness, one is a methodology for building software, the other is a programming mechanism. Patterns? They are applicable in areas other than OOP. Like... architecture for instance . AOP? That's just a fancy way of inserting code into a class. Same principle as using #define in C or C++, though certainly more powerful.
Most of the 'problems' of OOP are the same as the 'problems' with older languages and practices. Simply put, once you weed out the people who aren't very good at design or programming, the lazy, the stress-cases under schedule pressure, etc. etc., you have a small group of people left who are building "good" software. (Measured by the quality of the code itself, not the success of the product.)
One of the biggest impediments to good software IMO is that the current crop of languages and tools don't punish laziness up-front. Using a magic number (or string) in a dozen places? No compiler will complain. Got a method that is calling myFoo.getList().calculateMarbleSize().insertInto( table )? No problem! Got a class that's importing classes from two dozen packages? Hey, it compiles, it must be good.
All of these examples are well-understood problems which can be avoided or fixed with very little effort. But until we have languages and tools that actively encourage good practices, we'll keep writing crap.
(Insert a rant about methodologies here -- I'm not going to go on anymore.)
Slashdot Mirror
Linux is an ecosystem, not a product.
Linux is a philosophy, not a product.
Linux is a culture, not a product.
Linux is a development methodology, not a product.
Okay, mod this "-1, Sarcastic" if you want. But I don't find the article to be particularly illuminating or useful. Linux can be viewed in many ways depending on your perspective and assumptions. Declaring that Linux is "not a product" is about as useful as saying the United States is "not a nation". Yeah, you can get some people's attention, but you're not saying much.
How about looking at the value of the "Linux way" of doing things? How about comparing the "Linux way" to other ways? Other people are trying to answer these questions, and those discussions are much more interesting to me than a simplistic "Linux is a process" label.
My curmudgeonly 2c worth....
-Thomas
"Second, the data tables indicate a strong pressure bias - increases in pressure lead to great increases in thermal conductance:"
I can see it now, overclockers looking for ways to increase the pressure applied to the heatsink/die interface. Here's a future post from an overclocking forum:
"Hi peeps, I'm trying to put more pressure on my heat sink and need some advice. I've fabricated some titanium supports for the chip socket and motherboard with holes threaded on all four sides for even pressure, and welded supports onto the heat sink. But I'm not sure what setting to use on my torque wrench when I put the bolts on. Here are some pics of my setup (url1, url2, url3). Any thoughts?"
-Thomas
What others have suggested is ways to either reduce the "pain" associated with the work or increase the "pleasure".
We all work on the pain/pleasure principle: everything we do is an effort to reduce the pain and increase the pleasure in our lives. The pain or pleasure may be happening right now, or it may be some future pain/pleasure that we believe will occur.
Where it gets fun is all the ways we lie to ourselves in order to legitimize increasing our current pleasure. "Oh, I'll just check Slashdot real quick... what's ten minutes compared to the rest of the day?" "Yeah, those donuts are full of calories... but man they are so good, and they're not going to make any real difference." Yeah, sure.
I use a complex strategy to counter my procrastinating habits. I have to; my rationalizing habits and strategies are very ingrained and complex. I have to out-think myself. The details involve adding things to the "pleasure" side and removing things from the "pain" side until "pleasure" is greater than "pain":
- Stop thinking about it as one big project: break it down into pieces that are manageable in a small timespan. (Fifteen minutes to two hours.)
- Find a way to make the work less boring, unpleasant, difficult, etc., and more interesting, fun, personally rewarding.
- Create a meaningful reward system. And commit to it. (I tend to go right from one thing to the next and not reward myself: this is bad, because it increases the benefit of rewarding myself up-front, which makes me procrastinate more.)
- Focus on the unpleasant consequences of procrastination and let that be a spur. (This in combination with breaking the project down is a real winner: the consequences of procrastination are far more severe than the pain of getting one task done.)
There are other things I have to remember, too: it doesn't have to be perfect; it doesn't all have to get done in one session (it's okay to take breaks); getting it done is usually preferable to doing it the "right" way. These are antidotes for the training ("programming") I got from my parents.
Good luck. And be proud of yourself for asking for help!
-Thomas
Ah yes, Gilligan's Island: the first Reality TV show. "Survivor" is a pale comparison.
I'm too young to have seen the development of the most revolutionary advances in climbing: the shoes, ropes, harnesses, belay devices, protection, etc. etc. But I sure do appreciate their benefits -- both in my ability to climb more difficult routes and (more importantly) the safety with which I can climb.
As an example of the benefits of new technology, consider the American climbing ratings system (the Yosemite Decimal System). Originally there were ten difficulty levels, from 5.1 to 5.10, 5.10 being "physically impossible". Today, it goes to 5.15 -- and thanks to the technical advances in gear, an amateur like myself can climb 5.10 or 5.11 (once considered "advanced" climbs).
-Thomas
You think that's bad, man, you should see the I-beam!
-Thomas
Well said, Bedouin. I agree entirely -- although I think that while they don't need a sequel there's ample room for one.
What disappointed me most was the amount of silly comedy and the over-the-top gore. I was alternately laughing and rolling my eyes. I would have preferred a more serious, and less graphic, movie. But I'm old-fashioned and realize that doesn't sell to the kiddies.
-Thomas
On the other hand, you could always switch to an operating system with longer uptimes.... ;)
(Troll-mode off.)
-Thomas
Ah yes, the Good Old Days when I used graph paper and pencil to design graphics and fonts for my Commodore 64.
"my arm was flailing for several minutes, and my hand was jittering for several hours."
Heh. Sounds like me after too much coffee.
Lots of good thoughts expressed already. Here's my list of reasons we don't reduce, reuse, recycle code well:
/can't/ do it better than has already been done.
1. It goes against the unwritten rule of "elegance". Using someone else's code often means it just doesn't fit quite right into your program. We'd rather write our own solution that fits "perfectly" into our program than find and use someone else's solution that isn't quite perfect.
2. Trust. If I'm going to use someone else's code, can I trust that it is (relatively) bug-free? Can I trust that it does what it says it'll do? Without unseemly side effects?
3. It's more fun to write code than to search for code.
4. Hubris: I can do it better.
5. I know I can write my own solution. I don't know that I can find another solution, and that if I do it will work well enough for me (or won't require extensive modifications) and there won't be some other issue with it that will keep me from being able to use it. In short, I know I can develop a solution in n time... but if I spend time looking for and integrating another solution it's a crapshoot -- I might spend n/10 time or 10*n time.
Now let's look at some cases where reuse is working:
- Standard libraries. Popular languages come with a fairly large library of standard code. Reuse works here because (1) there's usually little/no choice and (2) being a standard library, there is a degree of trust given to it that is not granted other code.
- Popular add-on packages. Whether it's Log4J, a CPAN module, or a well-used bit of Javascript. Reuse works here because of trust: if lots of people are using it, it must be good.
- Really complicated things. Regex. Who wants to write regex code? Reuse works here because of the belief that you
- Really big things. Graphics libraries. Reuse works here because at some point a job becomes too large to tackle, compared to finding and using an existing solution -- even if the existing solution stinks.
In short, in order for code to be reused, it must be findable, usable, trustable, and valuable. The last meaning the time/effort spent in finding and learning existing code will be less than the time/effort spent coding a new solution.
That's 2c off the top of my head, I'm sure I can do better but it's late and I'm tired and I'm going to bed shortly.
-Thomas
I can't wait 'til they have climbing shoes with "gecko rubber" instead of Stealth rubber. 5.12, here I come!
-Thomas
Well, that's because Slashdot is full of young people who don't understand the difference between cost and benefit, or price and value.
-Thomas
You put the latest James Bond movie in your player, and your player (by law) automatically connects with your bank and credit card accounts. It sees you have made several purchases of Pepsi products in the past year, but no Coca Cola products. Unfortunately, as Coca Cola is a major advertiser^Wsponsor of the movie, you are barred from watching it -- it's required by law that you purchase products associated with "sponsors" in order to "protect the artists" who are making films. A pleasant voiceover says you must make a purchase of at least $45.83 in Coca Cola products to be qualified for the film.
Joking aside, the disrespect these organizations (and their backers) show for their consumers is astounding. This bunker mentality is resulting in an unnecessary war which both the recording/movie industries and consumers will lose. The industries will lose because people will stop buying their products. The consumers will lose due to the laws restricting their legal rights.
Move over government, this is the century of the mega-corp.
-Thomas
Custom-built recliners? I wonder how they compare to the La-Z-Boy I had growing up.
...and a light side. Any technology can be used for evil or for good. As long as evil lives in men's hearts, we will have people who abuse technology.
So don't choose the dark side. Once you choose it, forever will it dominate your destiny. (Until your son saves you.)
-Thomas
IMO it's not the corporate culture that's keeping them from supporting it. It's the fact that any kind of legal requirement of quality exposes them to huge liabilities. That impacts the bottom line. Microsoft would be a big fat target for lawsuits, simply because they have deep pockets. Lawyers can smell money like... ugh, please shoot me... like sharks can smell blood. Microsoft's budget for legal counsel will balloon just to keep enough lawyers on staff to handle the cases.
-Thomas
Like most everything else, this falls into a cost-benefit analysis. The Shuttle code, as many of us know, is perhaps the most high-quality code on the planet. Medical software ranks pretty highly as well (with a few exceptions). The script you put together to analyze hits on your corporate webserver was probably not given the same thorough analysis and attention. Why? Because if it fails, all it costs is some embarassment for you, maybe a little financial loss for the company if it based marketing/advertising decisions on your script's incorrect results.
In general, however, software quality is poor. It's usually one of the first things to get thrown out when the schedule slips (as it usually does). I would like to see higher quality standards enforced through an industry-acceptable mechanism.
-Thomas
An even more fair comparison would be to match up the chips most similar in performance.
Wait...
Nevermind.
The proximate cause for each accident was human decision-making. Yes, there are engineering weaknesses in the shuttle. There are also engineering weaknesses in my car. That doesn't mean the car and I share blame if I take a corner too fast.
If the Apollo team had had your attitude, the Apollo 13 capsule would have re-entered the Earth's atmosphere with three dead astronauts. Fortunately, they had a "can-do" attitude.
Both Challenger nor Columbia were caused by human error. In Challenger's case, the politicians/managers made the decision to go despite warnings from the engineers. In Columbia's case, they had the opportunity to take pictures of the shuttle in orbit, per suggestions by the engineers, but decided not to do so. (What they could have done to save the crew is a separate topic.)
So when we talk about the dangers of space flight, or how unreliable the shuttle fleet is, let's not forget how much of an element human decision-making is.
-Thomas
They are not just syntactic niceties. They are abstractions. (So is C for that matter.) They hide complexity, which lets you think at a higher level. Do not underestimate the power of abstractions. (Insert snide Star Wars comment.)
Regarding
, do a Google search on "law of Demeter". The basic rule is only talk to your friends. You know about low coupling, right? LoD is perhaps the most well-known idiom exemplifying this rule.Finally... I can believe, just barely, that it is possible to have a class that has a valid reason for importing from two dozen packages, but I definitely want a tool to point it out to me and ask me if I'm sure that's really what I want. I can choose to ignore it, just like I ignore deprecation warnings. That's not second guessing, that's giving advice.
-Thomas
PMD looks interesting. I'll take a look, thanks. (And if I get real ambitious I'll see about integrating it into Eclipse, assuming it hasn't already been done. But don't hold your breath :).)
Maybe it was just my reading, but I did get a sense that they were at least implying that OOP was being supplanted or perhaps deprecated in favor of XP, patterns, AOP. And I also kept getting a sense of "gee, that's hardly news". Still, I was in a bit of a mood yesterday and so I was more critical than I ought to have been.
-Thomas
There are so many obvious glaring problems with this article I'm surprised it got published. XP as a "replacement" for OOP? Goodness, one is a methodology for building software, the other is a programming mechanism. Patterns? They are applicable in areas other than OOP. Like... architecture for instance . AOP? That's just a fancy way of inserting code into a class. Same principle as using #define in C or C++, though certainly more powerful.
Most of the 'problems' of OOP are the same as the 'problems' with older languages and practices. Simply put, once you weed out the people who aren't very good at design or programming, the lazy, the stress-cases under schedule pressure, etc. etc., you have a small group of people left who are building "good" software. (Measured by the quality of the code itself, not the success of the product.)
One of the biggest impediments to good software IMO is that the current crop of languages and tools don't punish laziness up-front. Using a magic number (or string) in a dozen places? No compiler will complain. Got a method that is calling myFoo.getList().calculateMarbleSize().insertInto( table )? No problem! Got a class that's importing classes from two dozen packages? Hey, it compiles, it must be good.
All of these examples are well-understood problems which can be avoided or fixed with very little effort. But until we have languages and tools that actively encourage good practices, we'll keep writing crap.
(Insert a rant about methodologies here -- I'm not going to go on anymore.)
-Thomas