Instead of blaming all of world's ills on Vista, let's look at the real reasons:
1. Desktop power users are still mostly on 32-bit machines where you are limited by the available address space. I've gone through three laptops during the last four years and they were all 2GB machines. Even though I'd like to buy one with more RAM I can't. (Yes I know about the Windows 3GB switch but that has its problems on the desktop.)
2. Regular users are perfectly happy with what they have. Their machines work well for browsing, email, media playing and file sharing so they see no need to update to a new computer with more RAM.
As the article states, it's straightforward to write an Expose clone in Vista. I've done it and my biggest headache was implementing a linpacking 2d algorithm to layout the windows in a manner that's pleasing to the eye. I assume Microsoft didn't because they were afraid of stepping on one of Apple's numerous patents.
There is a problem with Vista's thumbnail API, btw. After a window has been minimized for a while, Vista's unable to render its thumbnail and instead it just renders the non-client portion of the window and sticks a large window icon at its center.
I assume they are doing that to minimize the process' working set, but it still sucks if you want to support advanced Expose functionality like drag and drop.
Having access to the source code is not a solution to this problem. Ken Thompson has demonstrated that in his paper Reflections on Trusting Trust twenty years ago.
To really fix the problem we need to leverage the one thing that all modern operating systems (including Windows) do right at the core level - access control. Why would anybody want to run a codec at the privilege level of the program that's using it? Why not run it under an account where it can't touch anything except its input and output streams? (This doesn't have anything to do with whether you are logged in as admin/root. Even if you are not an admin you don't want the codec to upload your documents somewhere.)
A related issue is installation programs. We need to make these declarative instead of executable. As it is right now, you run installations as an admin/root, and give them the rein to do anything. God knows what goes on in those MSIs and makefiles. If these were declarative then setups would declare at the beginning what kind of access they need (simple installation, shared component installation, mucking with the system, codec, &c) and you would be able to make a finer grade decision on whether you want to let them run.
> I did not HAVE "DOS and Win3.1 stuff", I had been using Linux on my > first PC (4M RAM) for 18 months.
In that case it was a product that didn't suit your needs. But running DOS and Win 3.1 apps that they had was a requirement for most people, and being able to compile their Win 3.1 apps to the new OS without requiring much change was a requirement for most software vendors. Windows 95 gave you that, Linux didn't.
Linux thus had more memory at its disposal as it didn't have to execute compatibility thunks, plus it had a lot less features at the time. So it had room to do other tasks better and faster.
Was Windows 95 a cludge? Certainly. But you try to pack all those features into 4MB and you'll have to make compromises too. It just a basic fact of software engineering.
Every software product is rushed. Nothing large is ever released perfect, there are always known problems and things you could have done better.
As for Windows, the NT line has always been pretty solid. You could always install RC1 and expect it to work normally with maybe a driver going crazy every few days. Final releases were always an improvement in overall user experience from the previous version. (Though not an improvement in overall stability as it's pretty hard to beat the previous version that has been through every imaginable scenario on millions of computers.)
Vista seems to be another story. If you analyze the Beta and RC timeline of every NT-line OS up to now, you see that Vista is abberation. It's pretty obvious that Microsoft is lowering its standards in order to push the product out, and that's just going to turn around and bite it in the ass.
Service packs: They are a mix of patches and new functionality. We also do that in the Linux world, just in smaller steps as there is less to worry about compatibility and localization.
And stop badgering Windows 95. It looks lame now but it kicked ass on 4 MB computers with broken hardware back in 95. It ushered process isolation many years before Macs got it. It ushered a reasonably good UI many years before Linux got it. Plug & Play, ugly as it was, brought the end to fiddling with jumpers which is something that 99 percent of the population doesn't know how to do. It ran all your DOS and Win 3.1 stuff. So go easy on it. It may suck by today's standards, but in that day and age it was miles better than any of the alternatives.
I use them. References are mostly used for passing things by reference, but that's worthless for data structures. (Plus, they tend to play badly with templates.) Consider a case where you have two hashes that use mostly the same basic_strings as keys. Those two are going to either store separate copies or do reference counting on strings, which, as I explained, are both bad for performance as compared to.NET and Java strings.
Or I can just use char*, but then I can forget about automatic memory management. Since that's very error-prone I prefer to do it only for performance-critical sections of the code.
Languages compiled into bytecode can be JIT-compiled into native code, or they can be pre-compiled into native code using a utility like Microsoft's NGEN. And when you are pre-compiling you have all the time in the world to optimize.
In a small but non-trivial program you can usually get C++ to beat Java and C# by throwing away all the high-level features and programming in what can be called "C with templates". But as soon as you start relying on, say, std::basic_string you may get surprised to see that C# and Java are winning. Java and C#'s GC-heap allocated strings are faster than C++'s basic_string if you use them in data structures because in Java and C# you only allocate the string once and pass it around by reference, where in C++ the each copy of basic_string is either going to allocate separate copies of its contents or do thread-safe reference counting which is unfriendly to the processor's cache.
I can also provide examples where real-world C++ will provide significantly better performance than Java or C#.
On a real-world program the performance of C# or Managed C++ is going to be roughly the same as the performance of C++, while depending on the problem Java may trail a little bit because it lacks structures so some data cannot be packed as tightly thus leading to more cache misses.
To see an example of C++ and C# being pitted against each other on a real-world problem take a look at the follow thread:
As I said, this is a fake dilemma. A more interesting question is how does the performance of mostly dynamically typed languages (Python, Ruby, Lisp) compare to the performance of statically typed languages (ML, Java, C#, C++)?
Peter Norvig has some numbers from four years ago:
On a real-world problem without external bottlenecks (database, network) dynamically typed languages can expect to be between two and five times slower than statically typed languages, though the trend is expected to worsen somewhat due to the expanding gap between the speed of the processor and main memory.
Also note that Lisp has by far the best performance among the dynamically typed languages. Companies that write Lisp compilers have been working on the problem far longer than the authors of Python and Ruby, and have significantly better type inference engines and compiler back-ends.
What they are doing beats running as non-admin on Windows XP. Which is basically the only way to be secure as the Windows core was engineered correctly while the apps were not.
Most Microsoft apps actually run correctly when you are not an admin because Microsoft sells to large companies which are mostly locked down, but 3rd party apps are horrible. There's no way a regular user could set up all his apps to run as that involves a lot of command line fun with CACLS on XP Home.
The part of Windows that was not designed correctly is the All Users account. If you install an app that's supposed to be available to all users then, for example, it's desktop icon is installed in the All Users/Desktop dir instead of being added to each user's Desktop dir. And to change anything for All Users you need admin priviledges, which is why Windows requires priviledge escalation for simple tasks like removing an icon from your desktop.
"A garbage collector protects against the leakage of memory and has nothing to do with what you described."
Not really. In languages like Java or C# the garbage collector guarantees that a reference will never point to a block that you don't own. You can't construct a reference to memory you don't own, and the memory won't be freed if you own it.
Also, garbage collectors _do not_ protect against memory leaks. Anybody that has ever programmed a data structure in a garbage collected language will tell you that. You still have to remember to set unused references to null (just like you have to delete them in C++) or you will have leaks.
"If you have to re-implement a generic function 20 times (once for each parameter), then you are doing something wrong - it means you have to implement it again the instant you need an the 21st parameter. C programmers would use the vararg functions, pass an array, or would pass an array of pointers - and it shouldn't be too hard for C++ programmers to do the same in a secure and type-safe method."
Actually, I have to implement it once for each parameter _count_, as I said in my post.
Varargs are out of the question, as they are not statically type safe and a frequent source of memory corruption.
If you find a way to do it without writing different functions for different argument counts, we'd all like to hear about that.
The main difference between C++ and other popular languages these days (other than gross syntax) is C++'s lack of garbage collector. Thus in C++ you can corrupt memory while in other languages you can't.
Yet we haven't experienced _any_ memory corruption in the medium-scale project we are working on? The trick? We avoid all C-style pointer-based constructs and instead use only higher-level, type-safe abstractions like smart pointers, vectors, strings, etc.
In the places those aren't available, we build safe constructs on top of the unsafe ones.
For example, instead of calling pthread_create which passes the parameters to the thread function through a void*, we have 20 createThread template functions that can be used to start a thread function with 0-19 arguments.
This leaves us with a single avenue for memory corruption: modifying a STL container while it's being iterated through. While it's impossible to prevent those at compile-time, a library like STLPort will catch them at run-time.
Can someone explain why cloning seems to be viewed as an unethical practice?
I know that with current technology cloning has more potential to go wrong than right (they go through 50-60 embryos until they manage the procedure), but assuming that gets fixed, what's the _ethical_ problem with doing it?
After all, the cloned child would not be your copy, but more like a twin born many years after you.
Dejan
Sudden surge in anti-patent sentiment in media
on
The Patent Epidemic
·
· Score: 2, Insightful
Funny. The media (especially business media) was very pro-patent up to a few months ago. Suddenly all these articles questioning patents are cropping up.
Either they are hurt by the fact that their Blackberries may stop working, or there is an orchestrated PR campaing going on.
When you minimize the last window in a process, Windows simply marks its pages as good swap file candidates but does _not_ swap them to disk. This is called a "soft swap". If more RAM is needed, these pages will indeed be among the first to be swapped out. But if they are needed before that, the flag will be cleared and most likely some other pages will be swapped.
As long as the cameras are not owned and directly controlled by the government, I don't see what's the problem?
What we are afraid of is a lot of power concentrated in few hands. That's why we have the separation of three branches of government in most of the democratic world, various checks and ballances, anti-monopoly laws, etc.
So as long as the government doesn't have too many cameras, and they have to go around asking shop owners and other people to provide their footage of some event, I don't think there's much threat to civil liberties.
The Word.doc format is well documented and parsed by hundreds of applications, including various open source office suites. And it's forward-compatible since Word 97, so the FUD about Microsoft changing the format and screwing up open source apps is crap.
Nobody helped Microsoft reverse-engineer WordPerfect and various other formats, yet they did it and claimed the market share.
Ditto for various API compatibility issues. NT emulated DOS, Windows 3.1 and Windows 95, yet WINE still chokes on circa-1995 apps. DOS is de-facto 100% documented and Windows 3.1 is de-facto 100% documented. Win32 is a moving target, but the stuff needed to run nine-year old apps is well-known.
First of all, thanks for the nice reply. Usually when I say something that goes against the accepted wisdom here I get flamed. I appreciate the tone and the content of your message.
"There's no rule against being paid for Free software. The 'Free' does not refer to money."
Yet in practice allmost all 'free' software is free.
It's pretty hard to make money off 'free' software. If you publish the source code and allow any competitor to create their own build, then they can always undercut you in price since they didn't have to go through the cost of writing the software in the first place.
Maybe you can make some money off support, but that's much less than can usually be made from selling private-source software.
That's why the few percent of people who directly earn money writing open source (instead of doing it as a hobby as I do) are mostly paid through foundations and research institutions.
Free software has the advantages of 1) using money to direct effort as you point out, 2) using sharing to allow reuse, and 3) lowering entry barriers to achieve diversity and 'genetic' strength. MS is missing advantages 2) and 3).
I hope I have shown above that point #1 is not a valid one, at least in practice.
Your points #2 and #3 definitely are valid. However, I think that the benefit derived from using money to carry the information about value outweights them.
"and a side effect is making the business of programming more efficient"
How so? It's Economics 101 that money is a great carrier and aggregator of information about how much something is worth to other people. One of the reasons why communist/socialist economies did so poorly was because they didn't let money perform that function.
OpenOffice is free, and can read MS Office file formats. There is no lock-in. Yet most people are still willing to pay of MS Office. That should tell you something.
And it's not inertia. MS has managed to make a significant dent in the Linux/FreeBSD server space market share over the last nine years, and Apple has (nearly? I don't have the latest figures) overtaken free operating systems in desktop OS market share. Both companies used money, that great carrier of information, to tell them what to concentrate their efforts on.
If I iterate through a collection of objects and cast them to some interface, all I will ever get is dynamic casts.
To address your other points:
- I used Java extensively for a few years.
- Have used all known optimization techniques to speed up all performance-critical code
- Have used the latest JVMs
- Checked the Sun's bug database. More often than not the bugs I stumbled upon were open for a couple of years or closed as not reproducible even though they clearly are.
- Your logic is flawed. The fact that something works for a LOT of people doesn't make it very fast. VB worked for a LOT of people.
- Java the language didn't change significantly since 1.2. Why you cite 1.3 as the turning point is unclear.
- Lots of people have used Java and came out unimpressed. Contrast that with the warm and fuzzy feeling that people that have experienced, say, Scheme, ML or Haskell have.
Ever since I've installed SpamNet (for Windows, Unix people should get Vipul's Razor), spam is no more.
I think that's what they are afraid of. Anti-spam tools are getting so good and easy to use that pretty soon everybody will be using. DMA will die a slow and painful death.
I design COTS desktop apps for living. Here are two patterns that have proven themselves many times so far:
1. Lazy evaluation of almost everything. Whenever one or more data objects change, they fire notifications that they have changed which are passed through the object graph to the views. The view then doesn't do _anything_ except invalidate itself. When the paint message comes later, it re-computes everything on the fly. (In case you are worried about performance: lazy evaluation and eager evaluation speeds are generally equal.)
2. Your event handlers shouldn't do anything by themselves. They should just call a function that actually does the job. This gives you a nice split between functions that are called as a direct result of users' actions and functions that are called internally. Very useful for undo/redo, traces and testing.
I've coded some of the largest and most functional applets I have ever seen for FutureSource. Here's an example.
During the few years that I have worked in Java, MS JVM was hands-down the best platform. It was fastest, had least bugs, and absolutely compatible with the code I initially wrote Sun's JVM.
Sun's JVM has a bunch of bugs that Sun is refusing to repair for years. For example, the clipping region of Graphics obtained through getGraphics() in Swing is wrong and has been wrong for N years.
Netscape had a terrible Symantec JVM. Working with it was a nightmare.
Microsoft's JVM certainly had its quirks, but much less than the other two.
Slashdot Mirror
Bull.
Instead of blaming all of world's ills on Vista, let's look at the real reasons:
1. Desktop power users are still mostly on 32-bit machines where you are limited by the available address space. I've gone through three laptops during the last four years and they were all 2GB machines. Even though I'd like to buy one with more RAM I can't. (Yes I know about the Windows 3GB switch but that has its problems on the desktop.)
2. Regular users are perfectly happy with what they have. Their machines work well for browsing, email, media playing and file sharing so they see no need to update to a new computer with more RAM.
Dejan
As the article states, it's straightforward to write an Expose clone in Vista. I've done it and my biggest headache was implementing a linpacking 2d algorithm to layout the windows in a manner that's pleasing to the eye. I assume Microsoft didn't because they were afraid of stepping on one of Apple's numerous patents.
There is a problem with Vista's thumbnail API, btw. After a window has been minimized for a while, Vista's unable to render its thumbnail and instead it just renders the non-client portion of the window and sticks a large window icon at its center.
I assume they are doing that to minimize the process' working set, but it still sucks if you want to support advanced Expose functionality like drag and drop.
Having access to the source code is not a solution to this problem. Ken Thompson has demonstrated that in his paper Reflections on Trusting Trust twenty years ago.
To really fix the problem we need to leverage the one thing that all modern operating systems (including Windows) do right at the core level - access control. Why would anybody want to run a codec at the privilege level of the program that's using it? Why not run it under an account where it can't touch anything except its input and output streams? (This doesn't have anything to do with whether you are logged in as admin/root. Even if you are not an admin you don't want the codec to upload your documents somewhere.)
A related issue is installation programs. We need to make these declarative instead of executable. As it is right now, you run installations as an admin/root, and give them the rein to do anything. God knows what goes on in those MSIs and makefiles. If these were declarative then setups would declare at the beginning what kind of access they need (simple installation, shared component installation, mucking with the system, codec, &c) and you would be able to make a finer grade decision on whether you want to let them run.
Dejan
Now you are saying that multitasking is unnecessary. How would you like it if you had to reboot each time you wanted to run a program?
> I did not HAVE "DOS and Win3.1 stuff", I had been using Linux on my
> first PC (4M RAM) for 18 months.
In that case it was a product that didn't suit your needs. But running DOS and Win 3.1 apps that they had was a requirement for most people, and being able to compile their Win 3.1 apps to the new OS without requiring much change was a requirement for most software vendors. Windows 95 gave you that, Linux didn't.
Linux thus had more memory at its disposal as it didn't have to execute compatibility thunks, plus it had a lot less features at the time. So it had room to do other tasks better and faster.
Was Windows 95 a cludge? Certainly. But you try to pack all those features into 4MB and you'll have to make compromises too. It just a basic fact of software engineering.
Every software product is rushed. Nothing large is ever released perfect, there are always known problems and things you could have done better.
As for Windows, the NT line has always been pretty solid. You could always install RC1 and expect it to work normally with maybe a driver going crazy every few days. Final releases were always an improvement in overall user experience from the previous version. (Though not an improvement in overall stability as it's pretty hard to beat the previous version that has been through every imaginable scenario on millions of computers.)
Vista seems to be another story. If you analyze the Beta and RC timeline of every NT-line OS up to now, you see that Vista is abberation. It's pretty obvious that Microsoft is lowering its standards in order to push the product out, and that's just going to turn around and bite it in the ass.
Service packs: They are a mix of patches and new functionality. We also do that in the Linux world, just in smaller steps as there is less to worry about compatibility and localization.
And stop badgering Windows 95. It looks lame now but it kicked ass on 4 MB computers with broken hardware back in 95. It ushered process isolation many years before Macs got it. It ushered a reasonably good UI many years before Linux got it. Plug & Play, ugly as it was, brought the end to fiddling with jumpers which is something that 99 percent of the population doesn't know how to do. It ran all your DOS and Win 3.1 stuff. So go easy on it. It may suck by today's standards, but in that day and age it was miles better than any of the alternatives.
Hm. That doesn't sound right.
The force that propelled the bullet forward is equivalent to the force that the gun from which the bullet is fired is exerting on the shooter's hand.
The only difference is that the force of the gun is spread over your palm, while the force of the bullet is concentrated into a much smaller area.
So I guess that if body armor could spread the pressure of the bullet to some 30 cm^2 you shouldn't fare that badly.
Dejan
I use them. References are mostly used for passing things by reference, but that's worthless for data structures. (Plus, they tend to play badly with templates.) Consider a case where you have two hashes that use mostly the same basic_strings as keys. Those two are going to either store separate copies or do reference counting on strings, which, as I explained, are both bad for performance as compared to .NET and Java strings.
Or I can just use char*, but then I can forget about automatic memory management. Since that's very error-prone I prefer to do it only for performance-critical sections of the code.
Dejan
This is a fake dilemma.
6 151.aspx
Languages compiled into bytecode can be JIT-compiled into native code, or they can be pre-compiled into native code using a utility like Microsoft's NGEN. And when you are pre-compiling you have all the time in the world to optimize.
In a small but non-trivial program you can usually get C++ to beat Java and C# by throwing away all the high-level features and programming in what can be called "C with templates". But as soon as you start relying on, say, std::basic_string you may get surprised to see that C# and Java are winning. Java and C#'s GC-heap allocated strings are faster than C++'s basic_string if you use them in data structures because in Java and C# you only allocate the string once and pass it around by reference, where in C++ the each copy of basic_string is either going to allocate separate copies of its contents or do thread-safe reference counting which is unfriendly to the processor's cache.
I can also provide examples where real-world C++ will provide significantly better performance than Java or C#.
On a real-world program the performance of C# or Managed C++ is going to be roughly the same as the performance of C++, while depending on the problem Java may trail a little bit because it lacks structures so some data cannot be packed as tightly thus leading to more cache misses.
To see an example of C++ and C# being pitted against each other on a real-world problem take a look at the follow thread:
http://blogs.msdn.com/ricom/archive/2005/05/10/41
As I said, this is a fake dilemma. A more interesting question is how does the performance of mostly dynamically typed languages (Python, Ruby, Lisp) compare to the performance of statically typed languages (ML, Java, C#, C++)?
Peter Norvig has some numbers from four years ago:
http://www.norvig.com/Lisp-retro.html
On a real-world problem without external bottlenecks (database, network) dynamically typed languages can expect to be between two and five times slower than statically typed languages, though the trend is expected to worsen somewhat due to the expanding gap between the speed of the processor and main memory.
Also note that Lisp has by far the best performance among the dynamically typed languages. Companies that write Lisp compilers have been working on the problem far longer than the authors of Python and Ruby, and have significantly better type inference engines and compiler back-ends.
Dejan
What they are doing beats running as non-admin on Windows XP. Which is basically the only way to be secure as the Windows core was engineered correctly while the apps were not.
Most Microsoft apps actually run correctly when you are not an admin because Microsoft sells to large companies which are mostly locked down, but 3rd party apps are horrible. There's no way a regular user could set up all his apps to run as that involves a lot of command line fun with CACLS on XP Home.
The part of Windows that was not designed correctly is the All Users account. If you install an app that's supposed to be available to all users then, for example, it's desktop icon is installed in the All Users/Desktop dir instead of being added to each user's Desktop dir. And to change anything for All Users you need admin priviledges, which is why Windows requires priviledge escalation for simple tasks like removing an icon from your desktop.
Dejan
"A garbage collector protects against the leakage of memory and has nothing to do with what you described."
Not really. In languages like Java or C# the garbage collector guarantees that a reference will never point to a block that you don't own. You can't construct a reference to memory you don't own, and the memory won't be freed if you own it.
Also, garbage collectors _do not_ protect against memory leaks. Anybody that has ever programmed a data structure in a garbage collected language will tell you that. You still have to remember to set unused references to null (just like you have to delete them in C++) or you will have leaks.
"If you have to re-implement a generic function 20 times (once for each parameter), then you are doing something wrong - it means you have to implement it again the instant you need an the 21st parameter. C programmers would use the vararg functions, pass an array, or would pass an array of pointers - and it shouldn't be too hard for C++ programmers to do the same in a secure and type-safe method."
Actually, I have to implement it once for each parameter _count_, as I said in my post.
Varargs are out of the question, as they are not statically type safe and a frequent source of memory corruption.
If you find a way to do it without writing different functions for different argument counts, we'd all like to hear about that.
You have the podium.
Dejan
The main difference between C++ and other popular languages these days (other than gross syntax) is C++'s lack of garbage collector. Thus in C++ you can corrupt memory while in other languages you can't.
Yet we haven't experienced _any_ memory corruption in the medium-scale project we are working on? The trick? We avoid all C-style pointer-based constructs and instead use only higher-level, type-safe abstractions like smart pointers, vectors, strings, etc.
In the places those aren't available, we build safe constructs on top of the unsafe ones.
For example, instead of calling pthread_create which passes the parameters to the thread function through a void*, we have 20 createThread template functions that can be used to start a thread function with 0-19 arguments.
This leaves us with a single avenue for memory corruption: modifying a STL container while it's being iterated through. While it's impossible to prevent those at compile-time, a library like STLPort will catch them at run-time.
Dejan
Can someone explain why cloning seems to be viewed as an unethical practice?
I know that with current technology cloning has more potential to go wrong than right (they go through 50-60 embryos until they manage the procedure), but assuming that gets fixed, what's the _ethical_ problem with doing it?
After all, the cloned child would not be your copy, but more like a twin born many years after you.
Dejan
Funny. The media (especially business media) was very pro-patent up to a few months ago. Suddenly all these articles questioning patents are cropping up.
Either they are hurt by the fact that their Blackberries may stop working, or there is an orchestrated PR campaing going on.
Dejan
"American multinationals"? Isn't that a contradiction in terms?
These companies employ people worldwide, and are owned by shareholders worldwide. What makes them American?
True, they are listed on U.S. stock exchanges, but so are many companies that are incorportated elsewhere.
Dejan
This is not correct.
When you minimize the last window in a process, Windows simply marks its pages as good swap file candidates but does _not_ swap them to disk. This is called a "soft swap". If more RAM is needed, these pages will indeed be among the first to be swapped out. But if they are needed before that, the flag will be cleared and most likely some other pages will be swapped.
Dejan
I'd like to hide one of those cellphones into my car as low-cost a theft-prevention measure. What's the cellphone in question?
As long as the cameras are not owned and directly controlled by the government, I don't see what's the problem?
What we are afraid of is a lot of power concentrated in few hands. That's why we have the separation of three branches of government in most of the democratic world, various checks and ballances, anti-monopoly laws, etc.
So as long as the government doesn't have too many cameras, and they have to go around asking shop owners and other people to provide their footage of some event, I don't think there's much threat to civil liberties.
Dejan
Oh quit whining already!
.doc format is well documented and parsed by hundreds of applications, including various open source office suites. And it's forward-compatible since Word 97, so the FUD about Microsoft changing the format and screwing up open source apps is crap.
The Word
Nobody helped Microsoft reverse-engineer WordPerfect and various other formats, yet they did it and claimed the market share.
Ditto for various API compatibility issues. NT emulated DOS, Windows 3.1 and Windows 95, yet WINE still chokes on circa-1995 apps. DOS is de-facto 100% documented and Windows 3.1 is de-facto 100% documented. Win32 is a moving target, but the stuff needed to run nine-year old apps is well-known.
Dejan
First of all, thanks for the nice reply. Usually when I say something that goes against the accepted wisdom here I get flamed. I appreciate the tone and the content of your message.
"There's no rule against being paid for Free software. The 'Free' does not refer to money."
Yet in practice allmost all 'free' software is free.
It's pretty hard to make money off 'free' software. If you publish the source code and allow any competitor to create their own build, then they can always undercut you in price since they didn't have to go through the cost of writing the software in the first place.
Maybe you can make some money off support, but that's much less than can usually be made from selling private-source software.
That's why the few percent of people who directly earn money writing open source (instead of doing it as a hobby as I do) are mostly paid through foundations and research institutions.
Free software has the advantages of 1) using money to direct effort as you point out, 2) using sharing to allow reuse, and 3) lowering entry barriers to achieve diversity and 'genetic' strength. MS is missing advantages 2) and 3).
I hope I have shown above that point #1 is not a valid one, at least in practice.
Your points #2 and #3 definitely are valid. However, I think that the benefit derived from using money to carry the information about value outweights them.
Dejan
"and a side effect is making the business of programming more efficient"
How so? It's Economics 101 that money is a great carrier and aggregator of information about how much something is worth to other people. One of the reasons why communist/socialist economies did so poorly was because they didn't let money perform that function.
OpenOffice is free, and can read MS Office file formats. There is no lock-in. Yet most people are still willing to pay of MS Office. That should tell you something.
And it's not inertia. MS has managed to make a significant dent in the Linux/FreeBSD server space market share over the last nine years, and Apple has (nearly? I don't have the latest figures) overtaken free operating systems in desktop OS market share. Both companies used money, that great carrier of information, to tell them what to concentrate their efforts on.
Dejan
Bullshit.
If I iterate through a collection of objects and cast them to some interface, all I will ever get is dynamic casts.
To address your other points:
- I used Java extensively for a few years.
- Have used all known optimization techniques to speed up all performance-critical code
- Have used the latest JVMs
- Checked the Sun's bug database. More often than not the bugs I stumbled upon were open for a couple of years or closed as not reproducible even though they clearly are.
- Your logic is flawed. The fact that something works for a LOT of people doesn't make it very fast. VB worked for a LOT of people.
- Java the language didn't change significantly since 1.2. Why you cite 1.3 as the turning point is unclear.
- Lots of people have used Java and came out unimpressed. Contrast that with the warm and fuzzy feeling that people that have experienced, say, Scheme, ML or Haskell have.
Ever since I've installed SpamNet (for Windows, Unix people should get Vipul's Razor), spam is no more.
I think that's what they are afraid of. Anti-spam tools are getting so good and easy to use that pretty soon everybody will be using. DMA will die a slow and painful death.
Dejan
I design COTS desktop apps for living. Here are two patterns that have proven themselves many times so far:
1. Lazy evaluation of almost everything. Whenever one or more data objects change, they fire notifications that they have changed which are passed through the object graph to the views. The view then doesn't do _anything_ except invalidate itself. When the paint message comes later, it re-computes everything on the fly. (In case you are worried about performance: lazy evaluation and eager evaluation speeds are generally equal.)
2. Your event handlers shouldn't do anything by themselves. They should just call a function that actually does the job. This gives you a nice split between functions that are called as a direct result of users' actions and functions that are called internally. Very useful for undo/redo, traces and testing.
Dejan
I've coded some of the largest and most functional applets I have ever seen for FutureSource. Here's an example.
During the few years that I have worked in Java, MS JVM was hands-down the best platform. It was fastest, had least bugs, and absolutely compatible with the code I initially wrote Sun's JVM.
Sun's JVM has a bunch of bugs that Sun is refusing to repair for years. For example, the clipping region of Graphics obtained through getGraphics() in Swing is wrong and has been wrong for N years.
Netscape had a terrible Symantec JVM. Working with it was a nightmare.
Microsoft's JVM certainly had its quirks, but much less than the other two.
Dejan