Am 12.09.2013 23:58, schrieb Nick Sabalausky:
On Thu, 12 Sep 2013 13:30:55 +0200
"PauloPinto" <[email protected]> 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.


My point is that there are too many few use cases, D would shine against
mainstream languages, assuming the existence of native compilers for said languages.

Since you used a few times C# as an example, would how we sell D to C# developers, in the hypothetical case .NET 5 would be native code, given the going native trend at Microsoft?

I would say the selling points would mainly be:

- system level programming features outside what unsafe blocks allow for in C#
- meta-programming abilities
- more friendly ways to manage memory manually

All capabilities related to low level coding.

--
Paulo



Reply via email to