Consider all the hype last week about the cell processor. Here is a processor in which the CISC optimizing portions have been removed, trusting the compiler to create pre-optimized code. The cell processor will run this code blindingly fast and with no modification. The compiler must be a smart optimizer. IBM, Toshiba and Sony are betting a lot on a smart optimizer. I'm guessing they won't be disappointed.
Further, consider the Parrot system to be used by Perl, Python and Ruby. There's a strong similarity here to the cell system. All three languages are to be compiled to a common register-based representation. That representation is to be optimized by the compiler before execution. They chose this model because w we have decades of research on optimizing code for register based computers (as opposed to Java's stack based computer).
In short, some very large, very important projects already have a lot of faith in these optimizers. They are not going away. I suggest the best approach is to work with them.
So how do you cooperate with your optimizer? Write cleanly and clearly. Don't try to outsmart the optimizer, because if you do so, your code will most likely be slower, not faster. And don't do any work until you need to. Write the project correctly and clearly, then profile. If you need to modify things, then you have a working baseline to compare your optimizations with.
Finally, when you get the faster version, check it in, then refactor the design to something reasonable, rechecking the speed as you do so. Ideally, for a small performance hit, you can end up with fast, efficient and easy to maintain code.
Any C programmer knows this. It is not true in all languages. And symantically, if you are checking to ensure that a pointer is not null, (ptr != NULL) is more correct. (!ptr) uses a quirk of C, that null pointers and the boolean state false have the same internal representation, to affect a comparison.
The Boeing answer is the 7E7 Dreamliner. This is to replace the 767 and compete in the medium haul segment, both over water and over land. The idea is to build a carbon fiber based plane with a large fuel savings. If they pull it off, their planes should be 30% more fuel efficient and have a lower maintanance cost.
Please remember, it is the airline, not the aircraft manufacturer, that installs the seating. Boeing and Airbus have nothing to do with the hideous seating arrangements the airlines inflict on the public.
What I find interesting is how many risk factors are addressable by good modern programming practices. Customer feedback is at the heart of the extreme programming model. Identification and encapsulation of customer requirements is also a major point in XML design practices.
Project complexity is well addressed by refactoring. If refactoring is stressed as a programming activity, the code base improves as time passes, rather than degrades. Good refactoring also heals program structure after yet another round of feature shifting. It also aids starting the project, as developers are free to start with a fairly good structure and rely on refactoring by knowledgeable developers to optimize the program structure as the project moves forward.
Formal project management processes are a dime a dozen, but good UML documentation, updated with each refactor, will go a long way to providing the structure to support any project management process.
Really, between UML design, XP style customer feedback and consistent refactoring, most of these risks are assessed. All of these feed nicely into methodology choice, leaving language and platform choices as the only factors undressed.
Well, that and the true cause of most project failures: incompetence. One factor keenly missing from the list is poor performance of personnel. In my eight years as a professional developer, every one of my failed projects can be traced to idiotic decisions made by people who should not have been given the responsibility for the decisions that were made.
The difficulty here is making absolutely sure the client and the mangement know the difference between a working prototype with canned data and a fully functional application capable of handling real world situations. All to often, I've seen really good prototypes either turn into the actual product, or be the source of unrealistic estimates of project status. (After all, if the demo works, how hard can the rest be?)
I remember reading an article by Joel Spolsky where he advised to deliberately make the UI for demos less than polished. Make it look like something that was knocked together. Make it too pretty and the client will think you're almost done. After all, to the client, the UI is the app. If that looks done, the guts of the thing must be near done as well.
Predictive power of the Big Bang: 1) Ratio of hydrogen to helium 2) Radio of hydrogen and helium to everything else 3) Large scale structure of universe (galaxy clusters) 4) Mass of the Universe
Explanation of the Big Bang: Explains the evolution of the universe from a few Plank times after the event to now. As the theory improves, the window we can see back increases.
Testing the Big Bang: 1) Cosmic Background radiation 2) Ratio of hydrogen to helium 3) Radio of hydrogen and helium to everything else 4) Large scale structure of universe (galaxy clusters) 5) Mass of the Universe
Can our theory explain why the Big Bang occured? No. We lack a good quantum theory of gravity, at the very least. But we can explain everything that happened from roughly 1x10e-50 seconds after the event until now. Plus, we are getting some interesting hints as to the 'why' question from M-Theory.
Look at the DVD Features section of the description:
* The extended versions of all three films boxed in a slipcase * See individual DVDs for complete details * (c)MMIII New Line Productions, Inc. (c)MMIV New Line Home Entertainment, Inc. (tm)Tolkien Enterprises under license to New Line Productions, Inc. All Rights Reserved * Number of discs: 12
I'd say its just a boxed set of the three EE movies. This fits with what PJ has said from the beginning, the EE movies are the last word. There is simply no more useable footage to put in.
Reminds me of a story. A friend of mine once told me about a debate he saw on rec.guns some years back. The topic of burglary had come up, once again, and had gradually shifted to a new question: What is the scariest sound a burglar can hear?
Everyone chimed in with their favorite weapon. Some claimed the sound of a 9mm cocking was the worst. Others argued for the hammer of a revolver. Sill others favored the finality of a pump action shotgun racking a shell. The debate raged on about the relative merits of bolt action rifles snicking closed and automatic weapons being cocked. In the end, though, a winner was declared.
The most frightening sound a burglar can hear is the rumble of a starting chainsaw.
Sadly, this is what currently passes as a debate. I want a real debate. Have the speaker present a topic. Give the candidates 2 minutes to state their side, then let'em at each other.
I want to see the candidates directly question each other. I want to see the press call the candidates on any obvious dissimilation or obstrifucation. I want to see a real, no holds barred debate.
So, has the cost of the war been figured into the price of gas at the pump? What's the payback schedule?
Whether or not you believe oil was a motivating factor for the war, the fact remains that we are now in charge of the second largest oil reserve in the world. We are paying companies like Haliburton to run these production facilities and put the oil on the market. This increases the supply, lowering the per barrel price.
How about the cleanup costs for MTBE? Are those computed into the price at the pump? What about the costs of cleaning up roadside lead left from pre-1970s gasoline? What about the health care costs of the lung damage being caused by ozone damage and soot? Are those factored in?
Having an alternative fuel that makes economic sense will seem impossible until the real costs of gasoline are represented in the price at the pump.
You missed the point. These were not 'robots... that are made to look and act exactly like people'. They were not mechanical creations. They were artificial, true, but they were biological. They were living, breathing, thinking, feeling people we created, then enslaved. And when they fought against their enslavement, they were hunted down and executed.
The point of the film is summed up early on in Deckard's examination of Rachel. If it takes a trained professional over an hour to spot the small emotional responses that differentiate a human from a replicant, is it moral to enslave replicants? If it is so close to human, does it deserve human status?
This is not a noir dressed up in sci-fi clothes. This is a sci-fi flick asking hard questions dressed up in a slinky noir outfit to get your guard down.
Here's my experience with Word internals. Take it for what its worth.
Back in '95 (on Win95 launch day, if you can believe it), I interviewed with Microsoft. I was fresh out of college, had one friend working there and it seemed like a nice place to work.
One of the interviewers and I were talking about my past college projects. In particular, we were discussing a hypertext editor I had written in our large scale programming class.
I had decided to implement my document viewer by allocating a large array, sufficient to hold the entire file to be edited, then reading the file into the array. This let me page around the document very quickly (I had the fastest design in class). Unfortunately, when we were told to add hypertext markup capabilities to these documents, I was stuck. How do I embed tags into an array of characters without reallocating the whole thing?
I decided to use a second data structure, a list of nodes. Each node contained the address in the array of where the hypertext tag began and ended, as well as the address of the jump target. (Yes, I now realize just how stupid the design is.) To save a file, I dumped my node list, the length of the file and then the raw text out into a flat file.
Again, I ended up with a very fast design - got an A for the project and the class.
In the interview, I described it to the interviewer, then pointed out several flaws with my design as well as giving it an overall poor grade on design. In particular, I noted how closely tied the document format is to my internal representation. The interviewer didn't think it was too poor a design at all. In fact, he said that it was more or less how Word 95 operated internally!
By the way, if you have MS Visual Studio, go to the Tools folder and load up the DocFile viewer. Use this to open some Word program. You'll find it is a very standard COM layout, filled with streams and storages. One of the streams will be called "WordDocument". Open it up and see something very similar to what the FAQ describes, as something eerily similar to my hypertext editor file format.
I believe you are incorrect. Both Netscape and Java were deadly competitors to Microsoft and, by their philosophy, nothing was to be spared in crushing these companies.
Netscape presented the vision of making the operating system irrelevant. Let's look at two of the most popular software products of the last few years: Google and Amazon. Yes, these are software products and each is completely platform agnostic. When I use Google or Amazon on Linux running Firefox, I get the exact same user experience as I get on Windows using IE. If this trend had continued, with the browser and its associated control of the user interface firmly in the hands of Netscape, Microsoft's monopoly position as the operating system of choice would have been lost.
Java was a danger due to a similar argument. Windows is popular because the most popular applications run on it. If Java delivered on its promise of platform independence, a whole new class of killer applications could have arose that were independant of the operating system. Microsoft would then no longer be the operating system of choice. Worse, it would not be the choice for the developers making new killer apps.
Killing Netscape and Java were not paranoid manoevers, they were carefully considered and rational defenses of one of Microsoft's two core strengths, the Operating System. Combined with the other strength: Office, Microsoft presents a huge barrier to entry for anyone attempting to wrest monopoly control over desktop computers from Microsoft.
The problem for Microsoft is they took out the companies, not the ideas. By the time they noticed, the idea of a universal browser was too well entrenched to go away. They have not yet succeeded in converting the Internet to a Microsoft only product (despite the best efforts of ActiveX and IIS).
Building a better Java is not an answer. At some point, the competitors would catch up to a standard such as a language, then how could Microsoft compete? Add features? To Sun's language?
And what happens when someone reimplements 80% of Office in Java? And suppose this new version runs just as nicely on Windows as, say, Mac? What's to keep people on Windows then?
No, these companies had to die. Nothing else would defend Microsoft's monopoly. That they attacked these companies is unfortunate, but part of our system of business. That they did so by exploiting their monopoly position is illegal and should have got them more severly punished.
The point of the article is that Microsoft has abandon its longstanding practice of supporting backwards compatability..Net renders com programming obsolete. (Sure, you can mix the two, but try hiring a developer who knows the ins and outs of class factory instanciation. There aren't many.) And before everything could fully convert to.net, we get Avalon, which partially obsoletes.net.
It appears Microsoft is trying to protect their desktop monopoly with further developer lock-in. Mono is trying to prevent this, but eventually, for this strategy to work, Microsoft is going to have to have some portion of their system lock-in developers.
Joel makes the point that much of the cutting edge of application development is taking place not on desktop systems, but web enabled servers. Gmail is a perfect example, but I'm sure we can all think of some others. More and more, hot new software is not being sold as shrink-wrapped products with a Windows approved logo, but being deployed as a web service with some other revenue model (sales or ads, usually).
And, of course, gmail runs just as well on a mac, linux or windows box.
But html cannot be used for everything. I/O sucks, forms are very limited in data validation, transactions are stateless, etc. What I see this as addressing is the beginning of a new, expanded API from which Microsoft's biggest competitors can continue to draw developer mindshare away from Win32 applications.
This is in reaction to Microsoft's continued revision of their API set to make development easier. Consider that.net's managed code makes Win32 programming much easier and secure - no buffer overruns, no memory leaks, etc. All this with speeds close enough to Win32 and C as not to really matter.
This is a preemptive move on the part of the web developers. If a new, open standard can be developed that allows most business applications to move to an intranet model, they can continue the brain drain from Windows. This will lead to more and more killer apps appearing on systems other than Windows. Killer apps that run on any system. This is what Microsoft fears.
Of course, this has all been tried before. Netscape once planned to crush Microsoft in exactly this format. This was the heart of why the first browser war was fought. Netscape failed because they were offering one vendor's lock-in for another.
The second browser war is being fought for exactly the same reason. This time, Netscape's side has added a new twist to their main weapon - open source. If they abandon lock-in, they may be able to strip off enough mindshare to stagnate Microsoft. If so, then the operating system is no longer an asset. If the ability to use the newest, hottest software on the planet is not the correct operating system, but a standars compatable browser, Microsoft looses.
That, more than desktop widgets, is what is happening here.
This problem was compounded by an artificial limiter on backwards compatablility. Namely, the fact that most buisnesses replaced their desktop computers every two to four years. Bundling deals meant those new computers came with the new shrinkwrapped products. Curiously, many of these newer products defaulted to file formats that older versions couldn't read.
As more machines were replaced, the business began to get in the uncomfortable position of supporting two formats, the old an the new. When it reached the breaking point, an order would be given to convert.
However, while computers continue to get faster at about the same pace as always, software has fallen behind. Developers may crave more horsepower, but just what is it about word processing that demands a 2 GHz processor? Couple this with the number of machines replaced to prepare for y2k and you have the current weak desktop computer market.
Without new hardware coming in the doors regularly, older machines, and their software packages, are suddenly lasting longer. This makes it much harder for Microsoft to force upgrades to a new version.
If I read the situation correctly, Microsoft is toying with a simultaneous conversion to the service model with a forced upgrade due to new APIs. After all, if Windows 2K doesn't suppor the latest.foo framework that you must have to run Microsoft Bar(tm), you'll just have to upgrade, won't you?
We use bubble ballots out here in Arizona and I wholeheartedly agree. This is definitely the way to go.
Each person is handed a ballot. They go to their booth, where the official election literature is posted, along with an ink pen. Fill in the bubble by your candidate's name. Couldn't be simpler.
Next, you take your completed ballot up to the machine. You place it face down in the scanner and it sucks it in. If the ballot is valid, the light turns green, your ballot is dropped in the ballot box and you get the little sticker.
This has the speed of computer scored elections plus the paper trail of ballots for double checking. Plus, if you fill out a ballot incorrectly (check two people in a race where only one is permitted or something) the ballot is spat back. The election official can then help you. This should eliminate most problems with incorrectly filled-out ballots.
The weak point in the system is the programming of the computer scoring. Random spot checks comparing paper ballots to machine talleys could easily be used to ensure correct behavior.
Proven reliable technology. Course, we've got to dump it for touch screens with no software audits or paper trails.
The French did not plan a stupid defense in WWII. They planned a superb, WWI style defense. The problem is the Germans mounted a WWII blitzkrieg style attack, an attack that had been invented by the Germans just a few years previously.
The French were using tanks in an infantry support roll. The total number of French tanks was about equal to the number of German tanks, but spread across the entire defensive line in groups of one or two per mile. The Germans concentrated their entire tank force into one area and smashed through. Once the line was broken, they were able to attack the rest of the line from the rear.
Or, in terms better understood by the Slashdot community, the French bunker line was 0\/\/n3z by a Zerg rush early in the game.
MSDN's search engine is so abysmally bad, I dropped it years ago and now just use Google. For example "CRegKey example" gives a link into the MSDN documentation, plus links to several examples on usage. The same search on MSN's search does not show the MSDN page as the first link and does not have any really good examples on the front page.
Sad. They can't even search their own documentation effectively.
Slashdot Mirror
Wasted? Not at all! What do you think we'll be dining on at the next Society of International Paleontologists meeting?
Consider all the hype last week about the cell processor. Here is a processor in which the CISC optimizing portions have been removed, trusting the compiler to create pre-optimized code. The cell processor will run this code blindingly fast and with no modification. The compiler must be a smart optimizer. IBM, Toshiba and Sony are betting a lot on a smart optimizer. I'm guessing they won't be disappointed.
Further, consider the Parrot system to be used by Perl, Python and Ruby. There's a strong similarity here to the cell system. All three languages are to be compiled to a common register-based representation. That representation is to be optimized by the compiler before execution. They chose this model because w we have decades of research on optimizing code for register based computers (as opposed to Java's stack based computer).
In short, some very large, very important projects already have a lot of faith in these optimizers. They are not going away. I suggest the best approach is to work with them.
So how do you cooperate with your optimizer? Write cleanly and clearly. Don't try to outsmart the optimizer, because if you do so, your code will most likely be slower, not faster. And don't do any work until you need to. Write the project correctly and clearly, then profile. If you need to modify things, then you have a working baseline to compare your optimizations with.
Finally, when you get the faster version, check it in, then refactor the design to something reasonable, rechecking the speed as you do so. Ideally, for a small performance hit, you can end up with fast, efficient and easy to maintain code.
Any C programmer knows this. It is not true in all languages. And symantically, if you are checking to ensure that a pointer is not null, (ptr != NULL) is more correct. (!ptr) uses a quirk of C, that null pointers and the boolean state false have the same internal representation, to affect a comparison.
I assume you mean all this as a compliment.
The Boeing answer is the 7E7 Dreamliner. This is to replace the 767 and compete in the medium haul segment, both over water and over land. The idea is to build a carbon fiber based plane with a large fuel savings. If they pull it off, their planes should be 30% more fuel efficient and have a lower maintanance cost.
Please remember, it is the airline, not the aircraft manufacturer, that installs the seating. Boeing and Airbus have nothing to do with the hideous seating arrangements the airlines inflict on the public.
What I find interesting is how many risk factors are addressable by good modern programming practices. Customer feedback is at the heart of the extreme programming model. Identification and encapsulation of customer requirements is also a major point in XML design practices.
Project complexity is well addressed by refactoring. If refactoring is stressed as a programming activity, the code base improves as time passes, rather than degrades. Good refactoring also heals program structure after yet another round of feature shifting. It also aids starting the project, as developers are free to start with a fairly good structure and rely on refactoring by knowledgeable developers to optimize the program structure as the project moves forward.
Formal project management processes are a dime a dozen, but good UML documentation, updated with each refactor, will go a long way to providing the structure to support any project management process.
Really, between UML design, XP style customer feedback and consistent refactoring, most of these risks are assessed. All of these feed nicely into methodology choice, leaving language and platform choices as the only factors undressed.
Well, that and the true cause of most project failures: incompetence. One factor keenly missing from the list is poor performance of personnel. In my eight years as a professional developer, every one of my failed projects can be traced to idiotic decisions made by people who should not have been given the responsibility for the decisions that were made.
The difficulty here is making absolutely sure the client and the mangement know the difference between a working prototype with canned data and a fully functional application capable of handling real world situations. All to often, I've seen really good prototypes either turn into the actual product, or be the source of unrealistic estimates of project status. (After all, if the demo works, how hard can the rest be?)
I remember reading an article by Joel Spolsky where he advised to deliberately make the UI for demos less than polished. Make it look like something that was knocked together. Make it too pretty and the client will think you're almost done. After all, to the client, the UI is the app. If that looks done, the guts of the thing must be near done as well.
Garbage.
Predictive power of the Big Bang:
1) Ratio of hydrogen to helium
2) Radio of hydrogen and helium to everything else
3) Large scale structure of universe (galaxy clusters)
4) Mass of the Universe
Explanation of the Big Bang:
Explains the evolution of the universe from a few Plank times after the event to now. As the theory improves, the window we can see back increases.
Testing the Big Bang:
1) Cosmic Background radiation
2) Ratio of hydrogen to helium
3) Radio of hydrogen and helium to everything else
4) Large scale structure of universe (galaxy clusters)
5) Mass of the Universe
Can our theory explain why the Big Bang occured? No. We lack a good quantum theory of gravity, at the very least. But we can explain everything that happened from roughly 1x10e-50 seconds after the event until now. Plus, we are getting some interesting hints as to the 'why' question from M-Theory.
Look at the DVD Features section of the description:
* The extended versions of all three films boxed in a slipcase
* See individual DVDs for complete details
* (c)MMIII New Line Productions, Inc. (c)MMIV New Line Home Entertainment, Inc. (tm)Tolkien Enterprises under license to New Line Productions, Inc. All Rights Reserved
* Number of discs: 12
I'd say its just a boxed set of the three EE movies. This fits with what PJ has said from the beginning, the EE movies are the last word. There is simply no more useable footage to put in.
Reminds me of a story. A friend of mine once told me about a debate he saw on rec.guns some years back. The topic of burglary had come up, once again, and had gradually shifted to a new question: What is the scariest sound a burglar can hear?
Everyone chimed in with their favorite weapon. Some claimed the sound of a 9mm cocking was the worst. Others argued for the hammer of a revolver. Sill others favored the finality of a pump action shotgun racking a shell. The debate raged on about the relative merits of bolt action rifles snicking closed and automatic weapons being cocked. In the end, though, a winner was declared.
The most frightening sound a burglar can hear is the rumble of a starting chainsaw.
The irony is in attacking your opponent for failing to vote funds for armor and equipment they should have had before we *chose* to invade.
Sadly, this is what currently passes as a debate. I want a real debate. Have the speaker present a topic. Give the candidates 2 minutes to state their side, then let'em at each other.
I want to see the candidates directly question each other. I want to see the press call the candidates on any obvious dissimilation or obstrifucation. I want to see a real, no holds barred debate.
Well, I can dream, can't I?
500 quattlues on the tall combat vet!
So, has the cost of the war been figured into the price of gas at the pump? What's the payback schedule?
Whether or not you believe oil was a motivating factor for the war, the fact remains that we are now in charge of the second largest oil reserve in the world. We are paying companies like Haliburton to run these production facilities and put the oil on the market. This increases the supply, lowering the per barrel price.
How about the cleanup costs for MTBE? Are those computed into the price at the pump? What about the costs of cleaning up roadside lead left from pre-1970s gasoline? What about the health care costs of the lung damage being caused by ozone damage and soot? Are those factored in?
Having an alternative fuel that makes economic sense will seem impossible until the real costs of gasoline are represented in the price at the pump.
You missed the point. These were not 'robots ... that are made to look and act exactly like people'. They were not mechanical creations. They were artificial, true, but they were biological. They were living, breathing, thinking, feeling people we created, then enslaved. And when they fought against their enslavement, they were hunted down and executed.
The point of the film is summed up early on in Deckard's examination of Rachel. If it takes a trained professional over an hour to spot the small emotional responses that differentiate a human from a replicant, is it moral to enslave replicants? If it is so close to human, does it deserve human status?
This is not a noir dressed up in sci-fi clothes. This is a sci-fi flick asking hard questions dressed up in a slinky noir outfit to get your guard down.
Here's my experience with Word internals. Take it for what its worth.
Back in '95 (on Win95 launch day, if you can believe it), I interviewed with Microsoft. I was fresh out of college, had one friend working there and it seemed like a nice place to work.
One of the interviewers and I were talking about my past college projects. In particular, we were discussing a hypertext editor I had written in our large scale programming class.
I had decided to implement my document viewer by allocating a large array, sufficient to hold the entire file to be edited, then reading the file into the array. This let me page around the document very quickly (I had the fastest design in class). Unfortunately, when we were told to add hypertext markup capabilities to these documents, I was stuck. How do I embed tags into an array of characters without reallocating the whole thing?
I decided to use a second data structure, a list of nodes. Each node contained the address in the array of where the hypertext tag began and ended, as well as the address of the jump target. (Yes, I now realize just how stupid the design is.) To save a file, I dumped my node list, the length of the file and then the raw text out into a flat file.
Again, I ended up with a very fast design - got an A for the project and the class.
In the interview, I described it to the interviewer, then pointed out several flaws with my design as well as giving it an overall poor grade on design. In particular, I noted how closely tied the document format is to my internal representation. The interviewer didn't think it was too poor a design at all. In fact, he said that it was more or less how Word 95 operated internally!
By the way, if you have MS Visual Studio, go to the Tools folder and load up the DocFile viewer. Use this to open some Word program. You'll find it is a very standard COM layout, filled with streams and storages. One of the streams will be called "WordDocument". Open it up and see something very similar to what the FAQ describes, as something eerily similar to my hypertext editor file format.
Try reading the MST3K version. It makes the decision easier.
I believe you are incorrect. Both Netscape and Java were deadly competitors to Microsoft and, by their philosophy, nothing was to be spared in crushing these companies.
Netscape presented the vision of making the operating system irrelevant. Let's look at two of the most popular software products of the last few years: Google and Amazon. Yes, these are software products and each is completely platform agnostic. When I use Google or Amazon on Linux running Firefox, I get the exact same user experience as I get on Windows using IE. If this trend had continued, with the browser and its associated control of the user interface firmly in the hands of Netscape, Microsoft's monopoly position as the operating system of choice would have been lost.
Java was a danger due to a similar argument. Windows is popular because the most popular applications run on it. If Java delivered on its promise of platform independence, a whole new class of killer applications could have arose that were independant of the operating system. Microsoft would then no longer be the operating system of choice. Worse, it would not be the choice for the developers making new killer apps.
Killing Netscape and Java were not paranoid manoevers, they were carefully considered and rational defenses of one of Microsoft's two core strengths, the Operating System. Combined with the other strength: Office, Microsoft presents a huge barrier to entry for anyone attempting to wrest monopoly control over desktop computers from Microsoft.
The problem for Microsoft is they took out the companies, not the ideas. By the time they noticed, the idea of a universal browser was too well entrenched to go away. They have not yet succeeded in converting the Internet to a Microsoft only product (despite the best efforts of ActiveX and IIS).
Building a better Java is not an answer. At some point, the competitors would catch up to a standard such as a language, then how could Microsoft compete? Add features? To Sun's language?
And what happens when someone reimplements 80% of Office in Java? And suppose this new version runs just as nicely on Windows as, say, Mac? What's to keep people on Windows then?
No, these companies had to die. Nothing else would defend Microsoft's monopoly. That they attacked these companies is unfortunate, but part of our system of business. That they did so by exploiting their monopoly position is illegal and should have got them more severly punished.
First, Read this article.
.Net renders com programming obsolete. (Sure, you can mix the two, but try hiring a developer who knows the ins and outs of class factory instanciation. There aren't many.) And before everything could fully convert to .net, we get Avalon, which partially obsoletes .net.
.net's managed code makes Win32 programming much easier and secure - no buffer overruns, no memory leaks, etc. All this with speeds close enough to Win32 and C as not to really matter.
The point of the article is that Microsoft has abandon its longstanding practice of supporting backwards compatability.
It appears Microsoft is trying to protect their desktop monopoly with further developer lock-in. Mono is trying to prevent this, but eventually, for this strategy to work, Microsoft is going to have to have some portion of their system lock-in developers.
Joel makes the point that much of the cutting edge of application development is taking place not on desktop systems, but web enabled servers. Gmail is a perfect example, but I'm sure we can all think of some others. More and more, hot new software is not being sold as shrink-wrapped products with a Windows approved logo, but being deployed as a web service with some other revenue model (sales or ads, usually).
And, of course, gmail runs just as well on a mac, linux or windows box.
But html cannot be used for everything. I/O sucks, forms are very limited in data validation, transactions are stateless, etc. What I see this as addressing is the beginning of a new, expanded API from which Microsoft's biggest competitors can continue to draw developer mindshare away from Win32 applications.
This is in reaction to Microsoft's continued revision of their API set to make development easier. Consider that
This is a preemptive move on the part of the web developers. If a new, open standard can be developed that allows most business applications to move to an intranet model, they can continue the brain drain from Windows. This will lead to more and more killer apps appearing on systems other than Windows. Killer apps that run on any system. This is what Microsoft fears.
Of course, this has all been tried before. Netscape once planned to crush Microsoft in exactly this format. This was the heart of why the first browser war was fought. Netscape failed because they were offering one vendor's lock-in for another.
The second browser war is being fought for exactly the same reason. This time, Netscape's side has added a new twist to their main weapon - open source. If they abandon lock-in, they may be able to strip off enough mindshare to stagnate Microsoft. If so, then the operating system is no longer an asset. If the ability to use the newest, hottest software on the planet is not the correct operating system, but a standars compatable browser, Microsoft looses.
That, more than desktop widgets, is what is happening here.
Oh, dear. This just flashed into my head...
Bill, lying naked on a table: "Why do my dividinds hurt?"
Linus, looking down, sad and concerned: "You've never issued them before."
This problem was compounded by an artificial limiter on backwards compatablility. Namely, the fact that most buisnesses replaced their desktop computers every two to four years. Bundling deals meant those new computers came with the new shrinkwrapped products. Curiously, many of these newer products defaulted to file formats that older versions couldn't read.
.foo framework that you must have to run Microsoft Bar(tm), you'll just have to upgrade, won't you?
As more machines were replaced, the business began to get in the uncomfortable position of supporting two formats, the old an the new. When it reached the breaking point, an order would be given to convert.
However, while computers continue to get faster at about the same pace as always, software has fallen behind. Developers may crave more horsepower, but just what is it about word processing that demands a 2 GHz processor? Couple this with the number of machines replaced to prepare for y2k and you have the current weak desktop computer market.
Without new hardware coming in the doors regularly, older machines, and their software packages, are suddenly lasting longer. This makes it much harder for Microsoft to force upgrades to a new version.
If I read the situation correctly, Microsoft is toying with a simultaneous conversion to the service model with a forced upgrade due to new APIs. After all, if Windows 2K doesn't suppor the latest
We use bubble ballots out here in Arizona and I wholeheartedly agree. This is definitely the way to go.
Each person is handed a ballot. They go to their booth, where the official election literature is posted, along with an ink pen. Fill in the bubble by your candidate's name. Couldn't be simpler.
Next, you take your completed ballot up to the machine. You place it face down in the scanner and it sucks it in. If the ballot is valid, the light turns green, your ballot is dropped in the ballot box and you get the little sticker.
This has the speed of computer scored elections plus the paper trail of ballots for double checking. Plus, if you fill out a ballot incorrectly (check two people in a race where only one is permitted or something) the ballot is spat back. The election official can then help you. This should eliminate most problems with incorrectly filled-out ballots.
The weak point in the system is the programming of the computer scoring. Random spot checks comparing paper ballots to machine talleys could easily be used to ensure correct behavior.
Proven reliable technology. Course, we've got to dump it for touch screens with no software audits or paper trails.
Stupid.
The French did not plan a stupid defense in WWII. They planned a superb, WWI style defense. The problem is the Germans mounted a WWII blitzkrieg style attack, an attack that had been invented by the Germans just a few years previously.
The French were using tanks in an infantry support roll. The total number of French tanks was about equal to the number of German tanks, but spread across the entire defensive line in groups of one or two per mile. The Germans concentrated their entire tank force into one area and smashed through. Once the line was broken, they were able to attack the rest of the line from the rear.
Or, in terms better understood by the Slashdot community, the French bunker line was 0\/\/n3z by a Zerg rush early in the game.
MSDN's search engine is so abysmally bad, I dropped it years ago and now just use Google. For example "CRegKey example" gives a link into the MSDN documentation, plus links to several examples on usage. The same search on MSN's search does not show the MSDN page as the first link and does not have any really good examples on the front page.
Sad. They can't even search their own documentation effectively.