GoingNative 6: The D Episode with Walter Bright and Andrei Alexandrescu

[Walter Bright]

On 2/22/2012 7:51 PM, bearophile wrote:
> Andrei says that some new languages suffer because they have a poor
> implementation, because creating the base for a language is a lot of work.
> Today this is issue is much less of a problem, new languages are implemented
> on the JavaVM,

Using the JVM forces your program into Java semantics. For example, there are no 
structs in the JVM bytecode. No pointers, either. Nor unsigned types. Your new 
language is fairly boxed in to being a rehash of Java semantics.


> DotNetVM.

Cristi's D compiler on .NET had large problems because array slicing was not 
expressible in the .NET intermediate code. It's not nearly as bad as the JVM in 
that regard, but it's still limited.


 > System languages are implemented with LLVM.

That works if your language is expressible as C, because LLVM is a C/C++ back 
end. If your language has different semantics (like how Go does stacks), using 
LLVM can be a large problem.

Note that early C++ compilers suffered badly when they were forced into using C 
back ends, because C++ wanted new features (like COMDATs) which are not 
expressible in C and so not supported by C back ends. Ditto for any language 
feature that needs something in the back end that C/C++ doesn't need.


> Regarding the comparison between dynamic languages like Python or Ruby and D:
> what Andrei has said is not fully fair. A simple common scripting task: read
> the lines of a text file and put them in a hash. This is probably faster in
> Python compared to D. I am willing to write a benchmark too, if asked.

That would be comparing library code, not language code. Much of Python's 
implementation is in C, not Python.


> Regarding what Walter has said, that most of the code of D applications will
> be @safe: if safe code gets (or has to get) so common as he says, then it
> will be good for the D compiler to learn some tricks to avoid (optimize away)
> array bound tests in some cases.

I looked into this years ago. Very little of array bounds checking can be 
optimized away. I've been working on optimizers for 25 years now, including a 
native code generating Java compiler, and I do know a few things about how to do 
arrays.

Clang has some pretty good ideas, like the spell checker on undefined 
identifiers. But others talked about in the spiel at GoingNative have been in 
compilers for 30 years.