Well, we'll always need business people (though as an aging socialist it pains me to admit it). But not everybody is cut out for the business world -- which doesn't have room for everybody anyway.
Besides, there are people who specialize in business. Except that if they're not flexible, their shiny degree aint worth much either. (Heard an interview with an unemployed "Vice President of Brand Awareness." Can't understand why he's a year plus on the breadlines.) Which brings me to my main point: everybody needs to be flexible.
Too many techies are overspecialized. Their only educational priority is to prepare for some job that happens to be Very Hot when they start school. Even if the dot.com boom had lasted for 100 years, people like that would be in big trouble eventually. Technology changes, and you need the mental flexibility to keep up with those changes. You won't get that with a narrow education.
None of these guys are insane. It's just that they've long since fired anybody with the guts to tell them that their shit doesn't smell. But yeah, their biggest enemies are their own egos. Same goes for that guy you mention in your sig.
You're right, Sun's a hardware company, not a software company. And that does indeed affect their priorities. But a company can do well selling both hardware and software. You simply need separate teams who work separately in terms of selling their own product, and who collaborate when it matters to the company as a whole.
Unfortunately, Sun, doesn't work that way. Separate parts of Sun don't collaborate, they work on stabbing each other in the back.
None of which really is relevent to my point about ideology. The fact is, Sun's ideological narrowness is hurting the whole company, including the hardware part. They're still acting as if nothing can displace the Sparc/Solaris server. Sure, they went and bought a an x86/Linux business, but like other such Sun ventures, it's dying from proper care and feeding.
As for your implication that a publically-traded company is immune from this kind of nonsense: dude, where have you been the last couple of years? Publically traded companies can't even track basic cash flow, never mind require that their management act sanely. In this case, most decisions seem to be determined by Scott McNeely's ego, and his personal vendettas.
Here's why I keep comparing Sun with IBM: the latter went through all this just a few years ago. They kept telling each other that a 90% share of the mainframe market was a guarantee of permanent profitability. They refused to see the importance of the personal computer (even though they invented the term!) or the internet, even after these things began to take over everywhere. Their upper management even refused to use email!
All this was turned around by a guy who initially refused the job because he didn't know jack about computers. But knowing what he didn't know turned out to make all the difference.
Java will not be disappearing any time soon. Too many big name companies (most notably IBM and Oracle) have invested too much money in Java for them to let that happen. Also, with the way that Java is developed, through the Java Community Process, any potential buyer would find it difficult to exert full control over the the technology. For a closed product, Java is pretty open.
Sun disappearing would actually be the best thing that could happen to Java. "Community Process" notwithstanding, Sun still thinks of Java as its private property, and almost all Java developments come from Sun employees. And Sun just has no understanding of the software marketplace. The atmosphere at Sun is just too ideological.
IBM has done far more to popularize Java than Sun. Just look at the Alphaworks web site. In general, IBM has a better grasp of the software world. The two companies actually have a parallel history. The main difference is that IBM has long since worked through their "we own the world" phase. If IBM were to buy Sun, things would get very interesting.
One thing: last time I interviewed at Apple (97) they were planning to replace Objective C with Java as the main system language. The object models are close enough, and there are a lot more Java programmers. Still hasn't happened. Ideology again?
So you're in Finland, big deal. You issue traffic fines based on income, and people let the government prepare their tax returns. Crazy. Time you re-merged with Russia!
Nonsense. Support people love me. I make their jobs easier. They always have more calls than they can handle. The hard part is convincing management that good docs are worth the expense.
Until Mozilla came out IE5Mac was the most standards compliant browser around. If you were a web developer and tested your pages on many OSs/browsers you'd be familiar with this.
Doesn't sound like a very useful compiler. Programmers, being more or less human, make mistakes coding their input. It's stupid to assert that they just need to be more careful. Aside from simple human error (Sorry Dave!), programmers can misunderstand the language definition. Indeed, they have a hard time learning the language without a robust compiler to play with. I don't think you can call a compiler "robust" if its only error message is "segmentation fault"!
Appropriately enough, you seem to have U.S. measure confused with Imperial measure. Not quite the same. For example, the Imperial system defines a gallon as 10 pounds of water under certain specific conditions. (Works out to 277.42 cubic inches.) This was imposed by act of Parliment in 1822, and replaced a large number of traditional "gallon" values.
Now by 1822, the U.S. had ceased to be part of the British empire (at least in our own minds), so traditional measures remained in use. We've cut way back, but we still have two kinds of gallons: the liquid gallon (which is the same as the English "wine gallon"; 231 cubic inches) and the dry gallon (same as the English "corn gallon"; 268.8 cubic inches).
Painfully complicated, no? I've always thought this kind of confusion is the real reason the metric system drove out all the competition. We were all told in school that the metric system triumphed because it's more logical and simple: you have a few basic definitions, and everything else extends from them in a simple way. But people don't mind complexity, if it's the kind they're used to. Not being able to communicate is another matter. Which is why Europe, with its thousands of diffent units of measure, embraced the metric system, but rejected all the similar reforms that came out of the French revolution (the decimal clock, the "rational" calendar).
And it's also why Americans have so thoroughly resisted metric reform. The "customary" system is familiar, the "logical" metric system is confusing. It's probably not that big a deal for American consumers; it just means we sometimes have to convert unfamiliar units. But it's totally unacceptable that any engineering gets done in customer units. It makes for lost space probes and airliners with fuel issues.
OK, assuming you don't need encryption, and don't have the CPU overhead to support it, FTP still is not necessarily the best choice. You speak of "transfers at line speed", but on a multiple access/collision detection network (such as Ethernet) there's no such thing. If the network's not busy, you can get pretty close, and it probably doesn't matter what protocol you use. But my own experience, and what I understand of how the protocols work, suggests that HTTP works better than FTP on a busy network.
My generalization used the word "crash". We don't speak of libraries crashing, only applications.
I should have mentioned that your company's product is a prime example of a library that has a good excuse for not being bulletproof. Math APIs are often used in tight loops in massive calculations. Adding failsafe logic may only degrade a call slightly, but when that call gets made a gazillion times, even a tiny loss of performance can get expensive.
On the other hand, the application itself had better be damned careful that the loop is executing valid data. Imagine the expense of a hours-long supercomputer run having to be repeated because the program crashed halfway through.
Or here's a nasty example: you're an artillery dude in the Iraqi desert and in the heat of the moment you type an invalid map grid into your laptop. It's OK for the program to reject your input (though making it difficult to impossible to enter invalid grids is better). It is not OK to just crash the program, and maybe force our GI to reboot the laptop -- assuming he lives that long.
That last example is directed less at Anonymous Brave Guy than at all the idiots who responded to my original post with assertions to the effect of, "we shouldn't have to make sure our product doesn't crash if the user does something stupid." That's a criminally arrogant attitude.
Yeah, "Legacy" was a poor choice of words. In addition to the advantages you mention, CW transceivers are easy to build from extremely primitive parts. Maybe not an issue in this era of cheap integrated circuitry. But you never know...
I work on an industry-leading mathematical library. We rely, in a few places, on getting sensible input from our client apps. If they give us garbage, they have no guarantees about getting a sensible error back, or even about anything ever coming back.
Oddly enough, I'm familiar with this kind of issue, since I write API docs for a living. I can actually accept that kind of behavior from a library -- provided it is thoroughly documented. It's a question of where you put your bulletproofing. It's obviously better to put the bulletproofing as low-level as possible, but that's nto always possible.
But the bulletproofing has to go somewhere. If the library developer leaves it out, but makes sure the application developer know that it's missing, most people (not all!) would say he done his job. But if the application developer simply ignores the whole issue and assumes that bad input will "never happen", he's criminally negligent.
Uh, you guys do document when your libraries are supposed to fail, don't you?
When I said "No equivalent" I sort of implied "in the IE implementation". Microsoft would never use somebody else's renderer, even if it was standard for the platform they were using. They want all different implementations of IE to work the same. To fail to do so would undercut their campaign to get everybody to standardize on IE.
HTML clients are supposed to do skip over input they can't render. And in general, software should do something reasonable when it can't deal with input. Like deliver an error message. Crashing is always evidence of a bug, whether the data that caused it is buggy or not.
The IE HTML renderer is actually in a DLL that's shared by several application. And yes, they crash too. It's sort of interesting that that this DLL has no MacOS equivalent. Or perhaps there is an MacOS equivalent, but the usual low-level kludges are different on Mac and Windows.
Why is this a big deal? Because the largest software company on the planet has no better development practices and safeguards than some half-literate garage hacker.
The ease with which Microsoft software manages to generate invalid pointers has bothered me for a long time. But for the web brower to crash in the face of such a god damned simple HTML error is just plain scary. Here's the entire web page:
<html> <form> <input type crash> </form> </html>
I mean, does anybody in Redmond do any QA work at all? Or are they all too busy writing white papers, fighting lawsuits, and babbling about "freedom to innovate"?
Slashdot Mirror
Besides, there are people who specialize in business. Except that if they're not flexible, their shiny degree aint worth much either. (Heard an interview with an unemployed "Vice President of Brand Awareness." Can't understand why he's a year plus on the breadlines.) Which brings me to my main point: everybody needs to be flexible.
Too many techies are overspecialized. Their only educational priority is to prepare for some job that happens to be Very Hot when they start school. Even if the dot.com boom had lasted for 100 years, people like that would be in big trouble eventually. Technology changes, and you need the mental flexibility to keep up with those changes. You won't get that with a narrow education.
None of these guys are insane. It's just that they've long since fired anybody with the guts to tell them that their shit doesn't smell. But yeah, their biggest enemies are their own egos. Same goes for that guy you mention in your sig.
Unfortunately, Sun, doesn't work that way. Separate parts of Sun don't collaborate, they work on stabbing each other in the back.
None of which really is relevent to my point about ideology. The fact is, Sun's ideological narrowness is hurting the whole company, including the hardware part. They're still acting as if nothing can displace the Sparc/Solaris server. Sure, they went and bought a an x86/Linux business, but like other such Sun ventures, it's dying from proper care and feeding.
As for your implication that a publically-traded company is immune from this kind of nonsense: dude, where have you been the last couple of years? Publically traded companies can't even track basic cash flow, never mind require that their management act sanely. In this case, most decisions seem to be determined by Scott McNeely's ego, and his personal vendettas.
Here's why I keep comparing Sun with IBM: the latter went through all this just a few years ago. They kept telling each other that a 90% share of the mainframe market was a guarantee of permanent profitability. They refused to see the importance of the personal computer (even though they invented the term!) or the internet, even after these things began to take over everywhere. Their upper management even refused to use email!
All this was turned around by a guy who initially refused the job because he didn't know jack about computers. But knowing what he didn't know turned out to make all the difference.
Nonsense. All you've accomplished is turning politics over to people who are good at lying to themselves. Which may have already happened!
IBM has done far more to popularize Java than Sun. Just look at the Alphaworks web site. In general, IBM has a better grasp of the software world. The two companies actually have a parallel history. The main difference is that IBM has long since worked through their "we own the world" phase. If IBM were to buy Sun, things would get very interesting.
One thing: last time I interviewed at Apple (97) they were planning to replace Objective C with Java as the main system language. The object models are close enough, and there are a lot more Java programmers. Still hasn't happened. Ideology again?
So you're in Finland, big deal. You issue traffic fines based on income, and people let the government prepare their tax returns. Crazy. Time you re-merged with Russia!
Nonsense. Support people love me. I make their jobs easier. They always have more calls than they can handle. The hard part is convincing management that good docs are worth the expense.
OK, since we're friends now: you guys need a tech writer?
OK, I'm slow. You're gonna hafta explain. What's the metaphor? What's your point?
Doesn't sound like a very useful compiler. Programmers, being more or less human, make mistakes coding their input. It's stupid to assert that they just need to be more careful. Aside from simple human error (Sorry Dave!), programmers can misunderstand the language definition. Indeed, they have a hard time learning the language without a robust compiler to play with. I don't think you can call a compiler "robust" if its only error message is "segmentation fault"!
Now by 1822, the U.S. had ceased to be part of the British empire (at least in our own minds), so traditional measures remained in use. We've cut way back, but we still have two kinds of gallons: the liquid gallon (which is the same as the English "wine gallon"; 231 cubic inches) and the dry gallon (same as the English "corn gallon"; 268.8 cubic inches).
Painfully complicated, no? I've always thought this kind of confusion is the real reason the metric system drove out all the competition. We were all told in school that the metric system triumphed because it's more logical and simple: you have a few basic definitions, and everything else extends from them in a simple way. But people don't mind complexity, if it's the kind they're used to. Not being able to communicate is another matter. Which is why Europe, with its thousands of diffent units of measure, embraced the metric system, but rejected all the similar reforms that came out of the French revolution (the decimal clock, the "rational" calendar).
And it's also why Americans have so thoroughly resisted metric reform. The "customary" system is familiar, the "logical" metric system is confusing. It's probably not that big a deal for American consumers; it just means we sometimes have to convert unfamiliar units. But it's totally unacceptable that any engineering gets done in customer units. It makes for lost space probes and airliners with fuel issues.
OK, assuming you don't need encryption, and don't have the CPU overhead to support it, FTP still is not necessarily the best choice. You speak of "transfers at line speed", but on a multiple access/collision detection network (such as Ethernet) there's no such thing. If the network's not busy, you can get pretty close, and it probably doesn't matter what protocol you use. But my own experience, and what I understand of how the protocols work, suggests that HTTP works better than FTP on a busy network.
I should have mentioned that your company's product is a prime example of a library that has a good excuse for not being bulletproof. Math APIs are often used in tight loops in massive calculations. Adding failsafe logic may only degrade a call slightly, but when that call gets made a gazillion times, even a tiny loss of performance can get expensive.
On the other hand, the application itself had better be damned careful that the loop is executing valid data. Imagine the expense of a hours-long supercomputer run having to be repeated because the program crashed halfway through.
Or here's a nasty example: you're an artillery dude in the Iraqi desert and in the heat of the moment you type an invalid map grid into your laptop. It's OK for the program to reject your input (though making it difficult to impossible to enter invalid grids is better). It is not OK to just crash the program, and maybe force our GI to reboot the laptop -- assuming he lives that long.
That last example is directed less at Anonymous Brave Guy than at all the idiots who responded to my original post with assertions to the effect of, "we shouldn't have to make sure our product doesn't crash if the user does something stupid." That's a criminally arrogant attitude.
Yeah, "Legacy" was a poor choice of words. In addition to the advantages you mention, CW transceivers are easy to build from extremely primitive parts. Maybe not an issue in this era of cheap integrated circuitry. But you never know...
And you know this because...
It might have something to do with the fact that there are more IE users in Rhode Island then there are Safari users on the whole planet.
I once heard a Java developer quip that the Windows BSOD was obviously a feature. How else to reclaim all those memory leaks?!
But the bulletproofing has to go somewhere. If the library developer leaves it out, but makes sure the application developer know that it's missing, most people (not all!) would say he done his job. But if the application developer simply ignores the whole issue and assumes that bad input will "never happen", he's criminally negligent.
Uh, you guys do document when your libraries are supposed to fail, don't you?
Go read the HTML spec, and then lecture me. asshole.
When I said "No equivalent" I sort of implied "in the IE implementation". Microsoft would never use somebody else's renderer, even if it was standard for the platform they were using. They want all different implementations of IE to work the same. To fail to do so would undercut their campaign to get everybody to standardize on IE.
HTML clients are supposed to do skip over input they can't render. And in general, software should do something reasonable when it can't deal with input. Like deliver an error message. Crashing is always evidence of a bug, whether the data that caused it is buggy or not.
Why is this a big deal? Because the largest software company on the planet has no better development practices and safeguards than some half-literate garage hacker.