Move VisualD to github/d-programming-language ?

[Paulo Pinto]

Am 12.09.2013 23:58, schrieb 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.
>

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