If Intel would agree to lay aside their patents and other government-granted monopolies, perhaps it would be more level, rather than being a black hole that consumes all competitors.
SWT exists because AWT and Swing didn't meet the needs of the project. If Sun had been sensible with Swing, it could have produced >something responsive and useful like SWT.
Exactly. More particularly, if Java were open, SWT or something better would ship with most JVMs.
IF SWT were part of the Java runtime, would you make the same point?
Let''s see... If Java didn't generally suck as shipped and limited by Sun, would I make the same point that it sucked as a result of no one who cared about improving it being empowered to do so? Probably not.
All GUI features have to hook into the OSes graphics library at some point - making them native.
Third party native hooks versus built-in hooks - a bit of a fine line there. Especially since SWT runs on most platforms, and platforms that aren't supported could be ported since SWT is OSS.
Exactly the point. Sun implementations suck, Even limited OSS replacements available for parts such as the UI suck less. The more open Sun were to more OSS improvements that could be shipped with significant JVMs, the less it would suck. While IBM can ship this sort of modification with a JVM, even they are restricted and most potential contributors could not because, again, it is not open and Sun goes to great lengths to keep it closed.
You made the case for the opposition. Now cite a product that runs in pure Sun Java and can be redistributed as a simple class library. Anyone can make a native entry point allowing better native implementations to be invoked by Java, but then most of what is claimed about Sun Java becomes false.
It was on-topic, and if you had something to say, you had the opportunity to do so. Instead you moderated overrated even though it had not previously been moderated at all. This type of behavior makes Slashdot truly suck.
The whole premise of why use freenet seems to be that the content you are communicating is illegal somewhere. The user makes the choice which country's laws he wants to circumvent.
It is illegal to publish, in the USA, for example, the purely-political works of an Iranian Nobel Peace Prize winner, which ban is just as unjustified as Chinese or Iranian censorships, and things keep getting worse here.
Censorship is government-sanctioned far more often than government-opposed. Freenent and so on exist to avoid censorship even if the uses happen to be legal in some countries. Censorship is also increasingly a function of DMCA, etc. Thus it is criminal to write software which promotes free speech?
The parent said when all they download is a.class file?
May as well download IBM's JVM or Microsoft's to get reasonable native widgets. With Sun's campaign against native libraries, they should have supplied something themselves and not killed off all the competing libraries, each of which worked better than theirs.
This doesn't really matter to Java detractors. IT types, usually not programmers, will bring up the same old tired clichés.
Same tired old cliches. I can tell you first hand that lots of major developers of Java and early advocates have been turned off directly by issues that could have been addressed by open sourcing it. But that won't stop you from your tired cliches that it doesn't matter, just because you don't want it to matter.
I was developing major applications with it before it reached 1.0, and still work with it quite a bit, but it becomes more and more irrelevant despite my best work because Sun wills it to be irrelevant. Even as a major early licensee of Java, basic problems were not considered important enough for Sun to solve, and it hasn't changed much.
Somewhere around the year 2000 Java became uncool especially with younger programmers. I guess because it became an institution taught in high schools everywhere. Maybe programmers feel Java is rammed down their throats so they champion less established languages even something by Microsoft.
Again, strong on cliche, very weak on technical understanding or demographic fact, but at least you contradict your prior nonsense that it is not programmers turning away.
Java really is the best thing out there for a lot of things. Sun can give away everything and detractors will be like: "OK but what about your first born child?"
Go whine somewhere else. You think you should dictate what is useful to us without giving us adequate control to meet our needs? We will continue to use Java less and less as other tools continue come forward that are more responsive to our needs. The stuff we run today in Java doesn't benefit from the JVM and will be ported away as performance becomes more important and other features we need to build in are still not available in Java, since it is not open.
The whole attitude that somehow open source is wanting more from Sun than it would contribute back is ignorant, uninformed, short sighted, etc. Sun and their apologists should get a clue. Open source would make it responsive to a much wider range of developers and would produce developments Sun was too blind to pursue or pursued way too late and too little. Any harm has already been done to a great extent by Sun's pig-headedness. They should go off in a corner and use it by themselves if they don't want to open it up.
Waiting for Java has become a dead issue. No one expects Sun to get a clue, so why are you still whining that some in the past thought they might.
Why would I use that data, when attempting to make a derived product? A real service would be at least to keep seperate what could be reused from what cannot. Why would I mix in proprietary data when it makes the whole product unusable to me. As a person involved in open source, I would think you would understand that. This is not the only project where Google "innovates" by making a totally proprietary product from data which should have been mostly open.
It is ludicrous to claim that Google invested that much in the original content, since everyone just gets it from US Geological Survey.
So, go to the National Atlas and download and use to your heart's content. If that is not good enough, then go download all the data you can imagine. Still not enough, you can access all the layers via web services that comply with specifications published by the Open Geospatial Consortium at run time from your own web pages.
Now, write your congressmen and tell them how you appreciate that they made all this available to you, the citizen, for free, instead of spending all that tax money only to add a fee that makes it prohibitive for all but corporations who can be gatekeepers to keep you out. And hope that this doesn't become another casulty of Iraq budgets.
While you are at it, start a USGS support mailing list and an open source project to keep this sort of alive.
There is little difference in the CSS rendering capabilities of Netscape 7 versus Firefox. IE, on the other hand performs quite miserably. Almost without exception, when I want to use a feature, it works well everywhere (Opera, Mozilla, Netscape, Firefox, Safari are the ones I test against lately) but not IE. And Firefox and Netscape are the same codebases, although it does take significantly longer for fixes and good features to trickle into Netscape. But to believe IE works better with respect to CSS is silly.
If you're seeking reassurance that some artifact won't be used to sabotage a project, just ring the doorbell and ask. There are much better ways to open a discussion than throwing a brick through the window.
But would it be as much fun?
Seriously, a comment like that deserves a brick through the window. As though they owned this sort of thing.
This incident, alone, will make sure that Borland gets no more of my business, whereas they have repeatedly had my business in the past.
Responding by asking for a nice request, even if it were an appropriate thing to do, can be just like SCO telling all the Linux users that they will sit down and work it out -- it looks great for the court record to have everyone suddenly acknowledging your fraudulent patent. As with others here, I used this sort of exception handling extensively on VAXes in many languages since the early '80s.
As with others, I have been ignoring Borland lately after they screwed up so often with stuff I paid good money for, so now, like SCO, they seem to want to register on the dark side of the register.
Who is there to blame but DEC for believing Microsoft lies rather than innovating on their business model and attitudes and trying to get ahead of the train again.
There were actual signs hanging above engineer's desks "We're DEC and you are not." and the attitude was pervasive.
They were never willing to go with something new that was not thought of, developed, patented, and otherwise controlled by DEC.
Small wonder when they needed an answer, they thought it would be someone like Microsoft.
I spent many years in the depths of DEC hardware and software, but good riddance. They would have become just like Microsoft or worse had they been able, because they were controlling the hardware as well. It is just too bad that no one picked up the Alpha chip or any number of other good technologies that they were somehow unable or unwilling to bring to the masses.
This is about what Digital was doing at this point in their death spiral. The pilot hasn't told the passengers the situation...
When I die, I want to die in my sleep, like my Grandfather did, and not like the 500 screaming passengers on his plane.
There is nothing saying "don't design" in Agile (nor in XP for that matter), just that you should not waste your time on too early designing, and useless generalization.
They try to dictate what is "too early" or "too much" which is different in every case. For someone with no domain experience and little architecture mexperience, it will forever be too early and too much, either to start designing or to start coding. Yet in their book it seems never too early to demand lots of meaningless tests.
The big problem is the lack in these people's minds of the need for some model in the big picture that different parts are conforming to as they interact with each other.
There are two types of bugs, technical failure to follow the model, which is like a typo, fairly easily corrected, and failure of (or failure to have) an abstract model, which gets you into far worse trouble because it means that different parts were built on quite incompatible assumptions. Even for a quite simple application, it is easy for different programmers to make completely different assumptions about what the interaction means. Tests only test points from an infinite set of possibilities, and are likely to not detect this, not to mention that the tests as well might be incoherant if coded by the same person.
A requirement is not the same as a model, and just because everyone has the same set of requirements in front of them or tests (especially written before the implementation) does not mean at all that their parts will interoperate, let alone not fail in subtler combinations.
This is almost too idiotic to respond to, but nowhere does AGILE manifesto mandate (unit) tests.
No, the manifesto is completely vague, able to justify about anything, but still self-contradictory. On the other hand, proponents/extremists are the ones who say all tests have to be written before you write a line of the implementation, as though it were possible. A quick search reveals many articles matching the flawed mind set. Where have you been? Such as:
http://www.builderau.com.au/architect/ood/0,390246 08,39130684,00.htm
And it certainly DOES rely on actual functioning product (aka running code); especially if one needs to choose between phone book sized "specifications" and actual functioning implementation.
Another silly straw man of the Agile community.
A simple specification with some good forethought can tie down a product behavior far better than a million tests, because tests can only handle one set of inputs at a time.
Have you actually even read the Agile manifesto? Go and read it: it has just main 4 bullet points, outlining what all Agile methodologies focus on, and what they consider secondary.
As to conformance to a design, what do you think unit tests are?!?!? And if the two are not the same, what is "testing conformance to a design"?
They test points of conformance, not conformance. Which ones do you want to test? A function typically has a nearly-infinite set of possible inputs. Are you testing a specific implementation or the black-box function it is supposed to serve? If the implementation, then it is really non-Agile, because when the implementation significantly changes, the test cases likely to break also significantly change (and they were all written before even the first implementation?). If the black box implementation, then you have no justifiable reason to choose one set of inputs over another out of the infinite set of possibilities.
Or perhaps it's more likely you misunderstand what unit tests actually are. They are NOT written by outsiders (QA etc), but by the developer who writes the implementation, based on design of some kind (whether formal or informal), and as such actually not only tests conformance, but also improves understanding of the design.
I'd say it is more likely that you misunderstand. The claims by extremists that all unit tests must be written before the function is implemented shoots a big hole in that theory (supported in the former randomly-selected reference and elsewhere).
Oh, and assertions actually are generally used to verify that implementor correctly understands how the implementation works (esp. when integrating someone else's code). They can help, especially with legacy code. But unit tests have wider scope, and in general are more useful... as well as more work.
I'd say they have more work to verify an infinite set of inputs for each function.
Agile methods are the ones to claim omniscience, despite many straw men they build to the contrary.
They do not rely on running code. They rely on tests, which are inherently incomplete and according to the doctrine should be created based upon a test-writer's attempt to predict where the implementation will break before the implementation has even been written.
Conformance to a design constitutes far more value than conformance to an arbitrary set of tests. Tests are inherently arbitrary and incomplete. They are often useful, but only with respect to how accurate you are in predicting where the implementation will break. Assertions might be said to be far more useful, because at least they focus on the actual use cases.
While testing can be a quite useful tool, it is not the only available one, and it should be followed only where it makes sense, not just to be following your methodology. Good coding can be done and may be appropriate in some cases with no tests at all. Even extremists have to admit that where to stop testing is arbitrary because you are never done writing tests. You do what is appropriate. Writing tests for a part that is unlikely to break is a waste of limited resources and ultimately at some level impossible. Likewise, testing an infinite set of inputs may be much more trouble than its worth, and the obvious cases may be the uninteresting ones from a testing standpoint.
The interesting cases become known first after the code is written and the implementation decisions have been made. Tests that test one implementation of a unit well, may completely fail to test another set. In many ways, assertions are far superior to unit tests, because at least then your tests are the real use cases.
Your process strongly conflicts with my experience.
In fact, they are advocated not for their ability to verify requirements, but rather, for their ability make design improvement less risky.
They are certainly advocated as the substitution by those I have encountered: everything driven by tests, tests say you have a requirement, and if you pass all the tests, you have met all the requirements by definition, and they are your design.
Rather, they ask you to abandon the assumption that all forward-looking design is adequate. This faces up to the hard fact that diagrams drawn in a tool rarely resemble the actual implementation in code, even if the implementation stays true to the spirit of these drawings.
I cannot abandon it, because I never had it, nor any programmer I ever met.
The only place I have encountered the omniscience claim has been in the straw men of XP advocates trying to make their case against reasonable, solid design. To the contrary, I design for the big picture and for anticipated flexibility requirements as long as it makes the design simpler, and if it takes a little bit or even significantly longer, I can usually make it up on the simpler implementation already in the first implementation cycle. Again, XP extremists redefine "big picture" as some sort of omniscient view to be avoided at all costs instead of an abstract view including possible future requirements, not to solve, but to consider. They claim that lots of refactoring is always possible and the most-desirable path to get where you are going and I know they are wrong for most situations I care about, because generally if you do not have time or pain tolerance to try to do it with the best foresight you can (the basics), you will never have time to do it over (changing the most-integral structures of the model after everything has grown up around it).
Releasing often and keeping close to your user's requirements is far easier with a good design at the start and along the way, because you don't confront every twist as a complete suprise from left field that violates basic assumptions.
I do not believe your 4% interpretation exhibits a clue about their focus and efforts on software or the value of the software to those purchasing the hardware.
And you are trying to claim that they got by on 3 million in total net sales last year?
I am sure to be modded OT as this whole thread is, but...
The Agile/XP movement is warped at best. Tests are no substitute for good design and they cannot prove any useful level conformance to a design (except in an extremely trivial application). Tests are useful in many cases, unless they are used to rationalize bad practices based on false notions.
And the more extremists you have trying to force it to be so, the worse the XP/Agile movement is percieved. Sure, they picked up on parts of a number of good practices that good programmers already followed, but when will they stop twisting them and advocating that experienced programmers abandon principles of adequate forward-looking design and methodology and follow the way which is what they ultimately believe to be The Only Right Extreme Way.
They resemble the pointy-haired managers who would like to think they can substitute their process for masterful programming and design.
I was attracted to XP by their advocacy of some of the more-reasonable principles until the fanatics showed why it was really called extreme programming. They need apologists to start really apologizing.
I believe, based upon work with attorneys, that even with a judge, there is a chance the judge will do very stupid things, and every time you put out an issue like this, no matter how insane, you are rolling the dice. It just depends on how the judge interprets the various factors and they are not guaranteed to follow a normative interpretation even if they are supposed to. I hope and would like to believe the chances are small and the analyses presented seem reasonable, but saying there is no chance would require quite a burden of proof. You don't even know if there might be money changing hands behind the bench, criminal relationships, etc. There is a huge distance between unlikely and impossible.
In order to argue with me, you would have to take the opposite position, that somehow jury opinions do establish precedent. You and several after you decided to assume my own clearly-stated position to argue with me. Whatever.
My post stated exactly the opposite, that a trial by jury does not establish legal precedence. But go ahead, be a blathering idiot. That is what AC postings are often for.
Slashdot Mirror
If Intel would agree to lay aside their patents and other government-granted monopolies, perhaps it would be more level, rather than being a black hole that consumes all competitors.
SWT exists because AWT and Swing didn't meet the needs of the project. If Sun had been sensible with Swing, it could have produced >something responsive and useful like SWT.
Exactly. More particularly, if Java were open, SWT or something better would ship with most JVMs.
IF SWT were part of the Java runtime, would you make the same point?
Let''s see... If Java didn't generally suck as shipped and limited by Sun, would I make the same point that it sucked as a result of no one who cared about improving it being empowered to do so? Probably not.
All GUI features have to hook into the OSes graphics library at some point - making them native. Third party native hooks versus built-in hooks - a bit of a fine line there. Especially since SWT runs on most platforms, and platforms that aren't supported could be ported since SWT is OSS.
Exactly the point. Sun implementations suck, Even limited OSS replacements available for parts such as the UI suck less. The more open Sun were to more OSS improvements that could be shipped with significant JVMs, the less it would suck. While IBM can ship this sort of modification with a JVM, even they are restricted and most potential contributors could not because, again, it is not open and Sun goes to great lengths to keep it closed.
You made the case for the opposition. Now cite a product that runs in pure Sun Java and can be redistributed as a simple class library. Anyone can make a native entry point allowing better native implementations to be invoked by Java, but then most of what is claimed about Sun Java becomes false.
It was on-topic, and if you had something to say, you had the opportunity to do so. Instead you moderated overrated even though it had not previously been moderated at all. This type of behavior makes Slashdot truly suck.
The whole premise of why use freenet seems to be that the content you are communicating is illegal somewhere. The user makes the choice which country's laws he wants to circumvent.
It is illegal to publish, in the USA, for example, the purely-political works of an Iranian Nobel Peace Prize winner, which ban is just as unjustified as Chinese or Iranian censorships, and things keep getting worse here.
Censorship is government-sanctioned far more often than government-opposed. Freenent and so on exist to avoid censorship even if the uses happen to be legal in some countries. Censorship is also increasingly a function of DMCA, etc. Thus it is criminal to write software which promotes free speech?
May as well download IBM's JVM or Microsoft's to get reasonable native widgets. With Sun's campaign against native libraries, they should have supplied something themselves and not killed off all the competing libraries, each of which worked better than theirs.
This doesn't really matter to Java detractors. IT types, usually not programmers, will bring up the same old tired clichés.
Same tired old cliches. I can tell you first hand that lots of major developers of Java and early advocates have been turned off directly by issues that could have been addressed by open sourcing it. But that won't stop you from your tired cliches that it doesn't matter, just because you don't want it to matter.
I was developing major applications with it before it reached 1.0, and still work with it quite a bit, but it becomes more and more irrelevant despite my best work because Sun wills it to be irrelevant. Even as a major early licensee of Java, basic problems were not considered important enough for Sun to solve, and it hasn't changed much.
Somewhere around the year 2000 Java became uncool especially with younger programmers. I guess because it became an institution taught in high schools everywhere. Maybe programmers feel Java is rammed down their throats so they champion less established languages even something by Microsoft.
Again, strong on cliche, very weak on technical understanding or demographic fact, but at least you contradict your prior nonsense that it is not programmers turning away.
Java really is the best thing out there for a lot of things. Sun can give away everything and detractors will be like: "OK but what about your first born child?"
Go whine somewhere else. You think you should dictate what is useful to us without giving us adequate control to meet our needs? We will continue to use Java less and less as other tools continue come forward that are more responsive to our needs. The stuff we run today in Java doesn't benefit from the JVM and will be ported away as performance becomes more important and other features we need to build in are still not available in Java, since it is not open.
The whole attitude that somehow open source is wanting more from Sun than it would contribute back is ignorant, uninformed, short sighted, etc. Sun and their apologists should get a clue. Open source would make it responsive to a much wider range of developers and would produce developments Sun was too blind to pursue or pursued way too late and too little. Any harm has already been done to a great extent by Sun's pig-headedness. They should go off in a corner and use it by themselves if they don't want to open it up.
Waiting for Java has become a dead issue. No one expects Sun to get a clue, so why are you still whining that some in the past thought they might.
Why would I use that data, when attempting to make a derived product? A real service would be at least to keep seperate what could be reused from what cannot. Why would I mix in proprietary data when it makes the whole product unusable to me. As a person involved in open source, I would think you would understand that. This is not the only project where Google "innovates" by making a totally proprietary product from data which should have been mostly open.
It is ludicrous to claim that Google invested that much in the original content, since everyone just gets it from US Geological Survey.
So, go to the National Atlas and download and use to your heart's content. If that is not good enough, then go download all the data you can imagine. Still not enough, you can access all the layers via web services that comply with specifications published by the Open Geospatial Consortium at run time from your own web pages.
Now, write your congressmen and tell them how you appreciate that they made all this available to you, the citizen, for free, instead of spending all that tax money only to add a fee that makes it prohibitive for all but corporations who can be gatekeepers to keep you out. And hope that this doesn't become another casulty of Iraq budgets.
While you are at it, start a USGS support mailing list and an open source project to keep this sort of alive.
There is little difference in the CSS rendering capabilities of Netscape 7 versus Firefox. IE, on the other hand performs quite miserably. Almost without exception, when I want to use a feature, it works well everywhere (Opera, Mozilla, Netscape, Firefox, Safari are the ones I test against lately) but not IE. And Firefox and Netscape are the same codebases, although it does take significantly longer for fixes and good features to trickle into Netscape. But to believe IE works better with respect to CSS is silly.
Anyway, the point is that Borland had a patentable idea, and Wine simply wants to use it, even though they could do it in other ways.
How does their attempt to steal the obvious designs of others qualify as innovation. Only Microsoft is allowed to claim that.
They are liars and frauds.
If you're seeking reassurance that some artifact won't be used to sabotage a project, just ring the doorbell and ask. There are much better ways to open a discussion than throwing a brick through the window.
But would it be as much fun?
Seriously, a comment like that deserves a brick through the window. As though they owned this sort of thing.
This incident, alone, will make sure that Borland gets no more of my business, whereas they have repeatedly had my business in the past.
Responding by asking for a nice request, even if it were an appropriate thing to do, can be just like SCO telling all the Linux users that they will sit down and work it out -- it looks great for the court record to have everyone suddenly acknowledging your fraudulent patent. As with others here, I used this sort of exception handling extensively on VAXes in many languages since the early '80s.
As with others, I have been ignoring Borland lately after they screwed up so often with stuff I paid good money for, so now, like SCO, they seem to want to register on the dark side of the register.
I find your stereotype wrong.
Who is there to blame but DEC for believing Microsoft lies rather than innovating on their business model and attitudes and trying to get ahead of the train again.
There were actual signs hanging above engineer's desks "We're DEC and you are not." and the attitude was pervasive.
They were never willing to go with something new that was not thought of, developed, patented, and otherwise controlled by DEC.
Small wonder when they needed an answer, they thought it would be someone like Microsoft.
I spent many years in the depths of DEC hardware and software, but good riddance. They would have become just like Microsoft or worse had they been able, because they were controlling the hardware as well. It is just too bad that no one picked up the Alpha chip or any number of other good technologies that they were somehow unable or unwilling to bring to the masses.
This is about what Digital was doing at this point in their death spiral. The pilot hasn't told the passengers the situation... When I die, I want to die in my sleep, like my Grandfather did, and not like the 500 screaming passengers on his plane.
There is nothing saying "don't design" in Agile (nor in XP for that matter), just that you should not waste your time on too early designing, and useless generalization.
They try to dictate what is "too early" or "too much" which is different in every case. For someone with no domain experience and little architecture mexperience, it will forever be too early and too much, either to start designing or to start coding. Yet in their book it seems never too early to demand lots of meaningless tests.
The big problem is the lack in these people's minds of the need for some model in the big picture that different parts are conforming to as they interact with each other.
There are two types of bugs, technical failure to follow the model, which is like a typo, fairly easily corrected, and failure of (or failure to have) an abstract model, which gets you into far worse trouble because it means that different parts were built on quite incompatible assumptions. Even for a quite simple application, it is easy for different programmers to make completely different assumptions about what the interaction means. Tests only test points from an infinite set of possibilities, and are likely to not detect this, not to mention that the tests as well might be incoherant if coded by the same person.
A requirement is not the same as a model, and just because everyone has the same set of requirements in front of them or tests (especially written before the implementation) does not mean at all that their parts will interoperate, let alone not fail in subtler combinations.
This is almost too idiotic to respond to, but nowhere does AGILE manifesto mandate (unit) tests.
No, the manifesto is completely vague, able to justify about anything, but still self-contradictory. On the other hand, proponents/extremists are the ones who say all tests have to be written before you write a line of the implementation, as though it were possible. A quick search reveals many articles matching the flawed mind set. Where have you been? Such as: http://www.builderau.com.au/architect/ood/0,390246 08,39130684,00.htm
And it certainly DOES rely on actual functioning product (aka running code); especially if one needs to choose between phone book sized "specifications" and actual functioning implementation.
Another silly straw man of the Agile community.
A simple specification with some good forethought can tie down a product behavior far better than a million tests, because tests can only handle one set of inputs at a time.
Have you actually even read the Agile manifesto? Go and read it: it has just main 4 bullet points, outlining what all Agile methodologies focus on, and what they consider secondary. As to conformance to a design, what do you think unit tests are?!?!? And if the two are not the same, what is "testing conformance to a design"?
They test points of conformance, not conformance. Which ones do you want to test? A function typically has a nearly-infinite set of possible inputs. Are you testing a specific implementation or the black-box function it is supposed to serve? If the implementation, then it is really non-Agile, because when the implementation significantly changes, the test cases likely to break also significantly change (and they were all written before even the first implementation?). If the black box implementation, then you have no justifiable reason to choose one set of inputs over another out of the infinite set of possibilities.
Or perhaps it's more likely you misunderstand what unit tests actually are. They are NOT written by outsiders (QA etc), but by the developer who writes the implementation, based on design of some kind (whether formal or informal), and as such actually not only tests conformance, but also improves understanding of the design.
I'd say it is more likely that you misunderstand. The claims by extremists that all unit tests must be written before the function is implemented shoots a big hole in that theory (supported in the former randomly-selected reference and elsewhere).
Oh, and assertions actually are generally used to verify that implementor correctly understands how the implementation works (esp. when integrating someone else's code). They can help, especially with legacy code. But unit tests have wider scope, and in general are more useful... as well as more work.
I'd say they have more work to verify an infinite set of inputs for each function.
Agile methods are the ones to claim omniscience, despite many straw men they build to the contrary.
They do not rely on running code. They rely on tests, which are inherently incomplete and according to the doctrine should be created based upon a test-writer's attempt to predict where the implementation will break before the implementation has even been written.
Conformance to a design constitutes far more value than conformance to an arbitrary set of tests. Tests are inherently arbitrary and incomplete. They are often useful, but only with respect to how accurate you are in predicting where the implementation will break. Assertions might be said to be far more useful, because at least they focus on the actual use cases.
While testing can be a quite useful tool, it is not the only available one, and it should be followed only where it makes sense, not just to be following your methodology. Good coding can be done and may be appropriate in some cases with no tests at all. Even extremists have to admit that where to stop testing is arbitrary because you are never done writing tests. You do what is appropriate. Writing tests for a part that is unlikely to break is a waste of limited resources and ultimately at some level impossible. Likewise, testing an infinite set of inputs may be much more trouble than its worth, and the obvious cases may be the uninteresting ones from a testing standpoint.
The interesting cases become known first after the code is written and the implementation decisions have been made. Tests that test one implementation of a unit well, may completely fail to test another set. In many ways, assertions are far superior to unit tests, because at least then your tests are the real use cases.
Your process strongly conflicts with my experience.
In fact, they are advocated not for their ability to verify requirements, but rather, for their ability make design improvement less risky.
They are certainly advocated as the substitution by those I have encountered: everything driven by tests, tests say you have a requirement, and if you pass all the tests, you have met all the requirements by definition, and they are your design.
Rather, they ask you to abandon the assumption that all forward-looking design is adequate. This faces up to the hard fact that diagrams drawn in a tool rarely resemble the actual implementation in code, even if the implementation stays true to the spirit of these drawings.
I cannot abandon it, because I never had it, nor any programmer I ever met.
The only place I have encountered the omniscience claim has been in the straw men of XP advocates trying to make their case against reasonable, solid design. To the contrary, I design for the big picture and for anticipated flexibility requirements as long as it makes the design simpler, and if it takes a little bit or even significantly longer, I can usually make it up on the simpler implementation already in the first implementation cycle. Again, XP extremists redefine "big picture" as some sort of omniscient view to be avoided at all costs instead of an abstract view including possible future requirements, not to solve, but to consider. They claim that lots of refactoring is always possible and the most-desirable path to get where you are going and I know they are wrong for most situations I care about, because generally if you do not have time or pain tolerance to try to do it with the best foresight you can (the basics), you will never have time to do it over (changing the most-integral structures of the model after everything has grown up around it).
Releasing often and keeping close to your user's requirements is far easier with a good design at the start and along the way, because you don't confront every twist as a complete suprise from left field that violates basic assumptions.
and let hardware sell itself, yea, sure.
I do not believe your 4% interpretation exhibits a clue about their focus and efforts on software or the value of the software to those purchasing the hardware.
And you are trying to claim that they got by on 3 million in total net sales last year?
Not likely.
I am sure to be modded OT as this whole thread is, but...
The Agile/XP movement is warped at best. Tests are no substitute for good design and they cannot prove any useful level conformance to a design (except in an extremely trivial application). Tests are useful in many cases, unless they are used to rationalize bad practices based on false notions.
And the more extremists you have trying to force it to be so, the worse the XP/Agile movement is percieved. Sure, they picked up on parts of a number of good practices that good programmers already followed, but when will they stop twisting them and advocating that experienced programmers abandon principles of adequate forward-looking design and methodology and follow the way which is what they ultimately believe to be The Only Right Extreme Way.
They resemble the pointy-haired managers who would like to think they can substitute their process for masterful programming and design.
I was attracted to XP by their advocacy of some of the more-reasonable principles until the fanatics showed why it was really called extreme programming. They need apologists to start really apologizing.
I believe, based upon work with attorneys, that even with a judge, there is a chance the judge will do very stupid things, and every time you put out an issue like this, no matter how insane, you are rolling the dice. It just depends on how the judge interprets the various factors and they are not guaranteed to follow a normative interpretation even if they are supposed to. I hope and would like to believe the chances are small and the analyses presented seem reasonable, but saying there is no chance would require quite a burden of proof. You don't even know if there might be money changing hands behind the bench, criminal relationships, etc. There is a huge distance between unlikely and impossible.
In order to argue with me, you would have to take the opposite position, that somehow jury opinions do establish precedent. You and several after you decided to assume my own clearly-stated position to argue with me. Whatever.
My post stated exactly the opposite, that a trial by jury does not establish legal precedence. But go ahead, be a blathering idiot. That is what AC postings are often for.
The SCO case is by jury.