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
