If anyone can think of another field where a mistake of a single mistake in hundreds or thousands of hours work is considered a bad record, I'd be suprised.
Every other engineering discipline. It just doesn't seem that way because they are better at it than software developers.
It doesn't matter that logging and archiving every call and communication isn't feasible. Once the OK is given to logging everything the security services are free to have anything logged as they see fit.
A more manual method of logging occured in communist Romania and, although I don't have any figures, it did keep the crime rate down.
No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
I admit to not knowing much about OO since I feel it is a bit of over-hyped non-proven rubbish that is often used to cover terrible design (whoops slipped that bit of Trolling in -- it is Friday afternoon). However, isn't the fashion now to not use inheritance but to go with aggregation of small objects to pick up functionality? The extra polymorphism provided by multiple inheritance is more than covered by interfaces.
The Design patterns book mentions this in its introduction and argues that it is a much better way of reusing functionality. It won me over, but then I'm a non-believer anyway.
It was sloppy BIOS coding in the first place to not research partition types -- and should be fixed simply for that reason (I like to imagine that people programming BIOS for IBM set themselves high standards).
The fix seems simple enough to me too since some posters have reported that older BIOS work, meaning that they've changed the partition type number once already. If there's another release, and its the right thing to do, why not do it?
Its easy to write documented perl (use comments).
Its as easy to write un-obfuscated perl as it is not to shoot yourself with a gun.
Its hard to write 25000 lines of code in perl because it gets the job done in a lot less (and someone probably wrote a freely available module for it anyway).
I've never used Eiffel, but I know the pre/post condition ideas help with local interactions and can keep an object in a sensible state. However, in a big universe of objects they reach their limitations.
For instance, to use engineering analogies, a perfect screw that is totally specified can still be dropped by a fallible human into the workings of a machine and a perfect missile can run out of fuel if its pointed at the wrong target.
Scripting languages and haphazard combination of objects introduce the problems. I don't see a simple solution apart from being really careful. Trying to keep things simple (and not being the programmer in the famous toaster story) is also a good defense as people using a smaller framework have less to think about.
That was a convincing argument for Marshall as man of the century and an interesting article. But one bit grated:
Even modern saints like Ghandi -- though properly admired for their principles and moral courage -- are seen to have been limited or foolish in their specific political agendas, from pastoral-socialism to libertarian solipsism. Humanity proved more complex than ideologues ever imagined.
Its arrogant to call him politically foolish. I mean, he did give birth to the biggest democracy in the world.
So there are Yahoo using http, tons of perl, maybe some general perl modules and FreeBSD trying to Patent a programming technique that is hardly rocket science and is useful to everyone else.
Information from Sun is a little woolly at present. They claim amazing things but, as far as I can tell, aren't going into much detail on the architecture.
There are some big new concepts with MAJC. It needs code optimisation done for each implementation, uses speculative threads (which will be competing with the known and proven magic of Vector processing) and has a lump of registers with local/global separation.
I can't imagine any of these optimisations are going to kick butt in useful applications until more information comes out. Intel withheld information on the Pentium (Appendix H) and this resulted in compilers producing slower code when Pentium optimisations were turned on (for about a year).
Meanwhile, general purpose and graphics processors will continue to evolve with the advantage of mature tools supporting them. Embedded chips can also go to tightly coupled SMP on chip at low cost.
Exciting times.
PS: Context switching on cache misses has been around for at least ten years. When everyone thought that superconductors would take over the world there was discussion on how to deal with the monster memory latency and and one architecture (forgotten the name but it may have come from Japan) proposed running 5 threads concurrently and swapping execution on memory accesses.
Sorry, I read that far too quick and deserved to get my arse kicked. Nice detailed reply.
One point that needs to be made lest history is re-written though:
And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time.
When RISC came out it wasn't seen as a simple logical progression. I even heard it refered to as a fad that would disappear when transistor counts improved. There were tons of arguments for keeping CISC (it does more work per instruction, RISC processors were only faster because they had more registers, the early Sparcs couldn't do multiplication to save their lives...) and I remember being called an idiot by an Intel engineer for saying that CISC was not going to last. Digital engineers were also very vocal in damning CISC when the Alpha came out. This was because so many people were defending CISC.
I also think that the attitude that RISC is just an ISA (as seen in a lot of replies) is a software persons argument. The thing doing the work in PIIs and Athlons is running simple instructions and is RISC whether it is doing the can-can or emulating x86 as far as the outside world is concerned. That is why some hardware and marketing people think of them as RISC.
I was moved to send in a reply that the author of the article was clueless -- thanks for getting there first.
When the first RISC machines came out, superscalar execution hadn't been invented yet.
Some processors (Cray for one) had been doing this years before RISC came out. RISC actually makes superscalar execution easier because there is more consistency in the instructions and they don't hit as many functional units in a single instruction.
The fast CISC chips (PII, Athlon) do instruction conversion into RISC, under the bonnet, for this and many other reasons. So if the debate is over, its because RISC won -- big time.
I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling and the branch hints on the Alpha is another example of this applied to branching.
There is also promising work done on MISC (Minimal Intruction Set) with simple chips doing lots of instructions per second.
A look at the CPU info center charts here show that the Alpha is still almost twice as fast as the Pentium III and Athlon at SPEC INT. Benchmarks mean very little but its such a shame this wonderful processor isn't getting the headlines, machine architecture and recognition it deserves.
Slashdot Mirror
Every other engineering discipline. It just doesn't seem that way because they are better at it than software developers.
The others will just have to use their imagination.
A more manual method of logging occured in communist Romania and, although I don't have any figures, it did keep the crime rate down.
I admit to not knowing much about OO since I feel it is a bit of over-hyped non-proven rubbish that is often used to cover terrible design (whoops slipped that bit of Trolling in -- it is Friday afternoon). However, isn't the fashion now to not use inheritance but to go with aggregation of small objects to pick up functionality? The extra polymorphism provided by multiple inheritance is more than covered by interfaces.
The Design patterns book mentions this in its introduction and argues that it is a much better way of reusing functionality. It won me over, but then I'm a non-believer anyway.
The fix seems simple enough to me too since some posters have reported that older BIOS work, meaning that they've changed the partition type number once already. If there's another release, and its the right thing to do, why not do it?
Its easy to write documented perl (use comments).
Its as easy to write un-obfuscated perl as it is not to shoot yourself with a gun.
Its hard to write 25000 lines of code in perl because it gets the job done in a lot less (and someone probably wrote a freely available module for it anyway).
For instance, to use engineering analogies, a perfect screw that is totally specified can still be dropped by a fallible human into the workings of a machine and a perfect missile can run out of fuel if its pointed at the wrong target.
Scripting languages and haphazard combination of objects introduce the problems. I don't see a simple solution apart from being really careful. Trying to keep things simple (and not being the programmer in the famous toaster story) is also a good defense as people using a smaller framework have less to think about.
... the lifeguard in Jaws who annoys everyone on the beach by causing a fuss and then saves them from the shark.
Even modern saints like Ghandi -- though properly admired for their principles and moral courage -- are seen to have been limited or foolish in their specific political agendas, from pastoral-socialism to libertarian solipsism. Humanity proved more complex than ideologues ever imagined.
Its arrogant to call him politically foolish. I mean, he did give birth to the biggest democracy in the world.
Shame!
There are some big new concepts with MAJC. It needs code optimisation done for each implementation, uses speculative threads (which will be competing with the known and proven magic of Vector processing) and has a lump of registers with local/global separation.
I can't imagine any of these optimisations are going to kick butt in useful applications until more information comes out. Intel withheld information on the Pentium (Appendix H) and this resulted in compilers producing slower code when Pentium optimisations were turned on (for about a year).
Meanwhile, general purpose and graphics processors will continue to evolve with the advantage of mature tools supporting them. Embedded chips can also go to tightly coupled SMP on chip at low cost.
Exciting times.
PS: Context switching on cache misses has been around for at least ten years. When everyone thought that superconductors would take over the world there was discussion on how to deal with the monster memory latency and and one architecture (forgotten the name but it may have come from Japan) proposed running 5 threads concurrently and swapping execution on memory accesses.
One point that needs to be made lest history is re-written though:
And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time.
When RISC came out it wasn't seen as a simple logical progression. I even heard it refered to as a fad that would disappear when transistor counts improved. There were tons of arguments for keeping CISC (it does more work per instruction, RISC processors were only faster because they had more registers, the early Sparcs couldn't do multiplication to save their lives ...) and I remember being called an idiot by an Intel engineer for saying that CISC was not going to last. Digital engineers were also very vocal in damning CISC when the Alpha came out. This was because so many people were defending CISC.
I also think that the attitude that RISC is just an ISA (as seen in a lot of replies) is a software persons argument. The thing doing the work in PIIs and Athlons is running simple instructions and is RISC whether it is doing the can-can or emulating x86 as far as the outside world is concerned. That is why some hardware and marketing people think of them as RISC.
Sorry for the disappointing comment.
When the first RISC machines came out, superscalar execution hadn't been invented yet.
Some processors (Cray for one) had been doing this years before RISC came out. RISC actually makes superscalar execution easier because there is more consistency in the instructions and they don't hit as many functional units in a single instruction.
The fast CISC chips (PII, Athlon) do instruction conversion into RISC, under the bonnet, for this and many other reasons. So if the debate is over, its because RISC won -- big time.
I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling and the branch hints on the Alpha is another example of this applied to branching.
There is also promising work done on MISC (Minimal Intruction Set) with simple chips doing lots of instructions per second.
That was a very disappointing article.
A look at the CPU info center charts here show that the Alpha is still almost twice as fast as the Pentium III and Athlon at SPEC INT. Benchmarks mean very little but its such a shame this wonderful processor isn't getting the headlines, machine architecture and recognition it deserves.