Patches, bottlenecks, OpenSource

[Fawzi Mohamed]

On 16-apr-10, at 09:12, Don wrote:

> bearophile wrote:
>> Don:
>>> And really, D doesn't need many people working on the DMD compiler.<
>> I agree, it's like having many people working around a dead corpse  
>> trying to revive it. Better use the time to adopt gcc and llvm back- 
>> ends at their best, keeping in mind, while designing D, that there  
>> are features that those back-ends have and the dmd back-end doesn't  
>> have that it will be good to add to the language. Simple example:  
>> refusing computed gotos because they are a lot of work to implement  
>> is not a justification that holds if both gcc and llvm already  
>> implement them and allow the front-end to just use them in a simple  
>> enough way.
>> Bye,
>> bearophile
>
> That's not what I meant. The fraction of the community working on  
> compilers should be very small.
>
> BTW the DMD backend really has very few bugs. Historically, much  
> less than 1% of the bugs in DMD are in the backend. Currently there  
> are 2 open backend bugs, and they're both extremely obscure.

Yes I agree with your point of view, D is good enough to be used  
seriously, you don't think that many persons should work actively on D  
or its compiler.
Actually I don't want to work on the compiler, I am actually afraid of  
touching it too much because I like to go low level at times, and I am  
very afraid of what working seriously on a compiler would mean for my  
productivity.
Work on actual programs and libraries is much more important now.
Yes the language is not perfect, but you know no language ever is,  
different languages allow you to express different things with  
different ease, and all have their problems and pitfalls.

In my opinion D sticks reasonably well to perl tenet "easy things  
easy, difficult things possible".
Now users should not have to redevelop everything from scratch, either  
because there are no libraries or due to limitations of libraries.
Library and application development is a major undertaking, it is not  
just an application of the language, also there much creativity, and  
(as it must be a practical thing) also working around bugs.

Bearophile is right that problems of the toolchain are also problems  
of a language.

I saw what I consider one of the most beautiful languages for  
numerics, one that could map mathematical concepts cleanly, die due to  
that.
It was Aldor and  had very nice things.
Templates for example unlike the C++ tradition don't automatically  
apply on all possible matching types, but had to be explicitly  
instantiated. This might seem like a drawback, but you could create  
templated modules that had exported several templates at once.
The result was that for example even the use of symbols like [] for  
array construction could be overridden, and do different things  
depending on the types and and the imported things: import  
List(Integer) and Array(Float) and [1,2,3] would be a list, and  
[1.0,2.0,3.0] an array. Import also List(Float) and you had to  
disambiguate...

Type inference was very powerful, so that one could very often avoid  
declaring the type, it was performed also on the return type, so one  
could implement FromInteger and fromRational and get automatic casting  
that did the right thing.

There ways to easily extend a library type, or create a copy based on  
the original but with some differences (sort did always use the  
default comparison operator, but one could easily feed to it an in  
place converted type that had a different ordering.
Aldor also had a powerful CTFE, and being strongly typed and  
templatized it was fast.

And the list goes on and on. Still where is this language? Did anybody  
here even know it? I don't think so because it died. The compiler was  
never sold standalone, only a part of the (expensive) Axiom.
The compiler was very complex, and had been paid a lot of money (it  
went from IBM to NAG), and nobody knew exactly what to do, they tried  
to opensource it, but never fully (hoping to reap back some money, and  
for difficult copyright status of some pieces?), so that people got so  
annoyed by not having a compiler or critical library parts available,  
and having strange restrictions, supporting only few platforms, not  
being able to see the full source to fix things, until everybody left.

I just burned several hours looking in what happened to the various  
projects in the meantime. I have to say, that while Aldor is still  
dead that I was pleasantly surprised to find FriCAS, Open-Axiom and  
Axiom reasonably alive and progressing using the fully free Aldor  
precursor SPUD (but being lisp based I think not as good for heavy  
numerics).

Lukily D (sorry for the aside on aldor) is in a much better shape the  
frontend is fully opensource, and source for everything is available.

dmd backend is reasonably good for windows and 32 bit development.
For serious numeric and computation 64bit is kind of needed,  
especially if you run on clusters maintained by other that have  
(rightly) switched to 64 bits.
There ldc and llvm look like very good future proof choice as backend  
for linux,osx, and probably soon also various things (GPU,  ARM,...  
are progressing quickly), but definitely not for windows at the moment.
I understand bearophile frustration, and share it up to a point (I am  
still firmly D 1.0 for these reasons), but llvm is not always better  
than the dmd backend.
That said for my applications it looks like the best choice for the  
present and close future (with ldc and D 1.0).

Fawzi