4 ms·

The future is languages that target a VM. Once you have a VM humming along on any webserver, you can apply any language you want to that VM. If today's PHP use

by bprater 18y ago

The future is languages that target a VM. Once you have a VM humming along on any webserver, you can apply any language you want to that VM. If today's PHP used a VM, writing a "new PHP" would be pretty straightforward. You wouldn't have to worry about backward compatibility since "old PHP" would target that same VM, too. You could use the basic syntax, do all your fun namespacing, break oldly named functions out of the core language, etc. If someone attempts the build a "new PHP", targeting Parrot or the JVM would be the way to go. ColdFusion made a similar break a few years ago. They rebuilt the entirely language in Java, and now ColdFusion is basically a layer on top of Java.

gsmaverick 18y ago
I think that targeting Parrot or JVM would be a bad idea, because that would break the simplicity of the PHP installation we have today.
- jrockway 18y ago
  mod_parrot should be just as easy to install as mod_php. Tomcat is also as easy to install. Deployment in any language is not much of a problem on machines that you control. PHP is popular because of mod_php shared hosts that charge $1/month. Paying a dollar is apparently an easier way to get started with programming than `apt-get install <a real language>`, hence PHP's popularity.
old-gregg 18y ago
The future is languages that target a VM I hope not. You may be predicting the future, and there are many indicators pointing that way, but I hope you're wrong. VM design is never 100% language-neutral. Targeting existing VMs means inevitably accepting VM limitations and letting some of the original language design choices go. Even things like float point arithmetics, threading and exceptions support are pretty much dictated by your choice of VM. JRuby's team has been constantly struggling with JVM internals [and still couldn't get continuations] and Ruby on LLVM was considered by many to be too difficult to implement. And Ruby isn't very unconventional. Furthermore, commercial VMs tend to be heavy platform-dependent pigs and by targeting one of them you're inevitably denying your language the right to be called "general purpose". By platform dependence I mean that Ruby.NET has to deal with a single "system instance" of .NET, assembly cache and other crap, i.e. things outside of language designer's and software author's control. And finally, you will never be able to port your language to platform X if your favorite VM isn't available there. I can run C and Python programs on my router. C# or Java? Nope.
- thwarted 18y ago
  "VM design is never 100% language-neutral." The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the same capabilities and flexibility that the x86, PPC or any other hardware/microcode based architecture provides. VM design may not be language neutral, then maybe some VM designers could learn something from hardware/chip designers. The very reason we're having this discussion is because ANY language can be implemented on ANY of the general purpose hardware architectures available. The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. Associating a VM with a runtime also confuses the technologies; admittedly this is often done because the company pushing their VM product has a vested interest in also providing developers with the tools and the libraries and the UI they program to.
  - ars 18y ago
    Second system syndrome? You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C. C is your new VM programming language.
    - eru 18y ago
      GHC actually moved away from using C as a target language. They call it a dead end for whatever reason. (They seem to be going to C--.)
  - blasdel 18y ago
    The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces. These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?

by bprater 18y ago

gsmaverick 18y ago

I think that targeting Parrot or JVM would be a bad idea, because that would break the simplicity of the PHP installation we have today.

jrockway 18y ago
mod_parrot should be just as easy to install as mod_php. Tomcat is also as easy to install. Deployment in any language is not much of a problem on machines that you control. PHP is popular because of mod_php shared hosts that charge $1/month. Paying a dollar is apparently an easier way to get started with programming than `apt-get install <a real language>`, hence PHP's popularity.

old-gregg 18y ago

The future is languages that target a VM I hope not. You may be predicting the future, and there are many indicators pointing that way, but I hope you're wrong. VM design is never 100% language-neutral. Targeting existing VMs means inevitably accepting VM limitations and letting some of the original language design choices go. Even things like float point arithmetics, threading and exceptions support are pretty much dictated by your choice of VM. JRuby's team has been constantly struggling with JVM internals [and still couldn't get continuations] and Ruby on LLVM was considered by many to be too difficult to implement. And Ruby isn't very unconventional. Furthermore, commercial VMs tend to be heavy platform-dependent pigs and by targeting one of them you're inevitably denying your language the right to be called "general purpose". By platform dependence I mean that Ruby.NET has to deal with a single "system instance" of .NET, assembly cache and other crap, i.e. things outside of language designer's and software author's control. And finally, you will never be able to port your language to platform X if your favorite VM isn't available there. I can run C and Python programs on my router. C# or Java? Nope.

thwarted 18y ago
"VM design is never 100% language-neutral." The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the same capabilities and flexibility that the x86, PPC or any other hardware/microcode based architecture provides. VM design may not be language neutral, then maybe some VM designers could learn something from hardware/chip designers. The very reason we're having this discussion is because ANY language can be implemented on ANY of the general purpose hardware architectures available. The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. Associating a VM with a runtime also confuses the technologies; admittedly this is often done because the company pushing their VM product has a vested interest in also providing developers with the tools and the libraries and the UI they program to.
- ars 18y ago
  Second system syndrome? You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C. C is your new VM programming language.
  - eru 18y ago
    GHC actually moved away from using C as a target language. They call it a dead end for whatever reason. (They seem to be going to C--.)
- blasdel 18y ago
  The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces. These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?