Nobody here really doubts MS's abililty to execute Are you joking me? The last time MS built this level of hype was for Windows NT 5.0 (Cairo), and the end result (Windows 2000), was hugely cut-down. A lot of the technologies going into Longhorn were supposed to be in Cairo!
"So-n-So wrote a paper" or "Here's a sourceforge project" looks a little thin. None of these are sourceforge projects, or papers. They are real implementations available from well-established projects, like DRI, X.org, and freedesktop.org. As for adoption, GTK+ integration of Cairo is already in the works, and Trolltech has already released a developer's preview of Qt 4.0 that features an OpenGL-accelerated graphics engine. As long as GTK+ and Qt are on the boat (and, by extension, KDE and GNOME), you've got all the adoption you need.
1) How is the OSS stuff any more vaporware than Longhorn? It's "in progress" just like Longhorn is "in progress." Or do you have a release version of Longhorn that nobody else does?
2) The new graphics stuff isn't in the PDC beta. The new UI was shown only in Bill G's keynote --- it was stripped from the 4051 build given to attendees. The new OSS graphics stuff is actually available for download.
There is absolutely no point at all to this article. He started with a 3998 byte program, and ended with a 45 byte one. The kicker is, when the OS loads the program into ram, it'll stick both in a 4096 byte page! All he accomplished was to make that page mostly full of zero-fill padding!
Since nobody is actually going to waste their time doing this for programs large enough that the padding doesn't kill the gain, what's the point?
I'm not saying that having a massive standard library is a bad thing. Indeed, Lisp was one of the first languages to have a larger-than-usual standard library (most of it's 1000-page standard covers it's library, rather than the language). However, the problem is that a large standard library masks the deficiencies of the language. If you're doing something that has no pre-canned solution, you've got to deal with Java the language, not Java the platform. Java, as a language, is not very impressive at all.
This is bad because Java can get away with being a crappier language, because it's class library eases most of the pain. However, the minute you need to do something that doesn't have a pre-canned solution (eg: anything I do at work, which is totally out of Java's network-programming niche), then you have to deal with the limitations of the language itself.
I'm not going to say that Java is bad, it's just that it's rather limited. It get's the job done for a certain type of thing, but it's way more work in many cases than doing something another way. With regards to abstraction --- Java only let's you do abstractions that fit the classical OOP model. If you need a functional abstraction, then you're stuck.
Let me give you a couple of examples:
1) Mandatory strong typing (without type inference) is a PITA. When I'm doing incremental development, and lot's of refactoring, etc, I don't want to deal with making the type-checker happy. In particular, when I'm working on "hard" problems (100 lines of code that take a week to write because it solves a complicated problem), I want to concentrate more on the problem than on the language. When I'm done with that, I can go ahead and add type declarations to my interfaces if I think that somebody might make a mistake down the road. Even then, there is no point in adding type declarations to local variables in a code body, because the compiler can usually figure that out itself, and since I never write functions over a page long, you know what all the types will be anyway.
2) Java lacks some key features that make it a pain to use. It has no lambdas, which means that instead of using clean abstractions like "apply this function to each element in the list," you have to use more verbose abstractions like "get the bounds of the list; iterate from the beginning of the list to the end of the list; for each list position, lookup the item at that position and apply this function to it." It also lacks multimethods (polymorphic dispatch on more than one argument), which necessitates complicated techniques like the visitor pattern.
Oh, P.S. Don't start sputtering crap about how the prices go down (or stay down) from overseas manufacturing. The only thing that changes by shipping overseas is the profit margin for the folks on top.
Translation: "I don't want to hear about all the theoretical and empirical benefits of free trade --- I want to keep believing my little fantasy about the benefits of hampering free trade."
The "folks on top" are people, just like you and me. They have the freedom, as American citizens, to hire whomever the hell they want to hire. You don't like it? Start your own company and hire who *you* want to hire. That's how a free country works!
It's not a matter of precanned solutions being good enough. Precanned solutions are a great idea. I *wish* Lisp had a library as huge as Java's. However, the real question is whether a language can still shine, without pre-canned solutions, in cases where pre-canned solutions aren't available. Java's library is a big help when you're doing network programming, but it's much less so when you're doing (say) scientific programming. At that point, Java's library is no better than any other language's, and you have to deal with the limitations of the language itself.
The market advantages of a technology are orthogonal to the technical advantages of a technology. So market factors do (and should), play a role in the overall decision, but they don't have any bearing on whether a technology is "better" or "worse." Also, you can't try to mush market factors along with practical values. There are theoretical values, practical values, and market forces. They are all seperate things. There are lot's of technologies that have the first two, but not the third.
More generally, market forces tend to be somewhat random and timing-dependent, a matter of chance. Say, for example, you can have a worse technology immediately, or a better technology in a year. If you're going to have to live with that technology for the next decade, it'd be logical to wait the year. However, for marketing reasons, the worse technology tends to get picked, and programmers have to live with worse technology for the next decade. A year down the line, when the better technology is fully developed, but programmers are stuck using the worse one, it is not surprising that they might be a bit frustrated, especially because the original marketing factors are no longer applicable to them.
You've never seen my code, so don't comment. Java is a halfway-decent language for OOP, but it does not get out of your way. It beats you over the head with it's limitations at every step, forcing you to deal with a primitive type system, constraining object model, limited control constructs, and limited ability to write any abstractions that don't fit a very narrow paradigm.
And Lisp for a videogame is hardly showing off -- commercial games have been written quite well in Lisp. Remember --- most games today are hybrids, with a low-level core in C and the bulk of the game logic in a higher-level scripting language. Since you can get C-like performance out of Lisp, and it works just great as a scripting language, it makes a great deal of sense to write games in Lisp!
I'm sorry, but Graham's dismissive attitude towards Java is evidence of extreme arrogance. Perhaps arrogance, but also perhaps frustration. To anybody familiar with a broad variety of languages, the ascendance of Java (and C#, which is Java + 1) is irritating at best. Here you have a language that finally managed to overcome the entrentched nature of C/C++, but is at best one step backwards for each step forwards. It's got shades of Smalltalk, but none of it's flexibility; shades of Self but none of it's innovation; shades of C++ but none of it's control. It's not particularly good at anything (but not particularly bad), nor is it a good all-rounder. Certainly, it's decades behind the state of the art compared to something like Lisp, or Smalltalk. The main reason Java got popular was hype, chance (the rise of network computing), and a giant class library that had pre-canned solutions for most things. Put simply, it was an example of worse technology winning out over better technology, for market reasons.
Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast. Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.
I don't think you are understanding the purpose of a standard. I don't think you understand the purpose of a standard. The library standard defines what libraries all C++ implementations must support. The standard is there to allow programmers to assume that certain services are available on all implementations. The standard is not there to force all programmers to use a certain set of services that may not necessarily be the best ones to use.
The STL and Trolltech's containers are totally different. The STL is homogeneous and value-oriented. Trolltech's containers are heterogeneous and reference oriented. Trolltech is defining their own containers not because they want to, but because the STL doesn't encompass what they are trying to do.
Qt doesn't use "non-standard" C++. You can write Qt code in regular C++ code --- moc simply writes a lot of boiler-plate for you. What you're complaining about is not that Qt uses non-standard C++ (since it doesn't), but that it doesn't use the STL style of programming. However, given that C++ is a multiparadigm language, that's perfectly valid.
GUIs are inherently object-oriented and amenable to dynamic programming techniques. That's why people like Objective-C (Cocoa), and Smalltalk so much for GUI programming. The STL style of C++ is very anti OOP and anti dynamic programming. Indeed, the creator of the STL, Alexander Stepanov, has said OOP is a hoax. While Stepanov is entitled to his opinion, and the STL is certainly useful for a wide range of tasks, it's silly to try to shoe-horn Qt into a programming style that doesn't fit it's problem domain.
Name MS Excel "Spreadsheet" Name MS Word "Word Processor" Name MS PowerPoint "Presentation Maker" Name MS Internet Explorer "Web Browser" Name MS Access "Sucky Database Wannabe"
But that's my point exactly! I simply said that Apple cut some corners in order to get the G5's price down. It's not a matter of "the G5 is $3000 because it uses higher-quality hardware" (except for a few pieces, it doesn't), but a matter of "the G5 manages to be only $3000 because it cut's some corners."
"Onboard sound" doesn't mean that the tower comes without sound. It means that it uses a sound-chip integrated on the motherboard instead of a full, separate sound card. Onboard sound is usually something you find on cheap PCs, because it saves $30-$50 on the machine. Onboard sound is almost always worse than a separate sound card because the sensitive analog components of the soundcard are closer to the noisy digital circuits of the motherboard and CPU.
I was a Liinux newbie once, and I've never gotten condescending attitude back. You just have to know how to ask nicely. Depending on your situation, you could ask a lot of places. The gentoo forums are extremely helpful, as are the various mailing lists. Linuxquestions.org is a good place to start. The various mailing lists (KDE's, GNOME's, distro-specific ones) are also good places. Hell, if you want, e-mail me:
The core platform software is a gateway to a huge amount of free knowledge. Consider the Debian software lineup and the things it allows:
- Internet access - Viewers for all the file formats found on the internet - Image editing (for prospective artists) - Office software (for prospective paper pushers) - Publishing software (for prospective writers) - Development software (for prospective programmers)
It's like a library, and there is great value in making it free and accessible.
Slashdot Mirror
Nobody here really doubts MS's abililty to execute
Are you joking me? The last time MS built this level of hype was for Windows NT 5.0 (Cairo), and the end result (Windows 2000), was hugely cut-down. A lot of the technologies going into Longhorn were supposed to be in Cairo!
"So-n-So wrote a paper" or "Here's a sourceforge project" looks a little thin.
None of these are sourceforge projects, or papers. They are real implementations available from well-established projects, like DRI, X.org, and freedesktop.org. As for adoption, GTK+ integration of Cairo is already in the works, and Trolltech has already released a developer's preview of Qt 4.0 that features an OpenGL-accelerated graphics engine. As long as GTK+ and Qt are on the boat (and, by extension, KDE and GNOME), you've got all the adoption you need.
The current Longhorn previews don't include the new graphics stuff. That's slated for the Longhorn beta in 2005.
1) How is the OSS stuff any more vaporware than Longhorn? It's "in progress" just like Longhorn is "in progress." Or do you have a release version of Longhorn that nobody else does?
2) The new graphics stuff isn't in the PDC beta. The new UI was shown only in Bill G's keynote --- it was stripped from the 4051 build given to attendees. The new OSS graphics stuff is actually available for download.
Um, OSS already has:
1) An X server that does transparency and double-buffering;
2) An (actually, 2) OpenGL-accelerated canvas;
3) A window manager that uses said canvas.
Sure, they are still "in progress" releases, but you can actually download them and try them out, which is way more than can be said for Longhorn.
Open source will handle this challenge quite fine. It's not a unified effort, but all the pieces are falling into place:
1) OpenGL 2.0 should easily be a match for whatever the successor to Direct 3D is. A lot stuff mentioned in the article is also in OpenGL 2.0.
2) The freedesktop.org folks are working on building an X server that sits on top of OpenGL.
3) Some DRI folks are working on an OpenGL implementation that can operate without the X server, to support using the X server on top of it.
There is absolutely no point at all to this article. He started with a 3998 byte program, and ended with a 45 byte one. The kicker is, when the OS loads the program into ram, it'll stick both in a 4096 byte page! All he accomplished was to make that page mostly full of zero-fill padding!
Since nobody is actually going to waste their time doing this for programs large enough that the padding doesn't kill the gain, what's the point?
Microsoft owns only 9% of Softimage.
The *used* to own all of Softimage, but since 1998, they just invest in them.
I'm not saying that having a massive standard library is a bad thing. Indeed, Lisp was one of the first languages to have a larger-than-usual standard library (most of it's 1000-page standard covers it's library, rather than the language). However, the problem is that a large standard library masks the deficiencies of the language. If you're doing something that has no pre-canned solution, you've got to deal with Java the language, not Java the platform. Java, as a language, is not very impressive at all.
This is bad because Java can get away with being a crappier language, because it's class library eases most of the pain. However, the minute you need to do something that doesn't have a pre-canned solution (eg: anything I do at work, which is totally out of Java's network-programming niche), then you have to deal with the limitations of the language itself.
I'm not going to say that Java is bad, it's just that it's rather limited. It get's the job done for a certain type of thing, but it's way more work in many cases than doing something another way. With regards to abstraction --- Java only let's you do abstractions that fit the classical OOP model. If you need a functional abstraction, then you're stuck.
Let me give you a couple of examples:
1) Mandatory strong typing (without type inference) is a PITA. When I'm doing incremental development, and lot's of refactoring, etc, I don't want to deal with making the type-checker happy. In particular, when I'm working on "hard" problems (100 lines of code that take a week to write because it solves a complicated problem), I want to concentrate more on the problem than on the language. When I'm done with that, I can go ahead and add type declarations to my interfaces if I think that somebody might make a mistake down the road. Even then, there is no point in adding type declarations to local variables in a code body, because the compiler can usually figure that out itself, and since I never write functions over a page long, you know what all the types will be anyway.
2) Java lacks some key features that make it a pain to use. It has no lambdas, which means that instead of using clean abstractions like "apply this function to each element in the list," you have to use more verbose abstractions like "get the bounds of the list; iterate from the beginning of the list to the end of the list; for each list position, lookup the item at that position and apply this function to it." It also lacks multimethods (polymorphic dispatch on more than one argument), which necessitates complicated techniques like the visitor pattern.
Oh, P.S. Don't start sputtering crap about how the prices go down (or stay down) from overseas manufacturing. The only thing that changes by shipping overseas is the profit margin for the folks on top.
Translation: "I don't want to hear about all the theoretical and empirical benefits of free trade --- I want to keep believing my little fantasy about the benefits of hampering free trade."
The "folks on top" are people, just like you and me. They have the freedom, as American citizens, to hire whomever the hell they want to hire. You don't like it? Start your own company and hire who *you* want to hire. That's how a free country works!
It's not a matter of precanned solutions being good enough. Precanned solutions are a great idea. I *wish* Lisp had a library as huge as Java's. However, the real question is whether a language can still shine, without pre-canned solutions, in cases where pre-canned solutions aren't available. Java's library is a big help when you're doing network programming, but it's much less so when you're doing (say) scientific programming. At that point, Java's library is no better than any other language's, and you have to deal with the limitations of the language itself.
The market advantages of a technology are orthogonal to the technical advantages of a technology. So market factors do (and should), play a role in the overall decision, but they don't have any bearing on whether a technology is "better" or "worse." Also, you can't try to mush market factors along with practical values. There are theoretical values, practical values, and market forces. They are all seperate things. There are lot's of technologies that have the first two, but not the third.
More generally, market forces tend to be somewhat random and timing-dependent, a matter of chance. Say, for example, you can have a worse technology immediately, or a better technology in a year. If you're going to have to live with that technology for the next decade, it'd be logical to wait the year. However, for marketing reasons, the worse technology tends to get picked, and programmers have to live with worse technology for the next decade. A year down the line, when the better technology is fully developed, but programmers are stuck using the worse one, it is not surprising that they might be a bit frustrated, especially because the original marketing factors are no longer applicable to them.
You've never seen my code, so don't comment. Java is a halfway-decent language for OOP, but it does not get out of your way. It beats you over the head with it's limitations at every step, forcing you to deal with a primitive type system, constraining object model, limited control constructs, and limited ability to write any abstractions that don't fit a very narrow paradigm.
And Lisp for a videogame is hardly showing off -- commercial games have been written quite well in Lisp. Remember --- most games today are hybrids, with a low-level core in C and the bulk of the game logic in a higher-level scripting language. Since you can get C-like performance out of Lisp, and it works just great as a scripting language, it makes a great deal of sense to write games in Lisp!
I'm sorry, but Graham's dismissive attitude towards Java is evidence of extreme arrogance.
Perhaps arrogance, but also perhaps frustration. To anybody familiar with a broad variety of languages, the ascendance of Java (and C#, which is Java + 1) is irritating at best. Here you have a language that finally managed to overcome the entrentched nature of C/C++, but is at best one step backwards for each step forwards. It's got shades of Smalltalk, but none of it's flexibility; shades of Self but none of it's innovation; shades of C++ but none of it's control. It's not particularly good at anything (but not particularly bad), nor is it a good all-rounder. Certainly, it's decades behind the state of the art compared to something like Lisp, or Smalltalk. The main reason Java got popular was hype, chance (the rise of network computing), and a giant class library that had pre-canned solutions for most things. Put simply, it was an example of worse technology winning out over better technology, for market reasons.
What's happened in the last 7 years? As far as I can see, it's static languages (Java, C#) that have been hogging the spot-light in that time.
Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast. Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.
I don't think you are understanding the purpose of a standard.
I don't think you understand the purpose of a standard. The library standard defines what libraries all C++ implementations must support. The standard is there to allow programmers to assume that certain services are available on all implementations. The standard is not there to force all programmers to use a certain set of services that may not necessarily be the best ones to use.
The STL and Trolltech's containers are totally different. The STL is homogeneous and value-oriented. Trolltech's containers are heterogeneous and reference oriented. Trolltech is defining their own containers not because they want to, but because the STL doesn't encompass what they are trying to do.
Qt doesn't use "non-standard" C++. You can write Qt code in regular C++ code --- moc simply writes a lot of boiler-plate for you. What you're complaining about is not that Qt uses non-standard C++ (since it doesn't), but that it doesn't use the STL style of programming. However, given that C++ is a multiparadigm language, that's perfectly valid.
GUIs are inherently object-oriented and amenable to dynamic programming techniques. That's why people like Objective-C (Cocoa), and Smalltalk so much for GUI programming. The STL style of C++ is very anti OOP and anti dynamic programming. Indeed, the creator of the STL, Alexander Stepanov, has said OOP is a hoax. While Stepanov is entitled to his opinion, and the STL is certainly useful for a wide range of tasks, it's silly to try to shoe-horn Qt into a programming style that doesn't fit it's problem domain.
I wish Microsoft would do this too. Eg:
Name MS Excel "Spreadsheet"
Name MS Word "Word Processor"
Name MS PowerPoint "Presentation Maker"
Name MS Internet Explorer "Web Browser"
Name MS Access "Sucky Database Wannabe"
But that's my point exactly! I simply said that Apple cut some corners in order to get the G5's price down. It's not a matter of "the G5 is $3000 because it uses higher-quality hardware" (except for a few pieces, it doesn't), but a matter of "the G5 manages to be only $3000 because it cut's some corners."
"Onboard sound" doesn't mean that the tower comes without sound. It means that it uses a sound-chip integrated on the motherboard instead of a full, separate sound card. Onboard sound is usually something you find on cheap PCs, because it saves $30-$50 on the machine. Onboard sound is almost always worse than a separate sound card because the sensitive analog components of the soundcard are closer to the noisy digital circuits of the motherboard and CPU.
I was a Liinux newbie once, and I've never gotten condescending attitude back. You just have to know how to ask nicely. Depending on your situation, you could ask a lot of places. The gentoo forums are extremely helpful, as are the various mailing lists. Linuxquestions.org is a good place to start. The various mailing lists (KDE's, GNOME's, distro-specific ones) are also good places. Hell, if you want, e-mail me:
gtg990h@mail.gatech.edu
The core platform software is a gateway to a huge amount of free knowledge. Consider the Debian software lineup and the things it allows:
- Internet access
- Viewers for all the file formats found on the internet
- Image editing (for prospective artists)
- Office software (for prospective paper pushers)
- Publishing software (for prospective writers)
- Development software (for prospective programmers)
It's like a library, and there is great value in making it free and accessible.