Here is an old blog comment I made and I don't remember if it ever got published... but since many of them don't I like to save copies just in case. In this case, I think it contains a good idea that I've mentioned before.
You know what they say about people who ASSUME.
You need to distinguish between "high level" code and interpreted code. Some might consider C high level. But high level code, no matter what the original language can be optimized.
Who said anything about kernel code? Not I. Is most of Windows implemented in the kernel? Again, this is news.
You can mix and match low/high compiled/interpreted code (note: talking two different issues there) all you want as long as code that gets executed a LOT is non-interpreted and has been optimized (by writing it in assembler or using a very good optimizing compiler).
But even interpreted code isn't necessarily slow. APL is an interpreted language, but I'd put it's ability to do matrix manipulation up against any average C programmer, because the matrix operation are all "primitives" in APL and the matrix work is highly optimized (at least for any commercial version).
And while we're at it, your comment much earlier about implementing Windows on top of BSD is at best misleading. The WINE project is an attempt to implement as much of the Widows API as possible on top of another base OS. This is a reverse-engineering effort, and is far from perfect. But is was a good enough base to allow Google to port Picassa to Linux relatively quickly.
Given the actual Windows code (and the rights to use it of course) Microsoft could do a near perfect re-implementation of the Windows user and driver interface just about anywhere they wanted to.
I don't happen to think that the VMS underpinnings (to the extent that the VMSness hasn't been tweaked out of existence) are the source of Windows flaws (WINE has proven that the flaws port quite well). On the other hand, there is nothing inherently spectacular about that VMS history. In fact there is something quite spectacular about your original comment, which I'll re-quote:
"Cause the C and Assembler bit heads who built Windows don’t work at Microsoft anymore. "
All the more reason to build Windows on top of a base that is still openly maintained by exactly that sort of "bit-head". It is exactly at that level that there is no longer any significant competitive advantage in maintaining proprietary code. When is that last time you heard a Windows user complain about inadequacies in the Windows HAL (Hardware Abstraction Layer)? Same issue.
No comments:
Post a Comment