On Thu, 12 Sep 2013 13:30:55 +0200 "PauloPinto" <pj...@progtools.org> wrote: > > I don't get the point, what there is VM like when I compile Java, > Scala, F#, C# native code? > > How it is different from compiling Apple/Object/Turbo/Think > Pascal, Delphi, Modula-2, Modula-3, Ada, OCaml, Oberon, Haskell, > D, Go, Rust to native code? > > There is no VM about it, other than implementation details. > > Is the lack of access to processor resources what makes some of > them VM languages? > > Then even ANSI C is a VM language, given that what gives the > language lower hardware access capabilities are all language > extensions. >
Let me try to clarify my main point, since I may have been a bit unclear: I don't really mean to debate "VM vs native" here; I'm aware (as you are) that a normally-VMed language can be made to be every bit as fast and powerful as any normally-native-compiled language. Heck, all you need is a VM that interprets/JITs the LLVM's bytecode, and then bam, all of a sudden C/C++ are VM languages. That "VM vs native" isn't what I was really trying to address. I was only trying to address a couple very specific points in your and Walter's discussion about "D vs languages like Java/C#/Scala/Clojure". And not *all* normally-VM languages in general, but specifically ones along those particular lines (frankly, the more popular ones). Walter had said: > I think [the C++ resurgence] presents an opportunity > for [D]. Driving the C++ resurgence is: > > 1. demand for high performance computing > > 2. turning back towards native languages > > 3. recognition of the value of functional-style programming > techniques > > 4. recognition of the value of safety, encapsulation, etc. I'll concede to your point that #3 and #4 are addressed not only by D but also by several normally-VMed languages (to varying levels of success). However, and this is the core of what I was trying to say: I'm disputing that most of those other popular normally-VMed languages address Walter's #1 and #2 *as effectively* as D does. My reasoning for that goes like this: - Walter's point #1, "demand for high performance computing" is *partly* about avoiding the runtime/startup costs of interpretation/JIT, but it's *also* about being able to reach down to the low-level when necessary (pointers, reinterpret casts, manual memory management, etc.) - Walter's point #2, "turning back towards native languages" has much the same duality: It's *partly* about performance, but *also* about being able to access the hardware (ex: drivers, OS-level stuff, certain embedded systems, reduced electricity usage, reduced memory footprint (ex: for phones/tablets with little or no virtual mem), etc.) - While it's certainly *possible* for a normally-VMed language to offer full low-level abilities, most of them don't (or at least most of the popular ones don't), and the ones that do (ex: C#, AIUI) don't usually (ever?) do it on a level that's on par with C/C++/D. And I think the fact that most normally-VMed languages lack, or skimp on, low-level abilities is no coincidence: There's a natural tendency for that specifically because two of the main reasons for using a VM in the first place are A, the safety of being banned from low-level access and B, the increased cross-platform portability achieved by not accessing low-level. Again, it's not that normally-VMed languages can't/never get around that (C#/.NET found ways around it), but that they *typically* don't, and even when they do it's typically (if ever?) not up-to-par with C/C++/D.