Ok, let's consider known "good things" about VM.
- Programs written for VM are easily portable
Yes, of course. A program compiled into, for example, java VM bytecode can be run everywhere the VM exists. This assumes that no external stuff is used. Yes, no external libraries, no external programs written not for VM. How often can the external stuff be useful? I'd answer - very often. Even if you a volunteer programmer and work times to times on several tasks you will gather a collection of development tools (libs, programs, etc.) you're using. And you're lucky if you started the development for a VM and you're in trouble if you did not. A commercial company would have even more troubles with reusing available stuff. - "Write once - run everywhere"
Yes, it's quite cool to compile program only once and to be able to execute it on different platforms. But the question here is whether testing can be avoided on several target platforms. For example, a company could decide that AIX is too expensive to buy and testing on that platform is not necessary. In ideal world, the company made right decision, in real - it will fail! Even UI will not look the same on different problems. And who knows how much issues with program execution can happen on a different platform?
One can argue that recompilation on different platforms can be enormously hard. Yes, I agree but the problem is not the recompilation itself. The source of a platform are development tools (like different c/c++ compilers, different build systems, etc.). - Modern computers have a lot of spare time - it can be spent for garbage collection and/or JIT compilation
Heh, yes, computers waste a lot of CPU cycles. But why the hell they try to spend those CPU cycles on garbage collection and/or compilation at the same time I try do do something with a program (remember java's "adaptive mark-and-sweep stop-and-copy gc" that makes large java programs so unresponsive?).
I'd say that if I have spare CPU cycles, I'd better spend them on interpreting the program (like python interpreter does) and not on trying to do the "background" magic. Real world proves that the later approach which in theory is slower turns out to be much faster (compare Java/SWT programs to Python/GTK or Python/Qt).
Bear in mind also that python interpreter uses GC with reference counting which should be "much slower". - It's easier to write programs for VM
Huh? It's easier to write programs in java and/or c# but that has nothing to do with a VM. Don't remember that GCJ compiler exists to compile java code into native executables. Similar compiler for c# can be implemented as well. - VM allows reflection
Ok, two questions. How often reflection is used? And isn't reflection available with interpreted languages? My answers are: "rare" and "yes". If you need reflection, use interpreted languages, they can do it easier. Most problems can be solved using some kind of "eval" statement (in ruby, for example, you can even add/modify class definitions using "eval"). - It's easy to distribute programs for VM
Ok, now I'm bailing out. This is not a myth - it's a reality. For example, java web start (JNLP) has always attracted me a lot. It's also easy to write and distribute plugins for applications. Anyways, with interpreted languages you can do the same thing and VM is not necessary. And let's consider for a minute troubles with distribution of native-compiled programs for Windows. Most of them are connected to the distribution of dll's which have no versioning information.
But besides that it's relatively easy to distribute compiled plugins for applications. On UNIX distribution of binaries was always a problem mostly due to binary incompatible libc/etc in dozens of distributions.
PS: As a postscript I will raise one question. Can aforementioned "good things" be said about a development platform with a compiled language?
And here my answers:
- Programs written for VM are easily portable
"Write once - compile everywhere" _can_ be achieved. There's no technical problem with that. It's a question of development tools - a compiler, standard library and build system. - "Write once - run everywhere"
"Write once - compile everywhere" can be considered as the same. Testing is always necessary so if a compilation can be made easier and straightforward then those statements become equal. - Modern computers have a lot of spare time - it can be spent for garbage collection and/or JIT compilation
There's no problem in having GC in compiled language. GC with reference counting can be used to avoid stops during program execution. The program will be slower (due to reference counting) but the overall program flow would be perceived as more "natural". For example, everybody knows that python programs are slow - each test shows their slowness, but at the same time python programs do not feel slow. They run smoothly. - It's easier to write programs for VM
For any modern language (java, c#, etc.) a native compiler can be created. If java/c# are not so good, it's always possible to create a better language ;) - VM allows reflection
Interpreter for a language can be created among with native compiler. Developers who need reflection could make use of such interpreter. Or vise versa, a compiler for an interpreted language can be created. The only technical problem to solve here is to allow easy interaction between interpreted and compiled code. - It's easy to distribute programs for VM
If BC is kept for the development platform then it is always possible to distribute binaries and plugins in binary form. A number of rules exists (see, for example, "parallel installation" document for GTK) to ensure the libraries do not clash and old programs can be run on newer platforms. It's just a matter of installing old and new binaries in parallel. Exactly the same thing should be done with VMs. Different versions of VMs can be incompatible so parallel installation is a must.
4 comments:
A few random points...
- platform-independent GUIs, reflection and GC are not VM-related at all. You can have them in statically compiled code, no VM requires them.
- the difference between pseudo code (thus designed for being executed by software) and native code is not CPU independence. You can run x86 code on a PPC. The VM will be more complex than a VM for Java byte code, but it is possible. The main advantage of pseudo code is that it is a good compromise between plain source code and native/binary code.
- plain source code is hard to compile. In practice it is not possible to guarantee that a large C++ application written today can be compiled without modifications on a C++ compiler that it has not been tested with. Source code is too complex to ensure real compatibility. So you simply can't ship a program as source code (unless you require the user to be capable of fixing C++ apps, but over 99% of the world's population are not). Another issue is that compilation takes a lot of time and no sane person wants to wait a couple of hours before the word processor can be used, but that's a problem that may disappear in the future.
- the problem of native code is that it is incredibly hard to understand and modify. You can convert x86 code into PowerPC code, especially when the PPC is also operating in little endian mode, but it will cost you performance. You could do a full analysis of native code and check whether it is trustworthy (thus only calls published functions of libraries, uses only legal types for doing this, does not access libraries' memory etc), but AFAIK nobody managed to do this yet, at least not with libraries being in the same process as the program
- pseudo code has the advantage that you can design it in a way that it is easy to process for software. You can easily translate it to different CPU architectures. When the user upgrades his system and has a new CPU, the VM can take advantage of the new CPU's features automatically. If the pseudo code is well designed, it frees the developer from testing on different architectures and it frees the user from having to care about CPU architectures. Today I can download a (J2ME Java) game and it will just work on my mobile phone - I have no idea which CPU my phone is using, and I don't need to. It just works. And can be confident that it will still work when I buy a new phone.
- The VM can also guarantee the pseudo code's trustworthiness to a degree that you do not even need Unix processes and memory separation for this anymore. A VM can easily define the privileges of code down to a per-method degree. This is useful for Java applets, but it will be even more useful once we have OSes that stop trusting applications and can limit the privileges of an application to a minimum. So people can finally install software with having to worry that they install spyware; that bugs in applications may affect other applications; that security leaks in the application may break out and infect the whole computer; or that the software can not be cleanly removed.
the MAIN reason for using a VM over an interpreted language is code scrambling. some ppl want to hide their code -- it is just like this. and with a VM they can use a multitude over other 'reasons' why the 'code hiding practise' is good for speed, starting-speed, and all the reasons you mentioned.
companies choose an interpreted language with a VM because they want to produce closed source apps.
> - platform-independent GUIs, reflection and GC are not VM-related at all.
Yes I know. I just was bored by some people saying that they are.
> The main advantage of pseudo code is that it is a good compromise between plain source code and native/binary code.
For what reason the compromise is necessary? I'm not trying to convince everybody to distribute source code for applications. I do understand that a normal user will never compile from sources.
But compilation from source to native code can be easier than it is now with C++. And I'm trying to say that better development platform can solve quite a lot of problems with native platform development.
I'm not opposing the usage of VM's. You gave good reasons for them to exist. But I don't like the modern tendency that good native development tools are being forgotten for the sake of questionable tools with VM's
But compilation from source to native code can be easier than it is now with C++. And I'm trying to say that better development platform can solve quite a lot of problems with native platform development.gcc+automake definitely has a lot of room for improvements. But the sheer size of the C++ specification plus the specifications for linking plus the build system's spec are larger than a pseudo code language's spec by at least one order of magnitude. Keeping such a C++ development environment interoperable with all existing programs is a much harder problem than keeping a pseudo code VM interoperable with all existing software.
When you split compilation into two steps (source code->pseudo code->native code), then you can let the developer take care of the first one, and the user is only affected by problems in the relatively small second step.
Post a Comment