Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

JVM, CLR &etc. - do we still need these higher-level VMs when LLVM is available?

77 views
Skip to first unread message

samue...@gmail.com

unread,
Jul 26, 2014, 3:47:03 AM7/26/14
to
Dear all,

For sometime now I have held the opinion that the advantages of higher level virtual machines are dwarfed by the advantages of lower level virtual machines.

Often I am purporting to Java engineers that C++ (&etc.) are better languages because of their compiler architecture, speed, portability and sheer power.

A common argument in the C++ vs Java debate is one of binary portability. Nowadays though cross-compilers are commonplace, so I don't feel this argument holds much weight.

Other arguments are about type safety, overflow handlers &etc.; all of which are [optionally] handed by modern compiler systems (even for languages like C and C++). Arguments about concision, unicode support, standardisation and functional capabilities have been mostly pushed aside thanks to the latest (C11 and C++11) standards.

Due to my strong opinions on Java, C# &etc. I have forgone learning how to work with interesting systems such as Hadoop, Mahout, Nutch and Luscene. Recently I have started learning how to work with these systems as a matter of necessity (I don't have the time to rewrite them in a lower-level language).

Without defending Java, C#, Scala, F#, Cobra, Groovy, Clojure, Golo, Boo, Eiffel &etc. based on cool/big projects/frameworks built with them; can you help convince me that:
- High level virtual machines really aren't that bad, and though LLVM (and similar) has their place, they are not the future

Thanks,

Samuel Marks
/in/samuelmarks

PS: Before you mention it, I am aware of VMKit

lam...@gmail.com

unread,
Jul 26, 2014, 5:21:45 AM7/26/14
to
The effect of Moore's law is exponentially falling value of computational efficiency, relative to programmer time. As such, the future belongs to more expressive languages (efficient in programmer time), not more computationally efficient languages (efficient in computation time).

Sure, you'll always be able to find a place in optimizing computation efficiency, but that will be an ever-shrinking slice of programming, until/unless the relative scarcity changes.
0 new messages