Journal Articles
Browse in : |
All
> Journals
> CVu
> 123
(22)
All > Journal Columns > Editorial (221) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Editorial
Author: Administrator
Date: 09 May 2000 13:15:36 +01:00 or Tue, 09 May 2000 13:15:36 +01:00
Summary:
Body:
When you go out and buy a car there are many factors that you may take into account. There are superficial details such as the colour and trim. Then there are details governed by your planned usage; you will choose a very different vehicle if you live and work in a town with your children grown up and gone compared with the choice of a parent of young children living in a remote country cottage. Mostly you will want a fairly conventional machine because it will be easy to maintain and easy to sell when you want to replace it. You will expect your vehicle to conform to one of two major styles of control format (stick shift or automatic) and you will want a vehicle that is either left-hand or right-hand drive depending on the norm for your place of residence.
I can think of many theoretical alternatives that might be arguably better but I know that the most important feature is a high degree of conformity. Running personal transport on natural gas may be highly desirable from an ecological viewpoint but it is impractical for most of us. Even if we made such a choice we would still expect the main controls to be the same as in a more conventionally powered machine. In addition, mostly we do not choose our cars on the basis of raw speed or raw power. Of course some people buy completely inappropriate cars, but mostly we get something that is reasonably functional for our needs and then stick with it for a number of years. The rate of change is relatively slow and those changes that occur do not immediately change the way we use our private transport.
Now reflect on computing and information technology. We have the worst of all possible worlds, conflicting technologies coupled with an accelerating rate of change. This has a wide range of undesirable consequences.
A few weeks ago I bought a new role playing computer game. When I came to install it my first choice of drive was rejected on the basis of lack of space. The game wanted 600Mbytes of storage without any options. I am not concerned with whether this expectation is reasonable, simply that the producers found it to be so from their perspective. Another feature of this game shared by many other programs is that it requires me to run one of a very limited range of operating systems. If I were a proud owner of an Apple Mac I simply could not play that game. By contrast much of the innovative multimedia work done by Voyager during the ten years of its existence only ran on an Apple Mac. It is as if I needed a different car for touring in France from that which I might use for shopping in my home town. Worse, there are no compromises, if I want to run Microsoft Office and multimedia from Voyager I must own two machines. It is not a matter of relative efficiency but working at all.
Fundamental differences between cars are hidden behind a largely uniform interface. I do not need to enquire if a car will travel on a US toll road. Of course there are special cases, if I want to travel across open country I better consider a four-wheel drive, if I live in North Alaska I better choose a vehicle whose fuel does not readily freeze. My point is that these extreme circumstances are generally well understood. It is very different in the world of computers. Last year's model may not be able to run this year's software, and we need to know what software we intend to run before we choose our machine.
What we need is a hardware independent machine. Only when we have that will we have a machine that is appropriate to the marketplace while allowing for continuing development and innovation at hardware level.
The great thing about Java is the JVM; pure Java software can be hardware independent. The worst thing about Java is the JVM; it restricts you to a specific machine, or even worse to software written in a specific language.
Java as a language has much going for it, but one very bad thing - it lacks stability. The JVM is a step towards hardware independence (albeit not a new one) but it is damaged because it limits the languages in which you can program. There is no inherent reason why we should not have a general virtual machine to which general-purpose software can be targeted. The JVM, as it is today, is not it. The JVM was developed to support a specific programming language and though it is general enough to allow some other languages to target it, it is also specific enough to make it very difficult if not impossible to target it with languages such as C or C++.
We have enough raw power in the current generation of machines to allow multiple operating systems to coexist (and inter-communicate) on the same hardware. We also have enough power to allow our machines to present a uniform interface to our software. The time has come for us to expect a uniform low-level virtual machine to which software developers can target those products that want a relatively high-level interface to the hardware. We also need to develop such products as VMware so that we can mount competing operating systems simultaneously. We now have the technology to decouple hardware development from software development (think how Microsoft's DirectX is doing this in the games market). What we lack is the vision and discipline to make that the norm. There will always be special cases that need closer coupling between software and hardware but they should be the exception rather than the norm, but do we have the will to make it so?
Notes:
More fields may be available via dynamicdata ..