| |||||||||||||
GNOME Platform StormcloudsGNOME Platform StormcloudsPosted Mar 25, 2004 3:32 UTC (Thu) by kyle_hayes (guest, #7904)Parent article: GNOME Platform Stormclouds
I think the title may be blowing this out of proportion a bit. I am
(Log in to post comments)
GNOME Platform Stormclouds Posted Mar 25, 2004 6:01 UTC (Thu) by raytd (guest, #4823) [Link] I tend to agree. F/OSS developers will code in/on whatever language/platform suits them, not because a particular language/platform has been "blessed".IMHO Havoc is more concerned about the immediate threat posed by the enemies of the F/OSS community rather than what language/platform the developers happen to be coding in/on. (yeah, yeah. x/y is getting on my nerves too, but I've had a couple and a very long day. sue me.)
Parrot - the way Posted Mar 25, 2004 18:39 UTC (Thu) by johnjones (guest, #5462) [Link] ok sosun does not want to open its stack machine python and perl run VERY BADLY on both of these parrot is a register based Virtual Machine that... o In My Humble Opinion will run Perl Python Very well o java compiler could target o C# compiler could target o portable this is a no brainer if you thinking about architecture... regards John Jones p.s. people who want to write things now should do so in python C or java
Parrot - the way Posted Mar 26, 2004 0:28 UTC (Fri) by hinoue (guest, #6949) [Link] The operative word is "WILL". Parrot is very far from being finished and has yet to prove that it is going to replace the current Perl/Python/Ruby VMs. However, you are right that the fight over languages and libraries is a bit silly -- the fight should be over the VM.The VM ultimately chosen should be decent target for any language. This precludes using a Java VM, IMO. CLR allows for a larger set of languages, but still isn't infinitely flexible. It has the advantage that the runtime is probably unencumbered by IP issues. The .NET libraries are a different story, but presumably people writing applications for GNOME will using GNOME bindings. However, what is actually needed is really a subset of a VM - a portable intermediate representation along with a well-defined runtime model. This is not an new idea -- I recall that GCC people tried something similar a long time ago. It is an idea that is gaining ground among VM people today, though. VMs on modern systems are no longer seen an interpreters -- good VMs compile code, and the instruction sets of Java, CLR, and even Parrot aren't really great representations to do the kind of analysis for optimization that you would want. (Incidentally, there's only a tiny advantage in using a register based instruction set over a stack one. You've got to put the values in real registers at some point). Redefining the problem to this allows one to dismiss language support and library issues. It would also allow greater amount of modularity -- compilers would then be naturally split between the front end, which target the IR, and the backends, which target the native machines. Unfortunately, I know of no suitable portable IR, so we are stuck with things that already exist -- Java or Mono.
|
|||||||||||||