The whole virtual machine concept implies that you are not to be trusted as a developer. You are expected to trust the language vendor more than your own programming skills.
This isn't the concept of the virtual machine. After all, it's really just a extremely CISC CPU intended to be emulated. It's not part of the language.
I understand this. I still resist the notion of any limitation between a programming language and the machine, because it is a dangerous trend to limit the developer from full, assembler-level access to all hardware. Otherwise you incrementally stunt his abilities, and that is sad. I am thinking about development fifty+ years in the future, when these issues are more mature, and from that perspective, the Java approach is incrementally more and more limiting to the developer.
Java has cross-platform merits, but clearly, it was designed by the marketing department, not by the geek squad.
Java has cross-platform merits not because of the virtual machine, but because of its extensive standard library giving abstractions for most of what people need to do. C and C++ can be generally cross-platform, provided you only use the standard library, but their stdlibs don't cover as much ground. Qt, on the other hand, builds on C++ and replaces its standard library with one that is more flexible and has a broader range of support, including the QtGui module which provides for graphical interfaces.
Java does have cross-platform merits because of the virtual machine. Your observations on libraries are keen, but are not the only reason that Java has cross-platform merits. We're both right:
I quote from http://en.wikipedia.org/wiki/Cross-platform.
As previously noted, the Java platform is an exception to the general rule that an operating system is a software platform. The Java language provides a virtual machine, or a "virtual CPU" which runs all of the code that is written for the language. This enables the same executable binary to run on all systems which support the Java software, through the Java Virtual Machine. Java executables do not run directly on the operating system; that is, neither Windows nor Linux execute Java programs directly. Instead, a special computer program called the JVM, or Java Virtual Machine, is run by the operating system, which in turn runs the Java program.
Again, I'm fine with Java as a language, if only the virtual layer could be removed.
If you can't crash a server, and crash it big with buggy inline assembler, how are you ever going to learn grace under pressure, which is a necessary component of any responsible world domination plan? ;)
You can't, or at least shouldn't be able to, crash a server with mere userland code. In most cases, you can't provided the server has been setup properly (eg, limiting forks to prevent forkbombs).
The logic behind "limiting forks" is a good idea for beginners. But it is incrementalism in the wrong direction, not toward freedom, and it removes useful tinkering ground from mature developers. Do not think that all geeks will always have the freedoms they take for granted today. Classlines are already being drawn. Be wise. Stake a claim in the ruling class because you understand the underlying issues.
Not far in the future, kernels will be considered "finished" and stable, because hierarchical power structures will have consolidated around them, and will prevent innovation, which is a pattern easily measured by studying the social dynamics of any large religion: Initial Freedom followed by incremental imprisonment of its own followers, until they are killing each other over absolutely trivial issues.
We must recognize we are building the foundations of a future which will not always be as free as it is now -- unless we look at these deeper issues and their long term consequences.
I prefer the geek to have full ability to crash the box -- and the wisdom and ethics not to do so; not a firewall of technology preventing him, but a firewall of ethics. It's like the logic behind the 2nd Amendment to the Constitution.
You seem to prefer removing power from the geek by limiting him, rather than relying upon the reputation economy to inspire geeks to do better, which is more perilous, but better in the end.
The original rant remains standing: On a philosophical level, virtual machine layers limit the geek. Some geeks like that. This one prefers freedom.
-Jared
On 3/6/07, Jared [email protected] wrote:
I understand this. I still resist the notion of any limitation between a programming language and the machine, because it is a dangerous trend to limit the developer from full, assembler-level access to all hardware.
You may have full access to all hardware on =your= computer. You may even have that access in source code that I, or people I trust, get to look at before we compile it and run it on =my= computer. But bear in mind that no userspace program needs access to the hardware. Only the kernel (including device drivers) needs that access.
And there is no way that Joe Blow's Website gets to download a program to run on my computer and do God Knows What. I might let Joe send me a java applet that runs in a sandbox where it can't try to sniff credit card numbers, bank accounts, passwords, etc.
If that stunts Joe's development as a programmer, so be it.
On 3/6/07, Jared [email protected] wrote:
The whole virtual machine concept implies that you are not to be trusted as a developer. You are expected to trust the language vendor more than your own programming skills.
This isn't the concept of the virtual machine. After all, it's really just a extremely CISC CPU intended to be emulated. It's not part of the language.
I understand this. I still resist the notion of any limitation between a programming language and the machine, because it is a dangerous trend to limit the developer from full, assembler-level access to all hardware. Otherwise you incrementally stunt his abilities, and that is sad. I am thinking about development fifty+ years in the future, when these issues are more mature, and from that perspective, the Java approach is incrementally more and more limiting to the developer.
Java has cross-platform merits, but clearly, it was designed by the marketing department, not by the geek squad.
Java has cross-platform merits not because of the virtual machine, but because of its extensive standard library giving abstractions for most of what people need to do. C and C++ can be generally cross-platform, provided you only use the standard library, but their stdlibs don't cover as much ground. Qt, on the other hand, builds on C++ and replaces its standard library with one that is more flexible and has a broader range of support, including the QtGui module which provides for graphical interfaces.
Java does have cross-platform merits because of the virtual machine. Your observations on libraries are keen, but are not the only reason that Java has cross-platform merits. We're both right:
I quote from http://en.wikipedia.org/wiki/Cross-platform.
As previously noted, the Java platform is an exception to the general rule that an operating system is a software platform. The Java language provides a virtual machine, or a "virtual CPU" which runs all of the code that is written for the language. This enables the same executable binary to run on all systems which support the Java software, through the Java Virtual Machine. Java executables do not run directly on the operating system; that is, neither Windows nor Linux execute Java programs directly. Instead, a special computer program called the JVM, or Java Virtual Machine, is run by the operating system, which in turn runs the Java program.Again, I'm fine with Java as a language, if only the virtual layer could be removed.
If you can't crash a server, and crash it big with buggy inline assembler, how are you ever going to learn grace under pressure, which is a necessary component of any responsible world domination plan? ;)
You can't, or at least shouldn't be able to, crash a server with mere userland code. In most cases, you can't provided the server has been setup properly (eg, limiting forks to prevent forkbombs).
The logic behind "limiting forks" is a good idea for beginners. But it is incrementalism in the wrong direction, not toward freedom, and it removes useful tinkering ground from mature developers. Do not think that all geeks will always have the freedoms they take for granted today. Classlines are already being drawn. Be wise. Stake a claim in the ruling class because you understand the underlying issues.
Not far in the future, kernels will be considered "finished" and stable, because hierarchical power structures will have consolidated around them, and will prevent innovation, which is a pattern easily measured by studying the social dynamics of any large religion: Initial Freedom followed by incremental imprisonment of its own followers, until they are killing each other over absolutely trivial issues.
We must recognize we are building the foundations of a future which will not always be as free as it is now -- unless we look at these deeper issues and their long term consequences.
I prefer the geek to have full ability to crash the box -- and the wisdom and ethics not to do so; not a firewall of technology preventing him, but a firewall of ethics. It's like the logic behind the 2nd Amendment to the Constitution.
You seem to prefer removing power from the geek by limiting him, rather than relying upon the reputation economy to inspire geeks to do better, which is more perilous, but better in the end.
The original rant remains standing: On a philosophical level, virtual machine layers limit the geek. Some geeks like that. This one prefers freedom.
-Jared
Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
I think I'm the complete opposite. I love the fact that VMWare/QEmu/etc.. are coming along and creating a virtual machine where I don't have to worry about hardware compatibility anymore. I'd like to eventually have preconfigured/pretuned virtual machines that are specific to a job function become the norm. This makes server migrations, turn-ups, turn-downs, etc.. far easier imho. But this is coming from a SysAdmin, not a programmer, so that may be the difference.
-
Jared -
Kyle Sexton -
Monty J. Harder