C++ has many good libraries to solve problem like "string" and "memory management." The problem is they are libraries rather than language constructs. For example, shared pointer is a good thing, the problem is, because it is not language constructs, different third party libraries in your program may use different shared pointers mixed with raw pointers which makes the reference counting as unmanageable as they had not existed.
I doubt that. Many languages invented before Java have already been qualified to fulfill cross-platform requirement in almost all fields except GUI. And look Java did what to GUI? Almost nothing. Java's GUI sucks, and instead of providing cross-platform, it created a new platform (recommend the use of Metal Look-and-Feel?). If your whole solution to make people working on two platforms feel better is to create the third platform, what's your point? Does people who are willing to get unified user experience have to pay money to Microsoft and Sun and Apple, and then resort to Java to get the same Look-and-Feel?
More over, all users I encountered, except developers, using one single OSs dominantly. So if you want to offer your app on multiple platforms, good, but only make the functionality cross-platform, not the user experience at the GUI level. Your cross-platform app is meant to make the same functionality accessible from different OSs, not to enforce the users of an OS experience what they should feel in another, or worse, in another new.
I think some people eventually realize GUI is of so high level of complexity and all different GUIs of different OSs can not be abstracted with a unified model in such detailed level like Java Swing.
So write once, test everywhere, for non-GUI? OK, C and other language already do that.
For GUI? No improvement from Java.
Chrome OS is pointless, even when I haven't seen it is in a finished state because it is for sure Chrome OS is a subset of a typical Linux distro. Any Linux distro with careful customization and running a browser (if you insist Chrome is fastest, you could even run Chrome Browser) is better than Chrome OS.
True. And I think apps should make more use of the underlying mechanism provided by OS, like configuring their one non-login user with limited previlige to start sandbox process, instead of implementing their own sandbox mechanism. In-process sandbox is a bad design, as what Applet did, because it reinvents whole wheel whereas OS provides process boundary.
On the other hand, even app does not provide sandbox, a user can always configure some low-previlige user by his/her own. That may be a too hard requirement for users, but better than wait.
which of course still allows 65% CPU for any other tasks -- You don't take count into responsiveness. Yes, you still have 65% for other tasks. But that means the point at which your "other tasks"assigned is likely to fall into the duration of 35% and therefore those "other tasks" must wait a while for those 65% comes. If you want your CPU be utilized more than 50%, then you should not use any interactive UI applications, you should treat your machine like an old time batch-processing monster.
To put everything in a marked language standard is really a bad idea. If want to replace Flash, replace it with another better-design or more open PLUG-IN. Plug-in model is how software can be built by collaborative organizations and how each component remains clean-designed and well-maintained.
I am not sure how much the probability that FireFox change an image from a server. According to my experience it rarely change the original images. Does GIMP always download the image from the server? If so, either FireFox or GIMP is not very smart. In most cases, they should exchange the information of local copy of the images as long as the image is not changed.
A pure technical problem (by "pure technical" I mean a problem purely caused by developers) is usually much less difficult to fix than most people originally thought. And problems caused by culture or management are difficult to fix. A culture encourage transparency and don't blame developer usually encourage developers not covering problems in their code, and encourages a developer benevolently fix problems introduced by others. A culture that blames developer for every single defect in the code, make them cover mistakes, not admit problem by any excuses, not let others tough their own code, and not tough other's code, either.
You're kidding, right? We're talking about the kernel that doesn't bother with unit tests or actual release cycles, and which thinks that "our users find our bugs" is a good replacement for a QA process?
You don't quiet know how MS work. Most of a QA process is a black-box process. A tester can make a voice only when she/he can produce a bug appearing to the outside of software. Actually, "out-users-(who-have-the-code)-find-our-bugs" is a way better method to find bugs than a QA process. In modern software company, QA process is more about politic than quality. Testers gain good performance by filing more bugs. Programmers gain good performance by preventing testers from filing more bugs. How programmers do so? By excessive design test. Basic design test is good, but why duplicate more than 70% test cases between a programmer and a tester? It's a waste of resource. And also, it's some vanity to prevent software company from pushing their software as early to users as possible. Google's way is right, to push even alpha version to users (but warn them don't download it unless they know what they are really doing. And, one thing, Google implement that alpha version for Mac/Linux too slow, just a complain about the speed, not the methodology).
It's like saying modern engineers can learn something from examining rusty old steam engines.
Sometimes computer is crude than a steam engine. Say today any crappy car with a poor-designed chassis can pass through a curve way with the help of a ABS system. But that's way ugly than the feeling of a well-designed chassis.
Slashdot Mirror
C++ has many good libraries to solve problem like "string" and "memory management." The problem is they are libraries rather than language constructs. For example, shared pointer is a good thing, the problem is, because it is not language constructs, different third party libraries in your program may use different shared pointers mixed with raw pointers which makes the reference counting as unmanageable as they had not existed.
A(n open source and portable) file system is hardly the reason you stick with a whole OS.
I doubt that. Many languages invented before Java have already been qualified to fulfill cross-platform requirement in almost all fields except GUI. And look Java did what to GUI? Almost nothing. Java's GUI sucks, and instead of providing cross-platform, it created a new platform (recommend the use of Metal Look-and-Feel?). If your whole solution to make people working on two platforms feel better is to create the third platform, what's your point? Does people who are willing to get unified user experience have to pay money to Microsoft and Sun and Apple, and then resort to Java to get the same Look-and-Feel?
More over, all users I encountered, except developers, using one single OSs dominantly. So if you want to offer your app on multiple platforms, good, but only make the functionality cross-platform, not the user experience at the GUI level. Your cross-platform app is meant to make the same functionality accessible from different OSs, not to enforce the users of an OS experience what they should feel in another, or worse, in another new.
I think some people eventually realize GUI is of so high level of complexity and all different GUIs of different OSs can not be abstracted with a unified model in such detailed level like Java Swing.
So write once, test everywhere, for non-GUI? OK, C and other language already do that. For GUI? No improvement from Java.
Chrome OS is pointless, even when I haven't seen it is in a finished state because it is for sure Chrome OS is a subset of a typical Linux distro. Any Linux distro with careful customization and running a browser (if you insist Chrome is fastest, you could even run Chrome Browser) is better than Chrome OS.
Choose any Linux distro that can run Chrome Browser would be a better solution than choose Chrome OS.
True. And I think apps should make more use of the underlying mechanism provided by OS, like configuring their one non-login user with limited previlige to start sandbox process, instead of implementing their own sandbox mechanism. In-process sandbox is a bad design, as what Applet did, because it reinvents whole wheel whereas OS provides process boundary.
On the other hand, even app does not provide sandbox, a user can always configure some low-previlige user by his/her own. That may be a too hard requirement for users, but better than wait.
There was one time people bought resistances, capacitances, and transistors to build up their own circuit.
which of course still allows 65% CPU for any other tasks -- You don't take count into responsiveness. Yes, you still have 65% for other tasks. But that means the point at which your "other tasks"assigned is likely to fall into the duration of 35% and therefore those "other tasks" must wait a while for those 65% comes. If you want your CPU be utilized more than 50%, then you should not use any interactive UI applications, you should treat your machine like an old time batch-processing monster.
To put everything in a marked language standard is really a bad idea. If want to replace Flash, replace it with another better-design or more open PLUG-IN. Plug-in model is how software can be built by collaborative organizations and how each component remains clean-designed and well-maintained.
That's exactly what I was saying.
You'd better write IBM a nasty letter for its losing PPC to Intel.
Non-UNIX OSes are all dying. Those taking more ideas are dying more slowly than those taking less, until they become UNIX completely.
Yeah, and Linux is new Apple along with that reasoning.
And what's to stop people from simply installing a tiny key logging chip inside your keyboard?
Now they know the cost. From now on, designers must be aware of the support cost incurred by install every individual piece of unnecessary chip.
I am not sure how much the probability that FireFox change an image from a server. According to my experience it rarely change the original images. Does GIMP always download the image from the server? If so, either FireFox or GIMP is not very smart. In most cases, they should exchange the information of local copy of the images as long as the image is not changed.
A pure technical problem (by "pure technical" I mean a problem purely caused by developers) is usually much less difficult to fix than most people originally thought. And problems caused by culture or management are difficult to fix. A culture encourage transparency and don't blame developer usually encourage developers not covering problems in their code, and encourages a developer benevolently fix problems introduced by others. A culture that blames developer for every single defect in the code, make them cover mistakes, not admit problem by any excuses, not let others tough their own code, and not tough other's code, either.
You're kidding, right? We're talking about the kernel that doesn't bother with unit tests or actual release cycles, and which thinks that "our users find our bugs" is a good replacement for a QA process?
You don't quiet know how MS work. Most of a QA process is a black-box process. A tester can make a voice only when she/he can produce a bug appearing to the outside of software. Actually, "out-users-(who-have-the-code)-find-our-bugs" is a way better method to find bugs than a QA process. In modern software company, QA process is more about politic than quality. Testers gain good performance by filing more bugs. Programmers gain good performance by preventing testers from filing more bugs. How programmers do so? By excessive design test. Basic design test is good, but why duplicate more than 70% test cases between a programmer and a tester? It's a waste of resource. And also, it's some vanity to prevent software company from pushing their software as early to users as possible. Google's way is right, to push even alpha version to users (but warn them don't download it unless they know what they are really doing. And, one thing, Google implement that alpha version for Mac/Linux too slow, just a complain about the speed, not the methodology).
It's like saying modern engineers can learn something from examining rusty old steam engines.
Sometimes computer is crude than a steam engine. Say today any crappy car with a poor-designed chassis can pass through a curve way with the help of a ABS system. But that's way ugly than the feeling of a well-designed chassis.
If the driver code is licensed under GPL, should the whole OS kernel of Zune be licensed under GPL enforcedly?