On 12 September 2013 02:06, Brad Anderson <eco@gnuk.net> wrote:

> On Wednesday, 11 September 2013 at 06:31:50 UTC, Rainer Schuetze wrote:
>
>>
>>
>> On 10.09.2013 20:03, Andrei Alexandrescu wrote:
>>
>>> On 9/10/13 9:31 AM, Brad Anderson wrote:
>>>
>>>> On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote:
>>>>
>>>>> Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.)
>>>>>
>>>>> Andrei, myself and Rainer (VisualD's champion) are all in agreement on
>>>>> this.
>>>>>
>>>>> What do you think?
>>>>>
>>>>
>>>> Since it's official I think it'd be nice to add to the Windows Installer.  I'll get started adding it if you or Andrei give me the go ahead.
>>>>
>>>
>>> Yes please. Make it an opt-out choice.
>>>
>>
>> Alternatively, I could add dmd to the Visual D installer. If the files are actually inside the package, I guess it is a bit easier this way because the Visual D installer does quite a bit of registration and patching.
>>
>> But both installers use NSIS, so it shouldn't be a big deal to merge them either way.
>>
>>
>>
>>>  Once dub is a bit more mature I think it too should be added to the
>>>> installer.
>>>>
>>>
>>> That should probably be in all installers.
>>>
>>>
>>> Andrei
>>>
>>
> I was just going to have the DMD installer download Visual-D's installer and run it.  Seemed like the easiest approach.  This would make it so Visual-D's releases aren't tied to DMD's and people could upgrade Visual-D independently if a new release comes out.  Every release of DMD we'd just update the Visual-D installer URL to match the current release.
>

Or just point at 'latest' somehow?

The most important thing is that the Visual-D installer doesn't need to ask the user where he chose to install DMD only a few seconds prior.

On Wed, 11 Sep 2013 08:57:59 +0200
"PauloPinto" <pjmlp@progtools.org> wrote:

> On Tuesday, 10 September 2013 at 21:25:41 UTC, Walter Bright wrote:
> > On 9/9/2013 11:35 AM, Russel Winder wrote:
> >> C++11 has revitalized C++ in ways that are only just showing themselves.
> >
> > That's true.
> >
> >> This is a threat to D gaining traction.
> >
> > I'm less sure about that. I think it presents an opportunity for us. 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.
> 
> Your 1-4 points are already covered by existing languages for traditional line of business applications, specially given the fact that even current VM based languages have native compilers available.
> 
> Putted another way, how well do the 1 - 4 bullet points stand against Java/C#/Scala/Clojure native compilers ?
> 

Points #1 and #2 (performance computing and the draw towards native languages) are *both* about these two things:

A. Lack of the VM "middleman" sucking up resources.

B. Low-level capabilities.

The native compilers for VM languages (With the possible exception of C#) can only address point "A" at best. And even C# is a bit awkward at point "B".

Giving a VM language a native compiler is only going half-way. The language itself is geared towards, and therefore limited by, the need to be runnable in a VM. That places inherent limitations on the potential benefits of native compilation. So while it's technically native-compiled, it's just bolted-on as an afterthought.

Just because I add a turbocharger to a sedan doesn't mean it's comparable to a McLaren or a Bugatti.

On Thursday, 12 September 2013 at 06:58:53 UTC, Nick Sabalausky wrote:
> On Wed, 11 Sep 2013 08:57:59 +0200
> "PauloPinto" <pjmlp@progtools.org> wrote:
>
>> On Tuesday, 10 September 2013 at 21:25:41 UTC, Walter Bright wrote:
>> > On 9/9/2013 11:35 AM, Russel Winder wrote:
>> >> C++11 has revitalized C++ in ways that are only just showing themselves.
>> >
>> > That's true.
>> >
>> >> This is a threat to D gaining traction.
>> >
>> > I'm less sure about that. I think it presents an opportunity for us. 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.
>> 
>> Your 1-4 points are already covered by existing languages for traditional line of business applications, specially given the fact that even current VM based languages have native compilers available.
>> 
>> Putted another way, how well do the 1 - 4 bullet points stand against Java/C#/Scala/Clojure native compilers ?
>> 
>
> Points #1 and #2 (performance computing and the draw towards native
> languages) are *both* about these two things:
>
> A. Lack of the VM "middleman" sucking up resources.
>
> B. Low-level capabilities.
>
> The native compilers for VM languages (With the possible exception of
> C#) can only address point "A" at best. And even C# is a bit awkward
> at point "B".
>
> Giving a VM language a native compiler is only going half-way. The
> language itself is geared towards, and therefore limited by, the need
> to be runnable in a VM. That places inherent limitations on the
> potential benefits of native compilation. So while it's technically
> native-compiled, it's just bolted-on as an afterthought.
>
> Just because I add a turbocharger to a sedan doesn't mean it's
> comparable to a McLaren or a Bugatti.

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.

--
Paulo

On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote:
> I don't get the point, what there is VM like when I compile Java, Scala, F#, C# native code?
>

Compiling such language to native code require horribly convoluted code generation. For instance, an helloworld in java compilled natively with gcj gives you a 50Mb (!) binary blob.

On Thursday, 12 September 2013 at 15:55:26 UTC, deadalnix wrote:
> On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote:
>> I don't get the point, what there is VM like when I compile Java, Scala, F#, C# native code?
>>
>
> Compiling such language to native code require horribly convoluted code generation. For instance, an helloworld in java compilled natively with gcj gives you a 50Mb (!) binary blob.

GCJ also doesn't offer improved performance over the JVM for non-trivial code. It will reduce the startup time, since no JIT is needed, but beyond that it doesn't really offer benefits.

Not sure about other VM->native compilation

On Thu, 12 Sep 2013 09:22:18 -0700, Trent <anon@nope.avi> wrote:

> On Thursday, 12 September 2013 at 15:55:26 UTC, deadalnix wrote:
>> On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote:
>>> I don't get the point, what there is VM like when I compile Java, Scala, F#, C# native code?
>>>
>>
>> Compiling such language to native code require horribly convoluted code generation. For instance, an helloworld in java compilled natively with gcj gives you a 50Mb (!) binary blob.
>
> GCJ also doesn't offer improved performance over the JVM for non-trivial code. It will reduce the startup time, since no JIT is needed, but beyond that it doesn't really offer benefits.
>
> Not sure about other VM->native compilation

Microsoft built the Singularity OS using a special full-native compiler for C# called Sing#. Very cool piece of technology that I really wish they would release to the public: http://en.wikipedia.org/wiki/Sing_Sharp

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Am 12.09.2013 17:55, schrieb deadalnix:
> On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote:
>> I don't get the point, what there is VM like when I compile Java,
>> Scala, F#, C# native code?
>>
>
> Compiling such language to native code require horribly convoluted code
> generation. For instance, an helloworld in java compilled natively with
> gcj gives you a 50Mb (!) binary blob.

gcj is a lame example. The project is dead since 2009 and they hardly invested anything into optimizing compiler. Just blindly translating bytecodes directly to processor instructions.

Native code generation has *nothing* to do with binary size. Have you tried to statically compile similar examples in other languages?

Lets use Oberon as an example for my native point.

GC enabled systems programming language created to write operating systems. So same space as D, but also same space as Java and Go because
it does not allow disabling the GC.

Wirt used it to write Native Oberon, originally targeting the Ceres workstation at Zurich Technical University. System that was used for a few years by students and professors, even for daily desktop tasks.

At ETHZ, there were native code compilers for Oberon, interpreters and
they even played with the idea of JIT compiling dynamic modules on load
using a kernel level JIT.

So does Oberon use require VM ?

If one wants to misuse the VM term to mean runtime library, then all high level languages have a VM even ANSI C.


--
Paulo

Am 12.09.2013 18:45, schrieb Adam Wilson:
> On Thu, 12 Sep 2013 09:22:18 -0700, Trent <anon@nope.avi> wrote:
>
>> On Thursday, 12 September 2013 at 15:55:26 UTC, deadalnix wrote:
>>> On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote:
>>>> I don't get the point, what there is VM like when I compile Java,
>>>> Scala, F#, C# native code?
>>>>
>>>
>>> Compiling such language to native code require horribly convoluted
>>> code generation. For instance, an helloworld in java compilled
>>> natively with gcj gives you a 50Mb (!) binary blob.
>>
>> GCJ also doesn't offer improved performance over the JVM for
>> non-trivial code. It will reduce the startup time, since no JIT is
>> needed, but beyond that it doesn't really offer benefits.
>>
>> Not sure about other VM->native compilation
>
> Microsoft built the Singularity OS using a special full-native compiler
> for C# called Sing#. Very cool piece of technology that I really wish
> they would release to the public: http://en.wikipedia.org/wiki/Sing_Sharp
>

You mean this?

http://singularity.codeplex.com/

--
Paulo

Am 12.09.2013 18:22, schrieb Trent:
> On Thursday, 12 September 2013 at 15:55:26 UTC, deadalnix wrote:
>> On Thursday, 12 September 2013 at 11:30:57 UTC, PauloPinto wrote:
>>> I don't get the point, what there is VM like when I compile Java,
>>> Scala, F#, C# native code?
>>>
>>
>> Compiling such language to native code require horribly convoluted
>> code generation. For instance, an helloworld in java compilled
>> natively with gcj gives you a 50Mb (!) binary blob.
>
> GCJ also doesn't offer improved performance over the JVM for non-trivial
> code. It will reduce the startup time, since no JIT is needed, but
> beyond that it doesn't really offer benefits.
>
> Not sure about other VM->native compilation

It is a waste of time to bring up gcj as an example, it is an outdated compiler, frozen in time (2009), where not much effort was spent in optimizing code.

If one wants to compare performance of Java native compilers, Aonix,
Excelsior JET and Websphere Real Time JVM are better examples.

Again there is no such thing as VM -> native compilation, it is always
an implementation decision.

I really hate all this VM/Managed code concepts introduced by Sun/Microsoft. Before we used to discuss implementation techniques
for programming languages, compiled/interpreted/jitted, not VM vs native.

--
Paulo

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