Why new languages and not generic vm?
JaBi
different preferences. On desktop platform we have wide range of
programming languages from wide range of authors. On web platform not.
Yes, there exists any crosscompilers to javascript but it is dirty
compromise.
Let's make standard virtual machine (as for example .net) and various
developers will make wide range of quality programming languages with
compilers to the virtual machine.
+ extensibility and universality
+ interoperability between codes in different languages
+ data traffic reduction - bytecode instead of sourcecode
+ better performance - no lexical analysis on clients
+ easier implementation of virtual machine on various platform
...
Florian Bösch
without a dozen-year multidisciplanary effort to create a new holy
grail of VMs. Just keep it simple stupid.
Cláudio Silva
so, a substancial part of the effort to create a universal virtual
machine is already done.
It probably just needs a few special opcodes to allow other kinds of
languages.
There is also already other similar efforts one can draw inspiration
(or even more) from, like, for example, the Parrot VM. Hey, why
reinvent the weel? There are already good and tested solutions. And
Google could improve them, instead of starting from scratch.
So, I don't think it would take a dozen years, and the benefits would
far outweight the effort.
Also, as no one will ever agree on the perfect language for the web,
it would end the debate once and for all: use the language you love
best! And, if there is no compiler for it yet, you could create one,
and no more would we be dependent on the browser makers, committees,
standards groups, lobbies, etc.
As I see it, it would be the only way to solve the problem of
improving the programming language of the web, and probably, the only
way for all browser makers to implement a common solution, as I don't
believe most of them will ever agree on Dart (or any other specific
language).
Florian Bösch
> TL;DR just implement my pet idea of the holy grail VM which we
> can totally plug together from existing components in 3 minutes,
> and we've solved 100% of 100% of all problems the web ever had.
> because nobody can agree on a language ever. So dart is totally backwards
> and necessary and just google for Java/Parrot/.Net VM or whatever
In my experience, you've got to let people do what people want to do,
and obviously, they don't want to do your pet idea. I also don't like
your pet idea, because such projects always take forever (see Parrot
VM, PyPy, the Java VM, any Java/.Net language integration etc.). I
actually quite like the idea of hacking down a simple solution that
solves a lot of what is wrong with JS right now, and just works.
Rico P
They shook the world with AJAXified search engine, then gmail.
I believe, they have a strong reason why they choose to create a
(slightly) new language.
Just like when they supported Android.
I will stand to watch their progress, to see the brighter path they
are creating with this.
Don't worry google teams, 1st time always the hardest one.
Keep up the good work!
rgrds,
Rico
Zexx
waiting for everyone to create their VM for their preferred language,
what should we use right now for complex applications? JavaScript?
That would just stall the progress.
It's probably better this way. Make a new language aimed at larger
projects, then when all problems are sorted out introduce uniform byte-
code so that independent producers can implement VM's for their langs.
Torsten Bronger
Zexx writes:
> VM is actually a good idea, but maybe not right now. Because while
> waiting for everyone to create their VM for their preferred
> language,
Why limit the VM to one language? You establish *one* VM on the
client side, and you can deploy a whole family of languages with it.
Tschö,
Torsten.
--
Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
Florian Bösch
> Why limit the VM to one language? You establish *one* VM on the
> client side, and you can deploy a whole family of languages with it.
net. How is the bytecode coming into existence?
A: The bytecode needs to be compiled from source.
Q: at which time does this happen?
A: at the time that you are done modifying your source and hit the
compile button
Q: Where do you get the compile button from?
A1: from an IDE
A2: by a serverside on bytecode request compiler
A3: by a command line compiler
Q1: I don't use an IDE, do I have to?
A: no right answer to that.
Q2: I don't have a server that can execute code...
A: no right answer to that.
Q3: what's a command line?
A: no right answer to that.
Q: When the bytecode gets to the browser, how can I debug it?
A: the debugger needs to display the source.
Q: Where does the VM/debugger get the source from
A: it has to be transferred as well
Q: How does that work?
A1: inlined into the bytecode
A2: requested by sideload
Q: What is the point of transfering bytecode AND source, that's even
more data then just source.
A: no right answer to that.
Q: Why can't the Browser compile the source to bytecode?
A: The browser doesn't know how to parse it because it has no
implementation of your language.
Q: How does the browser get an implementation of your language?
A: Source could declare an implementation of your language which the
VM loads to convert your language to bytecode.
Q: What is the point of transfering an entire language implementation
AND source everytime I load a Dart script?
A: no right answer to that.
See the terminal nodes where answers run into "no right answer for
that" as to why people don't do what you suggested.
Torsten Bronger
Florian Bösch writes:
> On Oct 12, 1:11 pm, Torsten Bronger <torsten.bron...@gmail.com> wrote:
>
>> Why limit the VM to one language? You establish *one* VM on the
>> client side, and you can deploy a whole family of languages with
>> it.
>
> [...]
>
> Q: What is the point of transfering bytecode AND source, that's
> even more data then just source.
>
> A: no right answer to that.
You wouldn't transfer source code. Instead,
<script type="application/my-great-vm" src="/path/to/bytecode.vm"/>
would only load bytecode.
Rémi Forax
Once you have done that, you need to ensure the compatibility against
that binary format instead of doing that against the source format.
Binary compatibility is really hard to maintain,
this is what Java does, this is by example why it's hard to reified
generics in Java.
So providing a generic VM has a high cost.
R�mi
On 10/12/2011 01:37 PM, Torsten Bronger wrote:
> Hall�chen!
>
> Florian B�sch writes:
>
>> On Oct 12, 1:11 pm, Torsten Bronger<torsten.bron...@gmail.com> wrote:
>>
>>> Why limit the VM to one language? You establish *one* VM on the
>>> client side, and you can deploy a whole family of languages with
>>> it.
>> [...]
>>
>> Q: What is the point of transfering bytecode AND source, that's
>> even more data then just source.
>>
>> A: no right answer to that.
> You wouldn't transfer source code. Instead,
>
> <script type="application/my-great-vm" src="/path/to/bytecode.vm"/>
>
> would only load bytecode.
>
> Tsch�,
> Torsten.
>
Zexx
correct it).
Of course one needs only one VM for all the languages. But each
language needs a compiler that produces code for the universal VM. It
could take a while before someone decides to produce such a compiler.
But if one is introducing a new language and compiler and VM, then you
already have a working solution.
There is one advantage of having a common programming language: Huge
code base. If most programmers use the same lang, you don't have to
worry about not finding enough examples, not having libraries that
solve your problem, not having a market for your own libraries, or not
finding someone who can answer your question on the forums. There will
always be somebody to solve the problem. And, well, yes, someone to
take your job too :(
> Q: What is the point of transfering bytecode AND source, that's even
> more data then just source.
> A: no right answer to that.
the browser? Makes no sense. If web apps are distributed as bytecode
(in the future) then only the bytecode needs to be transferred.
Browsers won't have to compile anything.
Cláudio Silva
1. the source code is loaded on demand, only when necessary to display
error information.
2. The browser comes with an integrated language (DART) and debugger,
but the browser also allows the download of byte code compiled from
other languages.
In that case, when an error occurs, the internal debugger is not used
and instead, the user must have installed an external debugger and the
browser session must have been invoked from that debugger, establishing
a communication channel between them.
That is the way it works with the Flash player, its VM, and the
downloaded abc bytecode, and it works fine!
If one wants to debug a program, one should use the appropriate tools.
The browser doesn't have to do it all.
But still, I believe the browser should have one predefined language
with an integrated debugger, for all those people who just want to use
notepad (or vim).
Em 11/10/12 12:37, Torsten Bronger escreveu:
> Hall�chen!
>
> Florian B�sch writes:
>
>> On Oct 12, 1:11 pm, Torsten Bronger<torsten.bron...@gmail.com> wrote:
>>
>>> Why limit the VM to one language? You establish *one* VM on the
>>> client side, and you can deploy a whole family of languages with
>>> it.
>> [...]
>>
>> Q: What is the point of transfering bytecode AND source, that's
>> even more data then just source.
>>
>> A: no right answer to that.
> You wouldn't transfer source code. Instead,
>
> <script type="application/my-great-vm" src="/path/to/bytecode.vm"/>
>
> would only load bytecode.
>
> Tsch�,
> Torsten.
>
Florian Bösch
+bytecode. How do you think you're gonna debug bytecode?
On Oct 12, 2:02 pm, Cláudio Silva <claudiombsi...@gmail.com> wrote:
> 1. the source code is loaded on demand, only when necessary to display
> error information.
into possession of the bytecode in the first place, you need to
provide a lot of tooling beyond the browser, so a default (no tooling
required) language is quite mandatory.
> 2. The browser comes with an integrated language (DART) and debugger,
> but the browser also allows the download of byte code compiled from
> other languages.
> In that case, when an error occurs, the internal debugger is not used
> and instead, the user must have installed an external debugger and the
> browser session must have been invoked from that debugger, establishing
> a communication channel between them.
different languages (introduced by a dozen libraries you use), does
your debugger implement them all? How do get support for the 12th
language from? The idea to optionally request source to debug by the
browser, and properly annotate bytecode with source positions seems
more attractive, so the browser can act as debugger to whatever source
you throw at it.
Torsten Bronger
Florian Bösch writes:
> To the others who suggested/asked by there needs to be source
> +bytecode. How do you think you're gonna debug bytecode?
Of course, while you *debug* your code, you let the browser load
source code and use special tools/plugins to debug it. For example,
I use Firebug for JavaScript. For Dart, we need such special tools,
too.
Zexx
source from your local disk.
2. If you're coding on a local machine, but testing on a remote
server, then only the bytecode has to be uploaded/downloaded. Source
code stays on your local machine so debugger can load it fast.
3. If both the source code and bytecode are on the remote machine,
again, browser doesn't have to download the entire source code. Only
if an error / breakpoint is encountered, the filename/line will be
loaded from debug info and only that source file will be displayed.
It's also assumed your IDE will have a (synchrnonized) copy of the
sources from the remote machine, so basically the source is always on
your local disk.
John Tamplin
John A. Tamplin
Software Engineer (GWT), Google
Florian Bösch
> ...
Tell you what, since all generic and completely good solutions have
obviously been done and all you need is plug it together. Why don't
you
1) grab the JVM
2) embedd webkit
3) ... (maybe call it a day, or perhaps 5 minutes)
4) success/profit
Rémi Forax
> It is hard to imagine some "super VM" that runs many languages can run
> any of them as efficiently as one that is designed for the needs of a
> particular language. While you can compile many languages to run on
> the JVM and some of them execute faster than their native
> implementation, none of them are particularly competitive
> performance-wise with Java on the same JVM.
If you talk about JRuby and Jython, it's more due to the fact that their
specification
(Ruby/Python) was written with an interpreter in mind.
> Scala isn't bad, but then it was designed around the capabilities of
> the JVM.
That's true, by example, Scala has changed its number representation to
match the boxing/unboxing done by Java.
>
> Even considering bytecode vs source, you have to do verification on
> the bytecode you download so you don't open security exploits, and
> from earlier discussions with the VM guys it is just as fast to parse
> the source as to verify the bytecode.
I don't think it's true with the linear verifier introduced in Java 6
but as I said,
in my opinion, the best argument for using the source directly is that
you don't have to care about binary compatibility.
>
> I think the answer you are looking for is snapshots, which will
> basically load an isolate in the VM from a pre-started state saved in
> compressed binary form (and generating that snapshot allows dead code
> elimination as well). I don't know how the verification issue is
> handled in this case, but that is the plan for addressing startup
> performance of the VM.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
Rémi
John
either.
That said, VM solutions are already a proven success, in the form of
Flash and to a lesser extent Silverlight and Java.
The fact that Flash has terrible financial and freedom barriers-to-
entry, yet still is taking over the web, shows the level of demand for
a VM solution even when it is done badly.
So a fully open-source VM with no strings attached would probably
rule. It would run on every platform and cost $0 for any beginner to
start learning. It would start with one language, and gradually
support many.
Think about it. If Javascript outperforms virtual machines, then why
did Apple allow Javascript but ban Flash & Java when they shut out App
competition on their mobile devices? Clearly Javascript performance
isn't real competition, but compiled bytecode is.
Josh Leverette
First, never, ever set up a QA list with dumb repetitive answers
unless you are the expert in charge. Just because you lack the answer
does not imply the answer is nowhere to be found.
Secondly, I think a middle ground solution is at least worth looking
into. You could have a JavaScript library load on page load that would
compile your sources into an intermediate language -- very similar to
what Microsoft does with the .NET framework -- and then each browser
could have at it, optimizing the intermediate language code as they
see fit when converting it to byte code for actually running it.
Almost all scripting languages are converted to byte code before any
code is executed, which improves run time performance by a good deal.
The intermediate language would have the benefit of being there when
debugging needs to happen, and ILs may not be as readable as the
original, but they are legible so you could possibly understand why
the problem is occurring and fix it. Then you only need one debugger.
Once your code is working properly and you're ready to publish it, you
could feed it through a compiler which would generate the IL code,
that way end users don't have to spend CPU cycles on an outdated
JavaScript library to compile your code, but if you somehow couldn't
deal with that eventuality, you could keep the source code raw and
send it to the users along with the JS library which would handle it
in their end, and would not significantly impact load times.
This leaves flexibility for browser makers to tout faster dart code
execution and all that other stuff due to better IL -> byte code
assemblers.
Thirdly, some of you say it is not possible to make different
languages execute efficiently on one VM. I say to you, look at .NET,
because it allows multiple languages to interop and it runs all of
them efficiently still. In fact, mono is an open source implementation
that you could read the exact means by which it all works.
My final note is that some of you keep referring to flash as a
wonderful example of how even a poorly done VM is so much better than
JavaScript. Consider this: before HTML5, and back when JS was super
slow, flash was an excellent way to write games and interactive web
apps. So people learned that environment. It is difficult to teach an
old dog new tricks, and so those same people have continued to release
flash app after flash app and cause the Internet to be a sadder place.
You can write 3D games with not too shabby performance using HTML5
(webgl) and JS and run them in a browser. There is nothing that is
inherently 'domination' in a VM compared to a well done scripting
language. JS may not be very well done, but that's because we've
outgrown it. We need something designed for multicore processors and
which has better integration with the target system. A VM is better,
but not by the margin most of you believe, in my humble opinion. Dart
is a huge deal because it is a language with many, much more powerful,
features than JS ever had. JS was a weak language in several ways. If
someone implemented JS on top of the Dart VM, it would still be as
miserable as ever.
On Oct 12, 10:04 am, John <jcatke...@gmail.com> wrote:
> First, Dart or a VM are both better than Javascript. I applaud
> either.
>
> That said, VM solutions are already a proven success, in the form of
> Flash and to a lesser extent Silverlight and Java.
>
> The fact that Flash has terrible financial and freedom barriers-to-
> entry, yet still is taking over the web, shows the level of demand for
> a VM solution even when it is done badly.
>
> So a fully open-source VM with no strings attached would probably
> rule. It would run on every platform and cost $0 for any beginner to
> start learning. It would start with one language, and gradually
> browser.
> Think about it. If Javascript outperforms virtual machines, then why
JaBi
I see elsewhere. Development of technologies on the web to real
possibilities of their use is slow (due to old browsers in user's
devices, standardization process etc.). If will be available a
universal virtual machine
a) better and more quickly pushed to the browsers - there is not a
dispute about which language is better (which is partly a subjective
thing - depends on the programmer and the problem that solves)
b) brings an entirely new possibilities especially for complex
applications
c) allow the rapid development languages and tools with the real
possibility of immediate use (it will work without having to changes
and uppdate browsers)
Demand for such things is quite large. For example jQuery and many
other JS libraries introduces a different language (DSL) in
JavaScript.
Here is a list of different languages and tools that can be
"compiled" to JavaScript:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
An example of the Virtual Machine is universal. NET,. List of
compilers yet implemented to the CLI:
http://en.wikipedia.org/wiki/List_of_CLI_languages
Although JavaScript is outdated language for complex projects, but as
the browser will look like when they will be JavaScript, DART, and
soon many other languages in feature?
Applications on the web will be more complex then now. Web platform is
a long-living thing and needs a systemic solution.
angelo
web apps.
But Java is.
However, there are some reasons Java wasn't much used on the client
side:
- Java was meant to be used for applets, i.e. rectangles in html
pages that
were managed entirely by java code that displayed graphical
objects and
provided callbacks to handle the events on them.
- as a result, it has always been difficult for web designers to
provide the
graphics of web pages in html, and the code in Java. They then
reverted to
javascript
- the current means to implement DOM callbacks in Java is to
provide some
javascript code that calls some java method contained in an
hidden applet.
Quite involved, you see.
- there is no simple way to make browsers reload applets, which
makes
debugging difficult.
These problems are mainly due to lack of integration between browsers
and the
current Java implementatios. There is no problem for the language as
such.
I am tempted to think that the best, at least for web developers,
would be to
have Java better integrated with browsers. It would allow them to use
the wealth
of Java libraries already developed.
Pedro Rodrigues
need to solve some perceived flaws in JavaScript. But Dart certainly
isn't going to be perfect either, so probably it's only going to be a
matter of time until someone creates a new language to solve the flaws
in Dart. If we keep spawning the creation of a new language everytime
we get annoyed with the existing ones, soon enough we'll have several
languages competing to be the standard language for Web development.
That isn't to say that I don't appreciate Dart. As a language Dart
seems good to me, and I'd definitely prefer it over JavaScript for
complex Web Development. However we are still trying to cling to the
idea that there can be a one-size-fits-all language for Web
Development, and the experience with JavaScript should be a strong
hint that that is not possible. Dart may be good for many problems,
might be appealing for many developers, but there will also be many
developers that dislike Dart and many situations where Dart is just
not the appropriate tool for the job.
I think the sooner we all realize that no single language can
dominate, the better for Web Development's sake. I believe the ideal
solution would definitely be some kind of universal VM. That way each
programmer could program in whatever is the language of he's
preference. The only major downside I see with this approach is coming
up with a VM that performs efficiently for any language.
John Tamplin
That isn't to say that I don't appreciate Dart. As a language Dart
seems good to me, and I'd definitely prefer it over JavaScript for
complex Web Development. However we are still trying to cling to the
idea that there can be a one-size-fits-all language for Web
Development, and the experience with JavaScript should be a strong
hint that that is not possible. Dart may be good for many problems,
might be appealing for many developers, but there will also be many
developers that dislike Dart and many situations where Dart is just
not the appropriate tool for the job.
I think the sooner we all realize that no single language can
dominate, the better for Web Development's sake. I believe the ideal
solution would definitely be some kind of universal VM. That way each
programmer could program in whatever is the language of he's
preference. The only major downside I see with this approach is coming
up with a VM that performs efficiently for any language.
Charles Forsyth
believe the ideal> solution would definitely be some kind of universal
up with a VM that performs efficiently for any language.
"world peace".
More seriously, since UNCOL was proposed in the late 1950s(!),
there have been many such attempts (from Janus to ANDF). Although a
few were surprisingly
effective, most were not widely adopted nor did many survive.
I suggest the idea is fundamentally flawed. Although it's true you
can compile many things to the JVM, it is not a *good* Abstract Machine
for a wide range of languages: functional ones with lazy evaluation,
languages with strong support for concurrency, dynamic languages,
languages that aren't inherently object-oriented. Other languages compile
to the JVM not because it's a good match, but because it's an existing
platform that's not uncommon (although still far from universal).
The whole point of an Abstract Machine is that it's tailored to a particular
language or language family to provide primitives that an ideal machine
for that language would provide. Thus, the JVM is at heart designed for
Java; it implements primitives that an ideal machine for Java would have.
(You can also design more than one Abstract Machine for a language, each
with different trade-offs.) Prolog had (has?) WAM. Some are high-level (JVM);
some are really low-level abstract processors (eg, INTCODE), losing
type information.
Other languages can get by if they compile their ideal primitives into
(say) method
calls within the JVM, but as far as I know they don't get to add new
machine operations.
As you add more language types, you end up heading for a lowest common
denominator:
it's just like compiling to x86 code, in fact, except that some things
are probably easier
to compile to x86 machine code than to the JVM, despite x86 being a
pitiful architecture!
Torsten Bronger
Charles Forsyth writes:
> [...]
>
> [...] I suggest the idea is fundamentally flawed. Although it's
> true you can compile many things to the JVM, it is not a *good*
> Abstract Machine for a wide range of languages: [...]
>
> [...] As you add more language types, you end up heading for a
> lowest common denominator: it's just like compiling to x86 code,
> in fact, except that some things are probably easier to compile to
> x86 machine code than to the JVM, despite x86 being a pitiful
> architecture!
The VM needn't be optimal for all languages but just good
enough(tm).
If Dart is successful, there will be compilers for transforming all
significant Web languages to Dart. While this works (as for
JavaScript now), I'd prefer a client-side VM instead.
Charles Forsyth
wrote:> If Dart is successful, there will be compilers for
transforming all> significant Web languages to Dart. While this works
(as for> JavaScript now), I'd prefer a client-side VM instead.
for some sort of machine, even generating method calls in JVM,
instead of telescopic translation through another
programming language (and that reasonably high-level).
As with Dart to JavaScript, or Ratfor to FORTRAN, the latter meets an immediate
need, but the former is more satisfying for a compiler writer. For one
thing, you can choose the code sequences, and it takes longer and pays better.
It's worth looking at "Compiler Design: Virtual Machines" (Wilhelm &
Seidl, 2010)
[ http://goo.gl/xIegD ] to pick a recent example,
just to see the range of radically different abstract machine
architectures, to suit
four or five different classes of programming languages.
Also, I'd re-emphasise that portability isn't the main reason to use
an abstract machine:
the big gain is that it provides an ideal target machine, and
offers separation of concerns when implementing a compiler,
and the technique works well for that.
Still, if someone put a half-way decent (documented) one into every
browser, I'd not complain.
Perhaps a Dart abstract machine might fit the bill. (But if you're
designing one with
Isolates in mind, and with that as the basis for security,
that machine probably looks different from one with support for
shared-memory concurrency.)
angelo
user input
and performing some action in response to it. There could be cases in
which
such actions are so complex as to require hundreds of thousands of
lines
of code. I think that in such cases the designers should consider
carefully
to move that code to the server side. Executing very large apps from
inside
browsers is stretching too much the intended scope of browsers.
That said, most of the times client apps need conventional imperative
languages.
There could be some corner cases in which the functional ones are a
better fit,
but that happens rather seldom.
I guess that the majority of web designers would be quite happy to
have a good
client-side, imperative language to use, that is able to interact
easily with the
objects in web pages as well as with the underlying operating system
(with
appropriate security policies enforced).
Having a VM that supports several languages is something that could
turn useful
in very few cases.
What is then needed is either to improve javascript (e.g. adding
concurrency and
modularity, which are its major limits), or inventing a new one, or
improving the
integration of java with browsers.
is one of its
Pedro Rodrigues
saying is that I find it more likely that major browsers vendors agree
upon one VM, than in a single programming language. Even if that VM is
tailored for one language or a class of languages, I think it's a
better compromise than a single language that runs efficiently. This
would leave the trade-offs decisions of choosing a language for his
next Web application, to the programmer where it should be.
If I choose to program in Ruby I know that although I'd write less
code, my application won't be as fast as if I had programmed in C. In
desktop applications I have the freedom to make those trade-offs when
it makes sense. I don't see why we shouldn't have the same freedom for
Wep applications.
I had never heard about NaCl before, but from a quick glance it seemed
like an interesting approach.
JaBi
is also not completely universal, but rather allows the efficient
running programs written in many languages. The reason "can not
implement effective wholly universal virtual machine" I consider it
wrong. It is true that the most efficient fully universal virtual
machine can not be done, but one that can be realistically
implemented, is sufficient in practice and significantly better than
one language support. It allows for further development, without
requiring changes in the browsers.
On Oct 15, 11:31 am, Charles Forsyth <charles.fors...@gmail.com>
wrote:
Michael Hendricks
On 15 October 2011 01:36, Pedro Rodrigues <rfd...@gmail.com> wrote:
I believe the ideal solution would definitely be some kind of universal
VM.
It's best to think of that as the computing equivalent of asking for
"world peace".
Florian Loitsch
--Michael
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett
JaBi
language is suitable for that purpose. Many conventional language,
without adaptation is practically useless to run in the browser as a
replacement for JavaScript. I would expect rather the creation of new
languages that are inspired by existing languages like Java, C #,
Python, Ruby, PHP, Basic, etc.
It is seen on existing compilers to JavaScript:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
If be a little effort to create a universal virtual machine, is meets
this purpose, even if the virtual machine is not quite universal.
Torsten Bronger
JaBi writes:
> The virtual machine may not be quite general. Not every programming
> language is suitable for that purpose. Many conventional language,
> without adaptation is practically useless to run in the browser as a
> replacement for JavaScript. I would expect rather the creation of new
> languages that are inspired by existing languages like Java, C #,
> Python, Ruby, PHP, Basic, etc.
You mean a plethora of MyFavouriteLanguageSCRIPT languages like
C#Script, PythonScript, RubyScript? Perish the thought! Instead,
you should slightly adapt all these *existing* languages for the
browser.
lascarayf
Rémi Forax
as I understand they will share the same DOM.
So a nice project will be to reuse the C interface used by DartVM
to plug the JVM instead.
R�mi