With regards to open source software, you make an interesting comparison that, "Free versus proprietary (or non-free) software is similar to the divide between science and alchemy." Can you discuss this concept a bit?
The next line in the book is that the problem with alchemy is that everyone had to learn for themselves that drinking mercury is a bad idea. Progress in math and science happens when scientists have "shoulders to stand on." I'm not a historian, but it would be interesting to look at the past from the perspective of times when man cooperated versus eras when this was not the default way of working.
We still live in the dark ages of computing because proprietary software is so dominant, at Microsoft of course, but also Google and Apple and many other places. Java is now free, but it has tremendous baggage because it was proprietary since its creation. Perhaps JavaScript wouldn't even exist if Java were available for the web folks. One of the reasons that Unix never beat Windows was that the hardware vendors, who were primarily funding the development, didn't work together and fragmented Unix, spending a lot of time re-implementing each other's features. Even in universities and other research labs, papers are published, but the accompanying software is not usually released. At some point, a switch will flip and this will change. I hope my book helps to play some part in that. Free software, like a free press and the free market, are very big ideas.
Looking at Linux specifically, where do you see the biggest need(s) for change are in this system? It's not perfect, obviously, but what needs to happen for Linux to become a mainstream success across the board?
I spent a lot of time thinking about this while writing the book and talk about this in several chapters. In general, I'd say everyone who works on Linux needs to do a better job! Intel's drivers are free, but they are providing minimal resources. Their 3-D support is buggy, and I heard that driver support for TV-out was added two years after the hardware was released. The driver support should be ready the day the hardware is released, if not before.
Linux only runs on a few of Dell's machines. It shouldn't be that hard for them to get the drivers for the all their components into the kernel tree, or simply put a little pressure on their component vendors to do the work. And on the topic of general hardware support, Andrew Morton told me that he doesn't think [Linux creator] Linus [Torvalds] cares enough about the buglist and so bugs languish.
Sun has 30,000 employees, but only 30 programmers working on OpenOffice. I'd put a lot more on OpenOffice as it is one of the most important pieces of the free software stack. Microsoft has more than twice as many programmers working on Internet Explorer as Sun has working on all of OpenOffice. One wonders whether Sun really thinks OpenOffice could be a replacement for Office when they make such a small investment in it.
User-mode code needs to abandon C and C++ and move to a garbage collected language. This would provide increased reliability, but more importantly, increase the maintainability of code and decrease the amount of duplicate code. I spend two chapters on that topic.
I've often wondered whether Linux needs a "killer app" to beat Windows, for example if it had robust continuous speech recognition or some other AI feature. That would be great, but it still needs to recognize your hardware, do a good job importing your Office files, etc. I think Linux already has a "killer app" in the 1,000s of applications it ships with. But they all need more polish. The more people who join Linux and the more programmers who contribute to it, the faster it will achieve world domination.
In general, things are moving in the right direction, but they could move faster. I use Linux 100 percent of the time on my laptop and on my server so it is ready for me. And it has made steady progress in the four years I've been using it.
Following up on your comments about programming languages and garbage collection, what do you see as the programming languages of the future? C#? Objective C? I've always felt like there were too many C-like languages, and that the minor differences between them could be confusing for developers, more so than if the languages were completely different (like Object Pascal). What's going on in that world, and how will these environments adapt to the multi-core/parallel computing needs of the near future?
Yes, there are too many C-like programming languages but even worse is that they tend to be supersets and so have of the same baggage as C: header files, source files, macros, and so on. The lack of garbage collection is the biggest downside because of how it changes programming and I spend an entire chapter on that topic. It is possible to build a programming language which looks nothing like C but whose compiler outputs C and it was a very big mistake for C++ not to have done this.
Objective C is popular only because of Apple, but they should abandon it as soon as possible. I just went to the Lang.Net 2009 conference and one of the things I found was a consensus from the variety of experts there that there is nothing interesting in that language, and that its primitive nature is holding Apple back. If Apple doesn't bless a new language like Microsoft has with C# and .Net, they will be in trouble.
My book discusses why Java turned out so poorly, and why making it free won't change anything, but I also gathered from talking to some Sun employees over beers that Java is a dying language. (They didn't admit anything explicit, but the things I learned made me realize this.) It was a mistake for Google to use Java/Dalvik for their phone. They should have used Mono or Python.
In terms of the future, I think it will boil down to a battle between .Net and Python. I'm not sure how it will play out, but it will be interesting to watch! Python needs to get compiled one day, but Python has a much larger set of libraries (check out SciPy for example) whereas outside of Microsoft's .NET walled garden is a barren wasteland. Python is my next language.
Supporting multi-core is a big problem, but a much bigger problem is that far too much code out there is still written in C and C++, and isn't even reliable when running on a single processor! Also, my computer is mostly idle even when I'm "busy" doing stuff on it, which means that the software isn't even taking advantage of the hardware that is already there. Once the industry solves these problems, we can take on the multi-core challenge.