I see your argument but I don't think an office package is going to push customers past the tipping-point in favor of Sun hardware as long as it's so expensive (they may buy it for other reasons, of course). On the other hand, if the price of Sun systems were more competitive with PCs, your argument would be stronger.
The other danger for Sun is that staroffice makes Linux more attractive and a Linux system is much cheaper. So it's more likely that a Linux system would be selected if the customer desires a Unix OS and an office package.
Of course, in the unlikely event that staroffice surpassed MS Office in usage, it would probably mean that most people would be running it on Windows (since that's the platform they're used to). This would be bad for MS since they would sell less of MS Office, but not really good for Sun since they aren't selling staroffice.
Thus my original argument: Scott wants to hurt Bill even if it doesn't help Sun.
"Sun's primarily business is hardware. So making an x86 port of solaris seems silly when they could spend the money/manpower of improving what is their best chance in the longrun -- staroffice -- of breaking microsoft's deathgrip."
You're right about Sun being a hardware company, but that's exactly why staroffice is even less useful for them than Solaris. Staroffice is available on more systems than Solaris and so provides little incentive to buy Sun hardware. I think staroffice is more about the ego contest between Scott and Bill and has little to do with Sun's business interests. That's not to say that staroffice isn't useful to users, but it's not clear how it helps Sun's bottom line.
"GO BUY YOUR CHEAP PIECE OF SHIITE. ***THEN*** you will find out the shortcomings, be $300 further from a real one, and stick your head in the sand yelling 'mine is just as good as a mac!!!!'"
You can't even buy the new Mac yet but you already claim that its flat screen is superior. Why don't you wait and see what the quality really is before passing judgment?
"...oh wait, i forgot the whole directory structure of XP was lifted right out of dos - but m$ SAYS there is no DOS underneath, and they WOULD NEVER LIE, WOULD THEY?"
Well, if you have some proof that there is DOS underneath XP, then by all means enlighten us.
Well, at least you've clarified what you mean by "APIs that you can live with for decades".
You can use the core UNIX APIs and the C standard library as they existed in the 1980's on their own to write applications that can do 1980's kind of stuff. If you want to write applications that take advantage of new technologies you need updated or additional APIs. There's nothing wrong with that but it's no great accomplishment and I suspect little thought was given to what was going to be needed in 20 years at the time C and Unix were created.
"Code written for Microsoft platforms in the early 1980's looks nothing like code you would write for Microsoft platforms today"
And code written for AT&T platforms prior to Unix and C looked nothing like what they were writing before - so what. Let's forget about "platforms" and talk about operating systems. Windows 1.0 wasn't released until November of 1985, so there really wasn't much Windows application development in the early 1980's to compare to.
I don't really see this as a Unix vs. Windows issue though, I was responding to what I believed to be a extravagant claim that I disagreed with.
By the way, Postscript, X11, and Motif are not decades old.
Sorry to disappoint you, but I do have a couple of decades of professional experience in this industry. You say you have that much experience as well, so I'll take your word for it.
You claim that a well-designed API should not have to change for a couple of decades. Can you give an example of API that hasn't changed since Jan of 1982?
Some of the worst software designs I've seen have been created by programmers that tried to predict future requirements and failed. I suspect the failure rate for predicting 20 years into the future is 100%.
"Apps running as a normal user under NT or UNIX clones can typically write only to the user's home folder or to the periodically-emptied/tmp, the only places most normal users have write permissions."
Well, in NTFS you can control access to directories with administrator privileges but I doubt that the default behavior would be to break all the legacy applications.
"Lets say that I build an application using the Windows API (actually am). Everything works fine until the user starts using it on Windows XP or Windows 2000. You may ask why? Well according to the new security rules the application must only save content under the "My Documents" folder and not the folder installed to or something else."
There must be more to it than that. Certainly applications can save to other folders besides "My Documents" in Windows 2000 and Windows XP. Otherwise 99% of legacy applications wouldn't work.
"Their main weapon is undocumented API's that they can change to their hearts content because no one knows about them (unless they have done some reverse engineering). These secret API's give Microsoft the stranglehold that they have"
Thousands of sucessful applications have been written without the use of "secret API's". I think the problem that some MS competitors have had is that they didn't take advantage of the public API's that were available (WordPerfect 1.0's disdain for Windows printer drivers comes to mind).
"Go take a look through some of those cheezy "Writers Market" magazines... You'll find them choc-a-bloc full of advertising from trademark owners, spelling out in great detail how their trademarks are to be used."
You're right. I recall an ad from Xerox explaining that the word "Xerox" was a trademark and shouldn't be used as verb to describe making a copy.
This practice is common in the legal protection of IP. For example, it only takes one individual with access to a trade secret who has not signed a non-disclosure agreement to undermine the rights of the holder.
"Again, design patterns aren't new, only the terminology is. Most of the programming used design patterns in their various forms, they just weren't called "design patterns"."
Your missing the point which was that all of this software was written without the "study" of design patterns. If the "study" of design patterns merely means doing stuff programmers have been doing all along than there's no point in reading any books on the subject. If, in fact, there are new ideas in these books (as I believe there are) than they may be worth reading but again reading these books is not a requirement for writing useful code since useful code has been written prior to the publication of the books. This is as clear as I can make it so I'll stop with this post.
You have a point. Clearly the value of studying algorithms has diminished somewhat as higher-level libraries have become available.
My point is that there is a consensus among programmers (at least to the extent that we can agree on anything) that studying algorithms is useful. Such a consensus doesn't yet exist for design patterns although it might someday.
"That's a big if. I'm sure there are a few rare geniuses who can re-invent this sort of thing, and fewer still who refuse to read anything and have such talent, but such people are the exception and not the rule."
Keep in mind that most of the programming that has ever been done predates the study of design patterns and most of this code was written by average programmers. That not to say that studying design patterns has no value, but obviously it is not a minimum requirement for writing useful code.
"Design patterns are not new, the expression "Design patterns" is....Coplien's "Advanced C++ Programming Styles and Idioms" book was written in '91, and this book describes many of the patterns in GoF."
Well, I see what you're saying but I think we're going to have a problem discussing this subject if we fuzzy-up the time-frame. Design patterns is supposed to be a formal subject and so I think it's appropriate to date it from the time it was first proposed. In any case, I'm not sure even a decade is long enough to declare victory.
"Solutions to classic programming problems are not "a fad". I believe it's a misconception that design patterns are a "fad", or even that they are "new"."
I never said that design patterns were a fad, I said that it's hard to determine whether any particular method is a fad or not. It takes a lot of time to evaluate these things and if you investigate it and it turns out to be less than great you've wasted a lot of time.
"Again, "Design patterns" is not a programming paradigm. It is more general than that"
Well, I think the problem is that you have a narrow definition of what a "programming paradigm" is. But let me restate what I said in a way that doesn't conflict with your definition: I'm sure advocates of every methodology for any aspect of computer science believe everyone should rush to study it, but the reality is that there just isn't enough time.
I think your response is a bit harsh. If people have been successfully using algorithms and design patterns without studying them than that weakens the case for saying that every programmer that doesn't study them is "lazy, ignorant, and a bad programmer".
In any case, I think the case for studying design patterns is a bit weaker than that for algorithms which has stood the test of time.
There's so much competition for programmers' attention these days it's hard to tell the latest fad from something of real value. I'm sure advocates of every programming paradigm believe everyone should rush to study it, but the reality is that there just isn't enought time. So we each have to make our own judgement about what is important and we should avoid labeling others just because they don't share our enthusiasm for a particular method.
"I find that to be completely true that one really _really_ good programmer can be better than as many mediocre programmers as you want to throw at a problem.... I think having those mediocre programmers can help... Documentation, debugging, etc. that you really don't want your best mind wasting his time on."
Yeah, you can't have "really good" programmers working on stuff like debugging or documentation.
I believe someone has posted this link before http://www.idiom.com/~zilla/Work/kcsest.pdf. This link is to a paper called "Large Limits to Software Estimation"
Abstract from the paper:
Algorithmic (KCS) complexity results can be interpreted as indicating some limits to software estimation. While these limits are abstract they nevertheless contradict enthusiastic claims occasionally made by commercial software estimation advocates. Specifically, if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project, then claims of purely objective estimation of project complexity, development time, and programmer productivity are necessarily incorrect.
This a good paper to keep in mind when reviewing the claims made for a particular software development methodology.
go ahead, tweak and tune your proprietary black box implementation"
I agree, but I think this argument can also apply to APIs and other higher-level SW interfaces. I'd rather a fully described API without source code then a poorly documented API with source code. You can learn a lot looking at source but it's not always the most efficient method of getting your work done.
"So I do think that free software is implicitly superior in all technical aspects."
No software produced using any particular methodology or philosophy is "implicitly superior in all technical aspects" to software produced using other methods. Assuming there is a consensus on what constitutes superiority, each software product has to be evaluated on it's own individual merits.
"Also, Windows does not have a 'base GUI toolkit'. There are several different ones, including both GTK+ and Qt, one for each RAD or IDE tool, and a few others."
"Normally newbies interpret RTFM to mean: this guy is a total asshole, and doesn't want to help me."
That seems to me the practical interpretation of RTFM. After all, what does the "F" stand for? It's not exactly a polite response. I suspect that a lot of the time the guy doesn't know the answer either and is just hiding his ignorance by saying "RTFM".
"I did read your post. "PC-based" means "runs on PCs" so I didn't naturally compare that to "runs on Intel architecture" like you did."
Well, over 99% of Windows installations run on Intel. Still, there's enough ambiguity in the term that I withdraw my claim that you weren't paying attention.
"DR's experience fifteen years ago" happened about ten years ago, and it led directly to the dominance of Windows (and thus Windows 95 and so on) since then"
Well I'm not going to quible over the exact number of years, but I notice that you haven't given a specific year either so perhaps you're not so sure. Even if you're correct and it was only a decade ago, it's still ancient history in this industry.
Your conclusion that Windows is dominant because MS derailed DR-DOS seems to me a big leap. Was Digital Research working on a GUI-based OS of their own that could compete directly with Windows? If so, why would they care so much about Windows being compatible with DR-DOS?
"Such as TV ads throughout Britain (for instance) which even my mother noticed, PCs from IBM and others being bundled with OS/2, ads in newspapers and trade magazines, etc."
I don't live in Britain so I can't comment on that but I didn't see much effort here in the US. IBM had much deeper pockets than MS so they could have outspent them on marketing if they wanted to.
"They wanted to sell PCs with Windows 95 when Windows 95 came out, as I said above."
Slashdot Mirror
I see your argument but I don't think an office package is going to push customers past the tipping-point in favor of Sun hardware as long as it's so expensive (they may buy it for other reasons, of course). On the other hand, if the price of Sun systems were more competitive with PCs, your argument would be stronger.
The other danger for Sun is that staroffice makes Linux more attractive and a Linux system is much cheaper. So it's more likely that a Linux system would be selected if the customer desires a Unix OS and an office package.
Of course, in the unlikely event that staroffice surpassed MS Office in usage, it would probably mean that most people would be running it on Windows (since that's the platform they're used to). This would be bad for MS since they would sell less of MS Office, but not really good for Sun since they aren't selling staroffice.
Thus my original argument: Scott wants to hurt Bill even if it doesn't help Sun.
"Sun's primarily business is hardware. So making an x86 port of solaris seems silly when they could spend the money/manpower of improving what is their best chance in the longrun -- staroffice -- of breaking microsoft's deathgrip."
You're right about Sun being a hardware company, but that's exactly why staroffice is even less useful for them than Solaris. Staroffice is available on more systems than Solaris and so provides little incentive to buy Sun hardware. I think staroffice is more about the ego contest between Scott and Bill and has little to do with Sun's business interests. That's not to say that staroffice isn't useful to users, but it's not clear how it helps Sun's bottom line.
"GO BUY YOUR CHEAP PIECE OF SHIITE. ***THEN*** you will find out the shortcomings, be $300 further from a real one, and stick your head in the sand yelling 'mine is just as good as a mac!!!!'"
You can't even buy the new Mac yet but you already claim that its flat screen is superior. Why don't you wait and see what the quality really is before passing judgment?
"...oh wait, i forgot the whole directory structure of XP was lifted right out of dos - but m$ SAYS there is no DOS underneath, and they WOULD NEVER LIE, WOULD THEY?"
Well, if you have some proof that there is DOS underneath XP, then by all means enlighten us.
Well, at least you've clarified what you mean by "APIs that you can live with for decades".
You can use the core UNIX APIs and the C standard library as they existed in the 1980's on their own to write applications that can do 1980's kind of stuff. If you want to write applications that take advantage of new technologies you need updated or additional APIs. There's nothing wrong with that but it's no great accomplishment and I suspect little thought was given to what was going to be needed in 20 years at the time C and Unix were created.
"Code written for Microsoft platforms in the early 1980's looks nothing like code you would write for Microsoft platforms today"
And code written for AT&T platforms prior to Unix and C looked nothing like what they were writing before - so what. Let's forget about "platforms" and talk about operating systems. Windows 1.0 wasn't released until November of 1985, so there really wasn't much Windows application development in the early 1980's to compare to.
I don't really see this as a Unix vs. Windows issue though, I was responding to what I believed to be a extravagant claim that I disagreed with.
By the way, Postscript, X11, and Motif are not decades old.
Sorry to disappoint you, but I do have a couple of decades of professional experience in this industry. You say you have that much experience as well, so I'll take your word for it.
You claim that a well-designed API should not have to change for a couple of decades. Can you give an example of API that hasn't changed since Jan of 1982?
Some of the worst software designs I've seen have been created by programmers that tried to predict future requirements and failed. I suspect the failure rate for predicting 20 years into the future is 100%.
Actually, you can use getenv to determine the user's HOMEPATH.
"The way it should be done is that you spend some time ahead of time and work out APIs that you can live with for decades."
Once you have decades of experience you'll be qualified to evaluate the practicality of that statement.
"Apps running as a normal user under NT or UNIX clones can typically write only to the user's home folder or to the periodically-emptied /tmp, the only places most normal users have write permissions."
Well, in NTFS you can control access to directories with administrator privileges but I doubt that the default behavior would be to break all the legacy applications.
"Lets say that I build an application using the Windows API (actually am). Everything works fine until the user starts using it on Windows XP or Windows 2000. You may ask why? Well according to the new security rules the application must only save content under the "My Documents" folder and not the folder installed to or something else."
There must be more to it than that. Certainly applications can save to other folders besides "My Documents" in Windows 2000 and Windows XP. Otherwise 99% of legacy applications wouldn't work.
"Their main weapon is undocumented API's that they can change to their hearts content because no one knows about them (unless they have done some reverse engineering). These secret API's give Microsoft the stranglehold that they have"
Thousands of sucessful applications have been written without the use of "secret API's". I think the problem that some MS competitors have had is that they didn't take advantage of the public API's that were available (WordPerfect 1.0's disdain for Windows printer drivers comes to mind).
"Go take a look through some of those cheezy "Writers Market" magazines ... You'll find them choc-a-bloc full of advertising from trademark owners, spelling out in great detail how their trademarks are to be used."
You're right. I recall an ad from Xerox explaining that the word "Xerox" was a trademark and shouldn't be used as verb to describe making a copy.
This practice is common in the legal protection of IP. For example, it only takes one individual with access to a trade secret who has not signed a non-disclosure agreement to undermine the rights of the holder.
"Again, design patterns aren't new, only the terminology is. Most of the programming used design patterns in their various forms, they just weren't called "design patterns"."
Your missing the point which was that all of this software was written without the "study" of design patterns. If the "study" of design patterns merely means doing stuff programmers have been doing all along than there's no point in reading any books on the subject. If, in fact, there are new ideas in these books (as I believe there are) than they may be worth reading but again reading these books is not a requirement for writing useful code since useful code has been written prior to the publication of the books. This is as clear as I can make it so I'll stop with this post.
You have a point. Clearly the value of studying algorithms has diminished somewhat as higher-level libraries have become available.
My point is that there is a consensus among programmers (at least to the extent that we can agree on anything) that studying algorithms is useful. Such a consensus doesn't yet exist for design patterns although it might someday.
"That's a big if. I'm sure there are a few rare geniuses who can re-invent this sort of thing, and fewer still who refuse to read anything and have such talent, but such people are the exception and not the rule."
Keep in mind that most of the programming that has ever been done predates the study of design patterns and most of this code was written by average programmers. That not to say that studying design patterns has no value, but obviously it is not a minimum requirement for writing useful code.
"Design patterns are not new, the expression "Design patterns" is....Coplien's "Advanced C++ Programming Styles and Idioms" book was written in '91, and this book describes many of the patterns in GoF."
Well, I see what you're saying but I think we're going to have a problem discussing this subject if we fuzzy-up the time-frame. Design patterns is supposed to be a formal subject and so I think it's appropriate to date it from the time it was first proposed. In any case, I'm not sure even a decade is long enough to declare victory.
"Solutions to classic programming problems are not "a fad". I believe it's a misconception that design patterns are a "fad", or even that they are "new"."
I never said that design patterns were a fad, I said that it's hard to determine whether any particular method is a fad or not. It takes a lot of time to evaluate these things and if you investigate it and it turns out to be less than great you've wasted a lot of time.
"Again, "Design patterns" is not a programming paradigm. It is more general than that"
Well, I think the problem is that you have a narrow definition of what a "programming paradigm" is. But let me restate what I said in a way that doesn't conflict with your definition: I'm sure advocates of every methodology for any aspect of computer science believe everyone should rush to study it, but the reality is that there just isn't enough time.
I think your response is a bit harsh. If people have been successfully using algorithms and design patterns without studying them than that weakens the case for saying that every programmer that doesn't study them is "lazy, ignorant, and a bad programmer".
In any case, I think the case for studying design patterns is a bit weaker than that for algorithms which has stood the test of time.
There's so much competition for programmers' attention these days it's hard to tell the latest fad from something of real value. I'm sure advocates of every programming paradigm believe everyone should rush to study it, but the reality is that there just isn't enought time. So we each have to make our own judgement about what is important and we should avoid labeling others just because they don't share our enthusiasm for a particular method.
"I find that to be completely true that one really _really_ good programmer can be better than as many mediocre programmers as you want to throw at a problem. ... I think having those mediocre programmers can help ... Documentation, debugging, etc. that you really don't want your best mind wasting his time on."
Yeah, you can't have "really good" programmers working on stuff like debugging or documentation.
I believe someone has posted this link before http://www.idiom.com/~zilla/Work/kcsest.pdf. This link is to a paper called "Large Limits to Software Estimation"
Abstract from the paper:
Algorithmic (KCS) complexity results can be interpreted as indicating some limits to software estimation. While these limits are abstract they nevertheless contradict enthusiastic claims occasionally made by commercial software estimation advocates. Specifically, if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project, then claims of purely objective estimation of project complexity, development time, and programmer productivity are necessarily incorrect.
This a good paper to keep in mind when reviewing the claims made for a particular software development methodology.
"open up and describe fully the interface.
go ahead, tweak and tune your proprietary black box implementation"
I agree, but I think this argument can also apply to APIs and other higher-level SW interfaces. I'd rather a fully described API without source code then a poorly documented API with source code. You can learn a lot looking at source but it's not always the most efficient method of getting your work done.
So what does GTK+ and Qt have to do with MS Windows?
"So I do think that free software is implicitly superior in all technical aspects."
No software produced using any particular methodology or philosophy is "implicitly superior in all technical aspects" to software produced using other methods. Assuming there is a consensus on what constitutes superiority, each software product has to be evaluated on it's own individual merits.
"Also, Windows does not have a 'base GUI toolkit'. There are several different ones, including both GTK+ and Qt, one for each RAD or IDE tool, and a few others."
Huh? Are you talking about Microsoft Windows?
"Normally newbies interpret RTFM to mean: this guy is a total asshole, and doesn't want to help me."
That seems to me the practical interpretation of RTFM. After all, what does the "F" stand for? It's not exactly a polite response. I suspect that a lot of the time the guy doesn't know the answer either and is just hiding his ignorance by saying "RTFM".
"I did read your post. "PC-based" means "runs on PCs" so I didn't naturally compare that to "runs on Intel architecture" like you did."
Well, over 99% of Windows installations run on Intel. Still, there's enough ambiguity in the term that I withdraw my claim that you weren't paying attention.
"DR's experience fifteen years ago" happened about ten years ago, and it led directly to the dominance of Windows (and thus Windows 95 and so on) since then"
Well I'm not going to quible over the exact number of years, but I notice that you haven't given a specific year either so perhaps you're not so sure. Even if you're correct and it was only a decade ago, it's still ancient history in this industry.
Your conclusion that Windows is dominant because MS derailed DR-DOS seems to me a big leap. Was Digital Research working on a GUI-based OS of their own that could compete directly with Windows? If so, why would they care so much about Windows being compatible with DR-DOS?
There was at least a mild implication that Satchell was a liar. That's a lot more of a flamebait than most of the posts moderated as such around here.
"Such as TV ads throughout Britain (for instance) which even my mother noticed, PCs from IBM and others being bundled with OS/2, ads in newspapers and trade magazines, etc."
I don't live in Britain so I can't comment on that but I didn't see much effort here in the US. IBM had much deeper pockets than MS so they could have outspent them on marketing if they wanted to.
"They wanted to sell PCs with Windows 95 when Windows 95 came out, as I said above."
Another poster has already answered this point.