"We're in something of a historical anomaly right now, with a single OS having over 90% marketshare, and a single desktop CPU architecture having over 90% marketshare"
You're right about marketshare, but wrong about the implications. Although only a small percentage of applications are ported today, there's more porting today than there has ever been.
"All that said, if MacOS gets to 20% marketshare in a few years, wouldn't you like to have an easy port to that platform? What about Linux? Or, heaven forfend, Solaris? AIX?"
Porting is always harder then advertised. In addition, by the time the MacOS gets a 20% marketshare (if ever), today's application will be obsolete. Why make your product less competitive in its original environment in the hope that you'll be able to port it easily later?
Optimize for your initial market first and you might have the luxury of porting the application later.
"If he is smart, he has confined all his platform specific code to a single library, or collection of libraries, with abstract interfaces."
That sounds like a good academic approach. It's a good professional approach too if there's a reasonable expectation that the application will be ported to another OS.
On the other hand, most applications will never be ported from the environment they started on and the extra effort and added complexity of adding a layer of abstraction that doesn't model the problem being solved isn't justified in those cases.
Even in those cases where the porting takes place, it's almost never as simple as just recompiling the code.
The question is whether you want to spend extra money and effort to pay today for what you may or may not need tomorrow.
The days when programmers were the key players in computer games development have long since passed (they probably ended at the time of the first industry crash).
"Well but then you should be writing small modular utilites in your "C or C++" that can easily be piped together to form new and interesting things you maybe didn't even know people would want to do with your utility."
No!No!No! Unix's philosphy of stringing little programs together wasn't based on some brilliant general design concept, but rather on the limitations of computer systems of the time. Fully integrated applications weren't practical at that time because they wouldn't fit into memory.
Well, the command line can do almost anything as long as you're willing to turn your real work into the process of integrating a bunch of tiny commands into someting approaching what you need.
If I wanted to go to that much trouble, I'd just write a utility in C or C++ that did exactly what I wanted without messing around with shell commands.
"There is absolutely no excuse for a company like Google to allow employees/contractors to be locking the company's applications into a single platform proprietary API."
Isn't the real solution to keep the applications on the web server? Supporting Windows and Unix derivatives seems more like a dual platform strategy than a cross-platform one anyway. For web apps all that is required is a browser which is a an OS-agnostic requirement.
Yes, MS learned how to make a GUI-style word processor by writing one for the Mac (which made a lot of sense since it was the only popular GUI-based system at the time). Word for Macintosh was, however, created by MS, not Apple, so I don't see any great debt owed to Apple with respect to it.
Obviously Apple had smart enough talent to create their own full-featured word processor, but Applle must have decided that letting MS dominate was in their best interest at the time.
As for WordPerfect, they let their ego overcome their business sense and it cost them.
Well, I think the point is to be careful about one's analogies. If the analogy writer gets to narrowly interpret the analogy to support his point, it's not very illuminating.
The fact is that some people really like FF much better than IE, but comparing FF to a fine car and IE to a crappy one is just another way of saying you really like FF better. No additional information has been added via the analogy.
Sure, but I don't get your point. Perhaps you meant that the existence of the mac played a role in the success of microsoft since it provided them with another platform to develop for.
Perhaps he also won't admit (and neither will you, I imagine) that programs like MS Word played an important role in the success of the Mac as a viable tool for business.
I think it was very savvy of Jobs to buy the computer graphics division of LucasFilm to create Pixar, but it's John Lasseter who made Pixar what it is today.
One could argue that a large part of Pixar's success has been Job's willingness to stay out of day-to-day operations and concentrate on the business side.
"Well, if everyone decided to exploit the BSD code (ie, if all enchancements were closed), then the community would die. There isn't really much question of that."
At the risk of rephrasing what I already said, the fact that BSD code exists at all indicates that the "if all enhancements were closed" scenario is very unlikely to occur. If people are motivated to create BSD code in the first place knowing that some enhancements will be closed, then they won't mind making enhancements under the same conditions.
Having said that, the pro-GPL forces have waged a very successful disinformatoin campaign against the BSD and it has taken its toll.
My only point is that the argument that only GPL'd code is "free forever" is a bogus one.
As for your argument about the BSD license, BSD code is available only because there are people who neither believe in the GPL or in making all their changes proprietary. So as usual, an argument starting with "if everyone" isn't valid in a practical sense.
The philosphical difference between the two licenses is that the those who use the GPL want to control the destiny of other people's work if it's derived from theirs, while those who favor the BSD believe that their code is a gift to be used without strings attached.
"Then these projects could be easily killed of. Some company like (we know who) would easily take all the codes, incorporate all the features in their products, add a few of their own stuff, make it proprietary, and that's it. You wouldn't be able to compete with them"
So let's get this straight. Companies like MS aren't capable of competing without BSD-based code, but suddenly once they incorporate it into their own software they'll be able to add features and the original community will be unable to keep up with them and so the original project will be killed off. How does the community get so dumb and MS so smart?
The GPL is about promoting an idea to the exclusion of all others; touting it as a "solution" to some non-existent problem of BSD-style licenses is just FUD.
"This code must remain free for everyone in the future to benefit from."
This is the biggest deception of the "Free" software movement, that somehow BSD code can be made unavailable by having it incorporated into closed software.
The difference between the two licenses is that GPL-derived works must abide by the GPL while BSD-derived works don't have to. In both cases the original code is free forever, only the new code is affected by the differences in licensing.
I think there is a difference between using a general purpose library to produce a new product and using the source code from one product to produce a new product that essentially does the same thing.
Let's say I write two versions of a game called grand theft motorcycle. In one version I use a graphics library like Direct X but I don't use anybody's source code. Let's say the other version uses code from Grand Theft Auto. Which of the two would you consider closer to the definition of "from scratch"?
Anyway, I don't know how much Netscape code FF uses or what part in detail, so I can't make an absolute judgement, but it's clear that FF relied on Netscape code more than other browser makers.
"SUN still owns the Java standard, but has NOT introduced a "Java accelerator" nor has anyone else."
From Byte.com in November 1996:
"Sun is also dev eloping a more expensive (approximately $100) chip called ultraJava, which will be for desktop systems. Sun officials won't say whether or not ultraJava chips will use a picoJava core. However, these chips could include multimedia capabilities such as JPEG decompression and the graphics-processing optimizations now found in Sun's UltraSPARC RISC processors.
BYTE couldn't obtain actual silicon samples of Sun's Java chips at press time, so we don't know how well picoJava succeeds at boosting Java performance. According to Sun, these chips will run Java programs about 12 times faster than the same code executed by Sun's current Java interpreter."
"Microsoft added proprietary methods to java.lang.* classes in a blatant attempt to trick developers into writing unportable apps"
Were there really any developers who believed they were writing a portable application using J++ only to find when they released their product, that some of their customers couldn't run it in on a Unix machine?
Generally speaking there were primarily two kinds of developers at the time J++ was introduced: Those targeting Windows exclusively and writing their applications using tools running on Windows and those who cared about cross-platform apps and developed them on Unix.
The Unix folks had no interest developing applications using MS tools and the Windows folks had no interest in developing applications that ran on Unix. There were exceptions of course, but this was generally true.
And perhaps you're one of the very few who actually run java applications on your desktop, most people don't.
"and my Cell phone too"
Which has nothing to do with the Windows desktop.
"It's behind many many web sites"
Which also has nothing to do with the Windows desktop.
"Java makes it so easy to port from one platform to another that running Java on Windows is trivial. There are 1000's of Java apps that run on Windows"
The question is not whether one can create Java apps that run on Windows but rather whether developers use Java when their product is specifically required to run on Windows. In most cases, platform-independence is not required. Windows customers would much rather have a responsive product that runs only on Windows than a slower product that could run on a platform they have no intention to use.
"MS was trying to pirate the Java langauge and make it run on NOTHING BUT Windows by adding proprieraty extensions as part of the "Standard"."
My speculation is that once Standard Java was established and was popular on many platforms including Windows, Sun planned to sell proprietary hardware to accelerate Java's performance to native speeds. MS's Windows-specific implementation undermined that plan by making Java faster on Windows without special hardware, so Sun decided to fight them.
Slashdot Mirror
"We're in something of a historical anomaly right now, with a single OS having over 90% marketshare, and a single desktop CPU architecture having over 90% marketshare"
You're right about marketshare, but wrong about the implications. Although only a small percentage of applications are ported today, there's more porting today than there has ever been.
"All that said, if MacOS gets to 20% marketshare in a few years, wouldn't you like to have an easy port to that platform? What about Linux? Or, heaven forfend, Solaris? AIX?"
Porting is always harder then advertised. In addition, by the time the MacOS gets a 20% marketshare (if ever), today's application will be obsolete. Why make your product less competitive in its original environment in the hope that you'll be able to port it easily later?
Optimize for your initial market first and you might have the luxury of porting the application later.
"I can't believe that you have a five digit UID but have never installed Linux on a laptop before"
He must have cheated on the five digit qualifying exam.
"I really don't want to re-write the ENTIRE GUI for each platform I port my app to. Would you?"
That's a fine reason for the minority of applications what will be ported to other platforms, but what about the rest?
Is Java's only value it's (sort of) platform-independence? If not, why not offer the ability to use the native widgets in a straight-forward manner?
"If he is smart, he has confined all his platform specific code to a single library, or collection of libraries, with abstract interfaces."
That sounds like a good academic approach. It's a good professional approach too if there's a reasonable expectation that the application will be ported to another OS.
On the other hand, most applications will never be ported from the environment they started on and the extra effort and added complexity of adding a layer of abstraction that doesn't model the problem being solved isn't justified in those cases.
Even in those cases where the porting takes place, it's almost never as simple as just recompiling the code.
The question is whether you want to spend extra money and effort to pay today for what you may or may not need tomorrow.
The days when programmers were the key players in computer games development have long since passed (they probably ended at the time of the first industry crash).
have nothing to do with my post.
Small business, bulk hosting companies, and realy gigantic companies tend to roll their own Linux or use Free as in Beer distributions."
I guess you mean that the very, very, very tiny percentage of small businesses that use Linux didn't buy it or pay for support.
"Well but then you should be writing small modular utilites in your "C or C++" that can easily be piped together to form new and interesting things you maybe didn't even know people would want to do with your utility."
No!No!No! Unix's philosphy of stringing little programs together wasn't based on some brilliant general design concept, but rather on the limitations of computer systems of the time. Fully integrated applications weren't practical at that time because they wouldn't fit into memory.
Well, the command line can do almost anything as long as you're willing to turn your real work into the process of integrating a bunch of tiny commands into someting approaching what you need.
If I wanted to go to that much trouble, I'd just write a utility in C or C++ that did exactly what I wanted without messing around with shell commands.
"There is absolutely no excuse for a company like Google to allow employees/contractors to be locking the company's applications into a single platform proprietary API."
Isn't the real solution to keep the applications on the web server? Supporting Windows and Unix derivatives seems more like a dual platform strategy than a cross-platform one anyway. For web apps all that is required is a browser which is a an OS-agnostic requirement.
Yes, MS learned how to make a GUI-style word processor by writing one for the Mac (which made a lot of sense since it was the only popular GUI-based system at the time). Word for Macintosh was, however, created by MS, not Apple, so I don't see any great debt owed to Apple with respect to it.
Obviously Apple had smart enough talent to create their own full-featured word processor, but Applle must have decided that letting MS dominate was in their best interest at the time.
As for WordPerfect, they let their ego overcome their business sense and it cost them.
Well, I think the point is to be careful about one's analogies. If the analogy writer gets to narrowly interpret the analogy to support his point, it's not very illuminating.
The fact is that some people really like FF much better than IE, but comparing FF to a fine car and IE to a crappy one is just another way of saying you really like FF better. No additional information has been added via the analogy.
Sure, but I don't get your point. Perhaps you meant that the existence of the mac played a role in the success of microsoft since it provided them with another platform to develop for.
Perhaps he also won't admit (and neither will you, I imagine) that programs like MS Word played an important role in the success of the Mac as a viable tool for business.
I think it was very savvy of Jobs to buy the computer graphics division of LucasFilm to create Pixar, but it's John Lasseter who made Pixar what it is today.
One could argue that a large part of Pixar's success has been Job's willingness to stay out of day-to-day operations and concentrate on the business side.
"Well, if everyone decided to exploit the BSD code (ie, if all enchancements were closed), then the community would die. There isn't really much question of that."
At the risk of rephrasing what I already said, the fact that BSD code exists at all indicates that the "if all enhancements were closed" scenario is very unlikely to occur. If people are motivated to create BSD code in the first place knowing that some enhancements will be closed, then they won't mind making enhancements under the same conditions.
Having said that, the pro-GPL forces have waged a very successful disinformatoin campaign against the BSD and it has taken its toll.
My only point is that the argument that only GPL'd code is "free forever" is a bogus one.
As for your argument about the BSD license, BSD code is available only because there are people who neither believe in the GPL or in making all their changes proprietary. So as usual, an argument starting with "if everyone" isn't valid in a practical sense.
The philosphical difference between the two licenses is that the those who use the GPL want to control the destiny of other people's work if it's derived from theirs, while those who favor the BSD believe that their code is a gift to be used without strings attached.
"Then these projects could be easily killed of. Some company like (we know who) would easily take all the codes, incorporate all the features in their products, add a few of their own stuff, make it proprietary, and that's it. You wouldn't be able to compete with them"
So let's get this straight. Companies like MS aren't capable of competing without BSD-based code, but suddenly once they incorporate it into their own software they'll be able to add features and the original community will be unable to keep up with them and so the original project will be killed off. How does the community get so dumb and MS so smart?
The GPL is about promoting an idea to the exclusion of all others; touting it as a "solution" to some non-existent problem of BSD-style licenses is just FUD.
"This code must remain free for everyone in the future to benefit from."
This is the biggest deception of the "Free" software movement, that somehow BSD code can be made unavailable by having it incorporated into closed software.
The difference between the two licenses is that GPL-derived works must abide by the GPL while BSD-derived works don't have to. In both cases the original code is free forever, only the new code is affected by the differences in licensing.
I think there is a difference between using a general purpose library to produce a new product and using the source code from one product to produce a new product that essentially does the same thing.
Let's say I write two versions of a game called grand theft motorcycle. In one version I use a graphics library like Direct X but I don't use anybody's source code. Let's say the other version uses code from Grand Theft Auto. Which of the two would you consider closer to the definition of "from scratch"?
Anyway, I don't know how much Netscape code FF uses or what part in detail, so I can't make an absolute judgement, but it's clear that FF relied on Netscape code more than other browser makers.
"SUN still owns the Java standard, but has NOT introduced a "Java accelerator" nor has anyone else."
From Byte.com in November 1996:
"Sun is also dev eloping a more expensive (approximately $100) chip called ultraJava, which will be for desktop systems. Sun officials won't say whether or not ultraJava chips will use a picoJava core. However, these chips could include multimedia capabilities such as JPEG decompression and the graphics-processing optimizations now found in Sun's UltraSPARC RISC processors.
BYTE couldn't obtain actual silicon samples of Sun's Java chips at press time, so we don't know how well picoJava succeeds at boosting Java performance. According to Sun, these chips will run Java programs about 12 times faster than the same code executed by Sun's current Java interpreter."
"Microsoft added proprietary methods to java.lang.* classes in a blatant attempt to trick developers into writing unportable apps"
Were there really any developers who believed they were writing a portable application using J++ only to find when they released their product, that some of their customers couldn't run it in on a Unix machine?
Generally speaking there were primarily two kinds of developers at the time J++ was introduced: Those targeting Windows exclusively and writing their applications using tools running on Windows and those who cared about cross-platform apps and developed them on Unix.
The Unix folks had no interest developing applications using MS tools and the Windows folks had no interest in developing applications that ran on Unix. There were exceptions of course, but this was generally true.
Should this story be about the latest trends in hammers and screwdrivers?
"There's a reason CS programs don't allow IDE's to begin with."
Is it because many CS professors learned to program before IDE's were available and haven't done any real-world work since then?
"I have it on my XP desktop right now"
And perhaps you're one of the very few who actually run java applications on your desktop, most people don't.
"and my Cell phone too"
Which has nothing to do with the Windows desktop.
"It's behind many many web sites"
Which also has nothing to do with the Windows desktop.
"Java makes it so easy to port from one platform to another that running Java on Windows is trivial. There are 1000's of Java apps that run on Windows"
The question is not whether one can create Java apps that run on Windows but rather whether developers use Java when their product is specifically required to run on Windows. In most cases, platform-independence is not required. Windows customers would much rather have a responsive product that runs only on Windows than a slower product that could run on a platform they have no intention to use.
"MS was trying to pirate the Java langauge and make it run on NOTHING BUT Windows by adding proprieraty extensions as part of the "Standard"."
My speculation is that once Standard Java was established and was popular on many platforms including Windows, Sun planned to sell proprietary hardware to accelerate Java's performance to native speeds. MS's Windows-specific implementation undermined that plan by making Java faster on Windows without special hardware, so Sun decided to fight them.