Thought not. Whenever I've gone down the links to find the actual languages, I find that they're always something that isn't the original language at all. So far, not one single current language actually fits into the.net framework.
(1) Every time you design a library you get a choice of lots-of-options or make-it-simple. It best to go in one direction or another. STL tries to go middle-of-the-road, resulting in too much complexity for most jobs, but not enough for wierd ones.
(2) Mismatching the requirements of the STL for very, very robust template handling with the real-world sucky template implementations. This leads to lots of imcompatible, almost-STL libraries, grossly reducing code reusability.
(3) Mismatching STLs need for smart error messages with real-world compilers lousy error messages. If I see any more 1024 byte messages with the word "basic_string" repeat a couple dozen times it will be too soon.
Note that these are engineering problems: making a dream work in the real world. The 1024 byte error messages are not STL's "fault" -- but it's STL that that triggers them, and STL that could have been designed such that when when an error is triggered, a more useful message was generated.
For those of us who are computer history book geeks, knowing which books refer to which computers would be a big help. For example, if I'm interested in the "System/23", which book actually says anything about it? And at what level is the information? Really technical? Totally dishes the politics? Pro-system/23, or does it mention the flaws? Any pictures?
"...Sun Microsystems has taken every step possible to prevent Microsoft from shipping our award winning Java virtual machine."
Too bad the courts agreed with Sun: it wasn't a Java Virtual Machine, and they had no right to use the name. The whole of "Visual J++" is a creepy "not java at all" tool -- want to design a dialog box? Certainly -- using Microsoft components, not Java components. Want to make 100% pure Java? You can, but it's hard, and Microsoft doesn't make it easy at all.
Microsoft professes great disdain for anyone who ever uses the courts. Would they rather we keyed their cars?
It's typical, when porting, to discover a host of silly little function that exist on one platform and don't on another. It's usually pretty simple to whip up a good solution.
Switching from classic 'sprintf' type output over to C++ type 'stream' output, though, it Just Criminal. We're porting and fixing here, not rewriting from scratch....
Um...Netscape wasn't making money on the browser? Are you stark, raving bonkers? They were hauling in money by the barrel -- Jim Clarke says (in his book) that Netscape was seduced by how easy it was to charge for a browser and therefore didn't diversify into other areas.
*you* may not have paid for your copy of Netscape -- and a lot of individuals didn't -- but lots of companies were happy to pay for site licenses.
When a company gets reorganized, one of the wonderful features is that all the contracts get voided. Which means that any special "I don't want to get screwed" clauses you put in just vanish. (This is a remembrance of I think an InfoWorld article from way back).
And yes, I've been personally dumped on by companies vanishing. My very expensive, personally purchased function timing program vendor vanished one day, along with the promised version two....
My old boss had an interesting insight on code escrow: in all the contracts that he'd ever done which required code escrow, not a single customer one ever required that updates be escrowed -- bit rot to the max! Not only that, but with the build tools, it can't be rebuilt anyway.
Slashdot Mirror
Have you actually *seen* these languages?
.net framework.
Thought not. Whenever I've gone down the links
to find the actual languages, I find that they're always something that isn't the original language at all. So far, not one single current language actually fits into the
The STL is badly engineered.
(1) Every time you design a library you get a choice of lots-of-options or make-it-simple. It best to go in one direction or another. STL tries to go middle-of-the-road, resulting in too much complexity for most jobs, but not enough for wierd ones.
(2) Mismatching the requirements of the STL for very, very robust template handling with the real-world sucky template implementations. This leads to lots of imcompatible, almost-STL libraries, grossly reducing code reusability.
(3) Mismatching STLs need for smart error messages with real-world compilers lousy error messages. If I see any more 1024 byte messages with the word "basic_string" repeat a couple dozen times it will be too soon.
Note that these are engineering problems: making a dream work in the real world. The 1024 byte error messages are not STL's "fault" -- but it's STL that that triggers them, and STL that could have been designed such that when when an error is triggered, a more useful message was generated.
Peter
What, me bitter?
For those of us who are computer history book geeks, knowing which books refer to which computers would be a big help. For example, if I'm interested in the "System/23", which book actually says anything about it? And at what level is the information? Really technical? Totally dishes the politics? Pro-system/23, or does it mention the flaws? Any pictures?
"...Sun Microsystems has taken every step possible to prevent Microsoft from shipping our award winning Java virtual machine."
Too bad the courts agreed with Sun: it wasn't a Java Virtual Machine, and they had no right to use the name. The whole of "Visual J++" is a creepy "not java at all" tool -- want to design a dialog box? Certainly -- using Microsoft components, not Java components. Want to make 100% pure Java? You can, but it's hard, and Microsoft doesn't make it easy at all.
Microsoft professes great disdain for anyone who ever uses the courts. Would they rather we keyed their cars?
Peter
It's typical, when porting, to discover a host of silly little function that exist on one platform and don't on another. It's usually pretty simple to whip up a good solution.
Switching from classic 'sprintf' type output over to C++ type 'stream' output, though, it Just Criminal. We're porting and fixing here, not rewriting from scratch....
Um...Netscape wasn't making money on the browser? Are you stark, raving bonkers? They were hauling in money by the barrel -- Jim Clarke says (in his book) that Netscape was seduced by how easy it was to charge for a browser and therefore didn't diversify into other areas.
*you* may not have paid for your copy of Netscape -- and a lot of individuals didn't -- but lots of companies were happy to pay for site licenses.
When a company gets reorganized, one of the wonderful features is that all the contracts get voided. Which means that any special "I don't want to get screwed" clauses you put in just vanish. (This is a remembrance of I think an InfoWorld article from way back). And yes, I've been personally dumped on by companies vanishing. My very expensive, personally purchased function timing program vendor vanished one day, along with the promised version two.... My old boss had an interesting insight on code escrow: in all the contracts that he'd ever done which required code escrow, not a single customer one ever required that updates be escrowed -- bit rot to the max! Not only that, but with the build tools, it can't be rebuilt anyway.