Move VisualD to github/d-programming-language ?

[Nick Sabalausky]

On Thu, 12 Sep 2013 13:30:55 +0200
"PauloPinto" <pjmlp at 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.