Every time a product starts to get good, some greedy fugknuckle on the project decides to close the source. We've seen it again and again. Here are the ones the come to mind:
FICS - Free Internet Chess Server DD-WRT - Firmware for Linksys router CDDB - Distrubted CD catalogue system BitTorrent - File transfer (on/. yesterday) Now MySQL
I'm sure others could add plenty more examples. Anyone who committed to developing or using these products because the were FOSS has been badly burned.
I think this is becoming a bigger threat to open source than any other and it certainly puts me off contributing anything. What I don't understand is how this is even possible under GPL? I thought if you built on it, you had to release the source.
What are you defending exactly? These record companies no longer have anything to contribute. A person can pretty much do it all themselves from marketing to distribution thanks to technology. The reason you can't think of a better way to protect their interests is that their interests are in a product that no longer has value. Do you just want to pay someone for the product, or do you actually want to see the artist who produced the work benefit from your financial contribution?
Let me be the first to suggest UseToBeMySQL or NowItsNotYourSQL. Or better yet SoldOutMySQL. SQLMoneyWhore might not fly but then again offensive names don't seem to be a problem with open source (I'm thinking of GIMP).
I think when it was written it was quite probably the best book out there and I can see how it would have been definitive for coding C under Unix. However I've seen many better books since. Things have moved on. K & R is neither easy to read nor engaging. I'd only use it as a secondary reference these days.
You'll spend hours working around the fact that different vendors do even basic things like giving a record a unique identifier in different ways.
That's called coding in the kitchen sink just in case. There may be good reasons to avoid using JDBC but differences in implementation between database vendors ain't one of them.
Just how many enterprise systems have you worked on where the database vendor for the underlying schema has changed even once throughout its lifetime? I'm not talking about minor version upgrades but going from one vendor to another? Do you really think you could change to a different vendor without a complete re-test? The databases work differently enough that you'd be mad to try it. Chances are you'd need to tweak something (or more likely many things) in your code before you had something that behaved similarly.
Frameworks are great. People who use them often suck.
Ah yes because if it's not simple and intuitive it's easier to say everyone sucks at coding than to build a framework that doesn't require a PhD to use correctly. Gotta love IT sometimes.
I have no experience of Struts, but if you have this problem with Spring MVC, you're using it wrong. Seriously. Spring MVC has helped me write some of the simplest, most maintainable web code I've ever worked with. Almost everything is automated: all I have to do in most situations for a common database view/query/update form is write a handful of lines of validation code, and usually a line or two of code to interact with a database access layer
What are you using to automate? Do you have specific look and feel requirements from your users that violate the model you're working with? (eg. list views that save and also have details views that save). I don't get to choose the requirements. I also don't get to choose the tool unfortunately.
If you're talking about Spring-style dependency injection, my experiences is that for almost any non-trivial code you'll more than gain anything you lose in readability or tracability in ease of writing unit tests.
Have you ever tried an interactive debugger with injections? You have 2 options: 1) Trace through lots of spring code that handles the injection 2) Put a breakpoint at the entry point and treat it like magic.
Of course there's a cost. Writing code without tests is much faster than doing so with tests, but being confident that it's correct is the trick....and you think a bunch of esoteric XML files, difficult to trace code, new language constructs and frameworks that are never allowed to mature before the next big thing comes along are the way to do this??? Please!
Most of us aren't able to write correct code reliably
So what are you telling me? That thanks to the magic of Spring your code is now bug free??? Or that your skills are so poor you require the latest and greatest language constructs and techniques to write something that works? I've never had problems writing correct code before these frameworks, but I've also never seen a complex system that was totally bug free.
And in my experience, writing tests first is faster than writing them immediately after
Again your experience is limited if your requirements never change and perfect tests can be written up front. What if you don't quite know how to solve a problem? In any complex system you're going to have some revision of the interface, and even more revision of the implementation, and that's before you get those requirements changes.
Do you honestly think there's much new in these frameworks? If so you're either gullible or you're not being honest. I really wonder what kind of systems you work on that you can automate writing most of the code. I'm inclinded to be of the opinion that this is a religion and you're a defender of the faith. Pure and simple.
However just because there are programmer who can use it well, doesn't mean that they will, or that there aren't plenty more who can't use it to save their life. It takes expertise, and it's still usually harder to code that does things by jumping around.
To use your own analogy if you were teaching people to cut weeds, you'd never start with the damn chainsaw. You'd teach them to cut weeds and when they were proficient progress them to bringing down trees with a chainsaw.
The real problem with comments (and tests unless you run continuous integration) is that they break easily ie. you can easily change the code without changing the comments.
You really need all 3 to have a decent system maintainable by a group: 1) Good neat code with well named identifiers 2) Comments 3) Tests
Yes that's 3 times the work and 3 times the maintenance. You get nothing for nothing.
So how can you minimize the work?
Good choice of granularity when commenting and testing.
For commenting always comment what isn't obvious from the well written code. You don't need a comment telling you that the method String getPersonsName() returns a string. The return type is staring you in the face. If the return type changes it's easy to accidentally miss the comment when modifying the code, particularly if you're making big changes. The method calculateTaxRate(...) shouldn't have a comment stating that you calculate the tax rate. It should explain the method used and refer to an external document if that explanation is too long. Asinine development standards would insist that we comment these. That's BS.
For tests, lets say you have a business layer and a data layer, and the business layer trivially calls the data layer. Do you really need a test at every layer? Perhaps a data layer test is enough if you're certain the business layer isn't likely to break. If it is, perhaps the business layer can do both. Half the code you have to write and maintain, but twice as much relying on that one test, so get it right.
Did you not even read what I said? You know the part about not referring to just this book. Mind you the blog site for the book that started going into detail about why Singleton (the most obvious fucking "pattern") is so "beautiful". I could have blown chunks right there. Effective and elegant if used correctly? Yes. A neat technique? Yes. Beautiful? Shit it ain't a non-obvious piece of elegance we're talking about here....and I couldn't care less who wrote it. Hero worship should have no place in computer science and engineering.
By the way K & R - the supposed C bible - is one of the least readable C books I own! If you think I'm talking out of my backside I'll just tell you I had to use it to teach a C course once (long ago, an elective as and as a part time activity). Fortunately the previous lecturer's notes were stellar, and I had learnt from a different C book which I could refer to. This book confused more students than it helped (though the ones that like esoteric unintuitive dense but fully descriptive text did get something out of it). 90% of the students though many people that read K & R with no previous banground in C had no freaking idea how dereferencing worked. I spent an entire lesson on it because I think it's one of the key things that a good C programmer understands the MEANING of, where an average or bad one just knows they have to use it (and subsequently get stuck debugging pointers when they don't work as expected).
It's way too big to be a planet and since small planets are called dwarf planets, please welcome the first discovered troll planet.
According to the insanely stupid definition adopted by the IAU nothing that isn't circling our sun is suppose to be called a planet or dwarf planet anymore.
Yeah I've seen that too - I use to know a guy in Uni who originally learnt BASIC, and always had a set of #defines in a header file he'd use to make BASIC constructs work in C. What a mess!
A) If prices start at $0 some group of individuals will start either automatically or (if that's not possible) manually downloading all $0 tracks one or more times a day. This creates artificial demand. B) As it catches on that there's free music to be had more people will do A. Ultimately casual users will miss out altogether and only the fastest from group A will get tunes for free. C) There is bound to be a subgroup of A that thinks "music wants to be free" or believes everyone should have access to it at the same cost (zero) as they got it for. The music will make its way onto the usual illegal file sharing networks. D) Casual users are still left with the same option. Buy for $0.98 or download for free illegally.
Is anyone else jaded by these books that go on and on about why a particular techique or code snippet or methodology is "right" or "beautiful" or "the way forward"?
I look at some of the code mentioned and yes it's neat. Some of the code snippets from these books (not just this one specifically) is either really obvious or makes me want to blow chunks because it's an over-complication or over-simplification just to demonstrate a technique which you know will be over-applied and end up in some set of corporate standards that sees it being misused....then there's some of the frameworks and methodologies out there that are generally worshiped as God's own code, but which when you try to use them turn out to be cumbersome, horrible, unintuitive messes. Years later this is suddenly "discovered" (EJBs I'm thinking of you!!!) and a whole new set of horrible frameworks goes through several iterations (Hibernate 1 vs 2 vs Spring persistence, Struts vs Spring MVC) where nothing is allowed to mature for long enough to have the major bugs ironed out.
Perhaps I'm just getting old but I'm really getting tired of all this. You want to know what makes code beautiful?
1) It does the job 100% correctly as intended. 2) It does it as simply as possible - not so simple it doesn't work, and no more complex than it absolutely needs to be...building everything in but the kitchen sink just in case is a fool's game. 3) It's readable and well documented enough that anyone who knows the language (or better yet a programmer familiar with a similar framework but not this one) understands it. 4) Its easy and quick to make changes as requirements change - that means GUI tools for GUI development (What ever happened to RAD tools being the norm in the industry!? It can take a week to make significant changes to a web page in Struts or Spring MVC, where it use to take about a day to do it for the clients developed with the RAD tools of the late 90s!) 5) It fits in well with the rest of the system. A module that works beautifully in isolation but doesn't fit in with the system can ruin the system.
All the rest is just a bunch of consultants trying to bilk you for cash.
Yes patterns can help, but they can also hurt. Yes externalizing code into config files can make a system more flexible (but you'll pay for it in readability and tracability/debugability). Yes aspects of the agile methodology - continual integration and test driven coding - can help but they're not the only way and there's a cost associated. Yes Object oriented code offers things that procedural does not, but again there's a cost and your developers better understand the language constructs.
You need to look at each of the above as tools in your arsenal, not religious doctrine.
Note that my recent experience is with Java/J2EE so that's where my examples come from but I've worked on dozens of languages and frameworks.
Actually it reads more like "Lookie I've brainwashed my chickie and can get her to do the work when she asks for help". It also comes across as condescending. Of course a woman with sufficient interest and motivation could put together a PC, or at least many/most women will be able to. To me that's a given. Having a vagina doesn't suddenly mean you're incapable of putting together what essentially is a technical jigsaw puzzle.
Hell I'm more interested in software so while I've fiddled with adding components, I've never built a PC from scratch - I get someone who does it for a living to do it for me when I need one put together.
Aw hell if this all it takes to get onto/. perhaps I should get pics of my fiancee doing advanced edits in photo editing software and put together a "story".;-)
Actually you have a point and I don't think you should be modded funny.
However I also think it's flawed to try to point at a single cause for industrialization. I think a whole set of inter-related changes led to the boom in the 1800s. Part of it was better medicine and living conditions. Part of it was increased trade allowing things such as tea and coffee (and many other useful things!) to become more widely available. Part of it was the culture at the time that supported the ideal of working long hours to avoid poverty. Part of it was advances in science and engineering. All these things mingle.
For example science feeds into medical science, which is sustained by trade of knowledge and materials, which also helps engineering. etc. etc.
After all, if you don't have cancer, why should you pay extra for the people who do?
So that you don't have people desperate for cash because they're dying, and who have nothing to lose because they're dying running around. Do you have any idea how dangerous someone who knows that there is no legal way to get cash for their terminal disease (or worse their children's) would be?
Hillary might use your tax money to do the wrong sort of good. Bush is using it to do harm.
If the end result is the same who cares? There's no practical difference between allowing someone stupid without intent to do damage vs someone evil with intent. The results is still the same damage.
Studies show that men are more linear thinkers while women tend to think in circular patterns. Men are more big-picture thinkers, women pay more attention to detail.
I can accept that men and women think differently. But big picture vs more detail is a personal trait. I am more big picture myself but you go out to your local scale modellers club - whether they model realistic trains, planes, war machines or automobiles and tell me they aren't details people (and yet there's a hobby few women take up or enjoy).
I'll let you in on something else. When women are truely interested in doing something and find it male dominated, they tend to form their own clubs that are female friendly (and sometimes ones that exclude men). It's only when this isn't possible (eg. legislation empowers a professional body to license them) that this doesn't work. That isn't the case in IT.
My experience has been that when women actually want to work in IT they're excellent at it and often outdo the guys. My experience is also that this is painfully rare and most women have no interest in technology and gadgetry.
I can't believe anyone would dismiss MAD and the prolific network of nuclear weapons that it comprises as something was "never going to end it all". Call me a pessemist but we possess enough technological prowess now that I believe ANY misuse has the potential to kill us. The key differences between MAD and global warming is the pace at which catastrophic change occurs, and possibly our ability to recover in the long term.
Slashdot Mirror
Every time a product starts to get good, some greedy fugknuckle on the project decides to close the source. We've seen it again and again. Here are the ones the come to mind:
/. yesterday)
FICS - Free Internet Chess Server
DD-WRT - Firmware for Linksys router
CDDB - Distrubted CD catalogue system
BitTorrent - File transfer (on
Now MySQL
I'm sure others could add plenty more examples. Anyone who committed to developing or using these products because the were FOSS has been badly burned.
I think this is becoming a bigger threat to open source than any other and it certainly puts me off contributing anything. What I don't understand is how this is even possible under GPL? I thought if you built on it, you had to release the source.
What are you defending exactly? These record companies no longer have anything to contribute. A person can pretty much do it all themselves from marketing to distribution thanks to technology. The reason you can't think of a better way to protect their interests is that their interests are in a product that no longer has value. Do you just want to pay someone for the product, or do you actually want to see the artist who produced the work benefit from your financial contribution?
Let me be the first to suggest UseToBeMySQL or NowItsNotYourSQL. Or better yet SoldOutMySQL. SQLMoneyWhore might not fly but then again offensive names don't seem to be a problem with open source (I'm thinking of GIMP).
On any given system you only need to solve a subset of the problem.
The elitist attitude must make you one hell of a treasure to work with on a team.
We'll just have to disagree on that.
I think when it was written it was quite probably the best book out there and I can see how it would have been definitive for coding C under Unix. However I've seen many better books since. Things have moved on. K & R is neither easy to read nor engaging. I'd only use it as a secondary reference these days.
You'll spend hours working around the fact that different vendors do even basic things like giving a record a unique identifier in different ways.
That's called coding in the kitchen sink just in case. There may be good reasons to avoid using JDBC but differences in implementation between database vendors ain't one of them.
Just how many enterprise systems have you worked on where the database vendor for the underlying schema has changed even once throughout its lifetime? I'm not talking about minor version upgrades but going from one vendor to another? Do you really think you could change to a different vendor without a complete re-test? The databases work differently enough that you'd be mad to try it. Chances are you'd need to tweak something (or more likely many things) in your code before you had something that behaved similarly.
Frameworks are great. People who use them often suck.
Ah yes because if it's not simple and intuitive it's easier to say everyone sucks at coding than to build a framework that doesn't require a PhD to use correctly. Gotta love IT sometimes.
I have no experience of Struts, but if you have this problem with Spring MVC, you're using it wrong. Seriously. Spring MVC has helped me write some of the simplest, most maintainable web code I've ever worked with. Almost everything is automated: all I have to do in most situations for a common database view/query/update form is write a handful of lines of validation code, and usually a line or two of code to interact with a database access layer
...and you think a bunch of esoteric XML files, difficult to trace code, new language constructs and frameworks that are never allowed to mature before the next big thing comes along are the way to do this??? Please!
What are you using to automate? Do you have specific look and feel requirements from your users that violate the model you're working with? (eg. list views that save and also have details views that save). I don't get to choose the requirements. I also don't get to choose the tool unfortunately.
If you're talking about Spring-style dependency injection, my experiences is that for almost any non-trivial code you'll more than gain anything you lose in readability or tracability in ease of writing unit tests.
Have you ever tried an interactive debugger with injections? You have 2 options:
1) Trace through lots of spring code that handles the injection
2) Put a breakpoint at the entry point and treat it like magic.
Of course there's a cost. Writing code without tests is much faster than doing so with tests, but being confident that it's correct is the trick.
Most of us aren't able to write correct code reliably
So what are you telling me? That thanks to the magic of Spring your code is now bug free??? Or that your skills are so poor you require the latest and greatest language constructs and techniques to write something that works? I've never had problems writing correct code before these frameworks, but I've also never seen a complex system that was totally bug free.
And in my experience, writing tests first is faster than writing them immediately after
Again your experience is limited if your requirements never change and perfect tests can be written up front. What if you don't quite know how to solve a problem? In any complex system you're going to have some revision of the interface, and even more revision of the implementation, and that's before you get those requirements changes.
Do you honestly think there's much new in these frameworks? If so you're either gullible or you're not being honest. I really wonder what kind of systems you work on that you can automate writing most of the code. I'm inclinded to be of the opinion that this is a religion and you're a defender of the faith. Pure and simple.
If you have a good REASON to use GOTO, yeah okay.
However just because there are programmer who can use it well, doesn't mean that they will, or that there aren't plenty more who can't use it to save their life. It takes expertise, and it's still usually harder to code that does things by jumping around.
To use your own analogy if you were teaching people to cut weeds, you'd never start with the damn chainsaw. You'd teach them to cut weeds and when they were proficient progress them to bringing down trees with a chainsaw.
The real problem with comments (and tests unless you run continuous integration) is that they break easily ie. you can easily change the code without changing the comments.
You really need all 3 to have a decent system maintainable by a group:
1) Good neat code with well named identifiers
2) Comments
3) Tests
Yes that's 3 times the work and 3 times the maintenance. You get nothing for nothing.
So how can you minimize the work?
Good choice of granularity when commenting and testing.
For commenting always comment what isn't obvious from the well written code. You don't need a comment telling you that the method String getPersonsName() returns a string. The return type is staring you in the face. If the return type changes it's easy to accidentally miss the comment when modifying the code, particularly if you're making big changes. The method calculateTaxRate(...) shouldn't have a comment stating that you calculate the tax rate. It should explain the method used and refer to an external document if that explanation is too long. Asinine development standards would insist that we comment these. That's BS.
For tests, lets say you have a business layer and a data layer, and the business layer trivially calls the data layer. Do you really need a test at every layer? Perhaps a data layer test is enough if you're certain the business layer isn't likely to break. If it is, perhaps the business layer can do both. Half the code you have to write and maintain, but twice as much relying on that one test, so get it right.
Better summarized on a toilet cubicle at a Uni I wonce attended:
Little boy blue - he needed the money.
Did you not even read what I said? You know the part about not referring to just this book. Mind you the blog site for the book that started going into detail about why Singleton (the most obvious fucking "pattern") is so "beautiful". I could have blown chunks right there. Effective and elegant if used correctly? Yes. A neat technique? Yes. Beautiful? Shit it ain't a non-obvious piece of elegance we're talking about here. ...and I couldn't care less who wrote it. Hero worship should have no place in computer science and engineering.
By the way K & R - the supposed C bible - is one of the least readable C books I own! If you think I'm talking out of my backside I'll just tell you I had to use it to teach a C course once (long ago, an elective as and as a part time activity). Fortunately the previous lecturer's notes were stellar, and I had learnt from a different C book which I could refer to. This book confused more students than it helped (though the ones that like esoteric unintuitive dense but fully descriptive text did get something out of it). 90% of the students though many people that read K & R with no previous banground in C had no freaking idea how dereferencing worked. I spent an entire lesson on it because I think it's one of the key things that a good C programmer understands the MEANING of, where an average or bad one just knows they have to use it (and subsequently get stuck debugging pointers when they don't work as expected).
I agree.
It's way too big to be a planet and since small planets are called dwarf planets, please welcome the first discovered troll planet.
According to the insanely stupid definition adopted by the IAU nothing that isn't circling our sun is suppose to be called a planet or dwarf planet anymore.
Yeah I've seen that too - I use to know a guy in Uni who originally learnt BASIC, and always had a set of #defines in a header file he'd use to make BASIC constructs work in C. What a mess!
A) If prices start at $0 some group of individuals will start either automatically or (if that's not possible) manually downloading all $0 tracks one or more times a day. This creates artificial demand.
B) As it catches on that there's free music to be had more people will do A. Ultimately casual users will miss out altogether and only the fastest from group A will get tunes for free.
C) There is bound to be a subgroup of A that thinks "music wants to be free" or believes everyone should have access to it at the same cost (zero) as they got it for. The music will make its way onto the usual illegal file sharing networks.
D) Casual users are still left with the same option. Buy for $0.98 or download for free illegally.
Is anyone else jaded by these books that go on and on about why a particular techique or code snippet or methodology is "right" or "beautiful" or "the way forward"?
...then there's some of the frameworks and methodologies out there that are generally worshiped as God's own code, but which when you try to use them turn out to be cumbersome, horrible, unintuitive messes. Years later this is suddenly "discovered" (EJBs I'm thinking of you!!!) and a whole new set of horrible frameworks goes through several iterations (Hibernate 1 vs 2 vs Spring persistence, Struts vs Spring MVC) where nothing is allowed to mature for long enough to have the major bugs ironed out.
I look at some of the code mentioned and yes it's neat. Some of the code snippets from these books (not just this one specifically) is either really obvious or makes me want to blow chunks because it's an over-complication or over-simplification just to demonstrate a technique which you know will be over-applied and end up in some set of corporate standards that sees it being misused.
Perhaps I'm just getting old but I'm really getting tired of all this. You want to know what makes code beautiful?
1) It does the job 100% correctly as intended.
2) It does it as simply as possible - not so simple it doesn't work, and no more complex than it absolutely needs to be...building everything in but the kitchen sink just in case is a fool's game.
3) It's readable and well documented enough that anyone who knows the language (or better yet a programmer familiar with a similar framework but not this one) understands it.
4) Its easy and quick to make changes as requirements change - that means GUI tools for GUI development (What ever happened to RAD tools being the norm in the industry!? It can take a week to make significant changes to a web page in Struts or Spring MVC, where it use to take about a day to do it for the clients developed with the RAD tools of the late 90s!)
5) It fits in well with the rest of the system. A module that works beautifully in isolation but doesn't fit in with the system can ruin the system.
All the rest is just a bunch of consultants trying to bilk you for cash.
Yes patterns can help, but they can also hurt.
Yes externalizing code into config files can make a system more flexible (but you'll pay for it in readability and tracability/debugability).
Yes aspects of the agile methodology - continual integration and test driven coding - can help but they're not the only way and there's a cost associated.
Yes Object oriented code offers things that procedural does not, but again there's a cost and your developers better understand the language constructs.
You need to look at each of the above as tools in your arsenal, not religious doctrine.
Note that my recent experience is with Java/J2EE so that's where my examples come from but I've worked on dozens of languages and frameworks.
Actually it reads more like "Lookie I've brainwashed my chickie and can get her to do the work when she asks for help". It also comes across as condescending. Of course a woman with sufficient interest and motivation could put together a PC, or at least many/most women will be able to. To me that's a given. Having a vagina doesn't suddenly mean you're incapable of putting together what essentially is a technical jigsaw puzzle.
/. perhaps I should get pics of my fiancee doing advanced edits in photo editing software and put together a "story". ;-)
Hell I'm more interested in software so while I've fiddled with adding components, I've never built a PC from scratch - I get someone who does it for a living to do it for me when I need one put together.
Aw hell if this all it takes to get onto
Because that doesn't sound like a sitcom or anything...
You're forgetting pwn-ography never makes it to mainstream tele.
Actually you have a point and I don't think you should be modded funny.
However I also think it's flawed to try to point at a single cause for industrialization. I think a whole set of inter-related changes led to the boom in the 1800s. Part of it was better medicine and living conditions. Part of it was increased trade allowing things such as tea and coffee (and many other useful things!) to become more widely available. Part of it was the culture at the time that supported the ideal of working long hours to avoid poverty. Part of it was advances in science and engineering. All these things mingle.
For example science feeds into medical science, which is sustained by trade of knowledge and materials, which also helps engineering. etc. etc.
After all, if you don't have cancer, why should you pay extra for the people who do?
So that you don't have people desperate for cash because they're dying, and who have nothing to lose because they're dying running around. Do you have any idea how dangerous someone who knows that there is no legal way to get cash for their terminal disease (or worse their children's) would be?
Hillary might use your tax money to do the wrong sort of good. Bush is using it to do harm.
If the end result is the same who cares? There's no practical difference between allowing someone stupid without intent to do damage vs someone evil with intent. The results is still the same damage.
Find somewhere else to work. Your skill is wasted on those morons. Not every workplace is so anti-female.
Studies show that men are more linear thinkers while women tend to think in circular patterns. Men are more big-picture thinkers, women pay more attention to detail.
I can accept that men and women think differently. But big picture vs more detail is a personal trait. I am more big picture myself but you go out to your local scale modellers club - whether they model realistic trains, planes, war machines or automobiles and tell me they aren't details people (and yet there's a hobby few women take up or enjoy).
I'll let you in on something else. When women are truely interested in doing something and find it male dominated, they tend to form their own clubs that are female friendly (and sometimes ones that exclude men). It's only when this isn't possible (eg. legislation empowers a professional body to license them) that this doesn't work. That isn't the case in IT.
My experience has been that when women actually want to work in IT they're excellent at it and often outdo the guys. My experience is also that this is painfully rare and most women have no interest in technology and gadgetry.
I can't believe anyone would dismiss MAD and the prolific network of nuclear weapons that it comprises as something was "never going to end it all". Call me a pessemist but we possess enough technological prowess now that I believe ANY misuse has the potential to kill us. The key differences between MAD and global warming is the pace at which catastrophic change occurs, and possibly our ability to recover in the long term.