www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Patches, bottlenecks, OpenSource

reply bearophile <bearophileHUGS lycos.com> writes:
After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.

I like D, it's an alive project, but from what I've seen D so far is not having
a so significant success. I think lot of people (especially young programmers)
don't want "a better C++", they want no stinking C++ at all. They want
something quite different. (On the other hand now I am not so sure Scala will
have a widespread success, its type system makes it not easy to learn).

A C++-class language compiler is a big project that requires quite different
skill sets: in the D compiler there is work to do on the vector operations,
lent/uniqueness, multi-core, 64 bit, work for keep it well updated on
Mac/Linux/Win and well packaged, development of Phobos and its data structures,
work on the back-end to use the SSE registers and future CPUs or GPUs, tuning
of the associative arrays, future improvements of the core language,
improvements in the unit test system, large improvement in the D web site and
the documentation, big improvements needed for the GC to turn it into something
more modern, and so on. Such things have to be refined, debugged, efficient,
cared of, polished.

So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts. As D grows this will become a
bottleneck, and from what I've seen it already is. The disadvantage of allowing
other people the rights to patch the front-end is some lost control, but Walter
can review patches after they are already applied & working (in a big project
having a director is positive). This can speed up the patching process itself.
The compiler can become more like a patchwork of different programming styles,
and Walter has to ask to other people how some parts not written by him work.
This can be doable if the front-end becomes more modular. LLVM shows a more
modular design that can be copied. This is a lot of refractoring work.

Increasing openess can increase the influx of devs and their willingness to
help the project. This is quite positive and its importance can't be
underestimated.

Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ) was forked
in Cython (http://www.cython.org/ ) because Pyrex author was too much slow in
patching. A fork will not happen in D soon because there are not enough people
yet that care and work for D enough to make a fork viable. D is not a project
as alive as Pyrex. Cython is a tiny rib of the Python language circus.

I suggest to give patching rights to Don, it can be one more step forward
toward Open Sourcing D development style :-) In future such right can be given
to other few good people that have shown to deserve enough trust.

I am not sure the future of D is in the dmd back-end, llvm looks in better
shape for this purpose. LLVM is able to support 99.9% of the features of D2
(and I presume llvm devs are willing to add the few missing things if someone
gives them patches; from the unladen-swallow project I have seen they are open
enough), and it supports a large number of good features currently not
done/present by/in the back-end of dmd. Currently ldc is a compiler much better
than dmd (try it if you don't believe me!), but its devs are not appreciating
D2 language yet much. I don't like to see the Walter-locomotive so detached
from the present nice ldc D1 compiler, and from the future of LDC and llvm. I'd
still like ldc to become the official D2 compiler, developed and cared of :-)

Bye,
bearophile
Apr 10 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 10/04/10 13:09, bearophile wrote:

 After the last posts about patches, I can write something myself
 about this topic :-) I am far from being an expert of big software
 projects, but I think I am now able to understand some things of the
  D project.

 I like D, it's an alive project, but from what I've seen D so far is
  not having a so significant success.


It seems this way to me too, I wonder what needs doing to change this...
Perhaps getting the word out more will help (I believe Walter and Andrei
are giving a 1 day talk at ACCU this week, I wonder if this will have an
impact at all). I also wonder if TDPL will make a difference, I guess
we'll see.


 I think lot of people (especially young programmers) don't want "a
 better C++", they want no stinking C++ at all. They want something
 quite different. (On the other hand now I am not so sure Scala will
 have a widespread success, its type system makes it not easy to
 learn).


Speaking myself as a young programmer (probably one of the youngest D 
users), I'm not sure where I stand on this. On one hand we have to learn 
from our mistakes... If C++ didn't happen D would be as much of a mess 
as C++ is :) On the other hand, if C++ went away I wouldn't feel so 
obliged to learn an obviously inferior language. I made the choice to 
learn D before C or C++, and as a result my motivation to learn them has 
been minimal...


 A C++-class language compiler is a big project that requires quite
 different skill sets: in the D compiler there is work to do on the
 vector operations, lent/uniqueness, multi-core, 64 bit, work for keep
 it well updated on Mac/Linux/Win and well packaged, development of
 Phobos and its data structures, work on the back-end to use the SSE
 registers and future CPUs or GPUs, tuning of the associative arrays,
 future improvements of the core language, improvements in the unit
 test system, large improvement in the D web site and the
 documentation, big improvements needed for the GC to turn it into
 something more modern, and so on. Such things have to be refined,
 debugged, efficient, cared of, polished.


That is, despite the size of the paragraph... A huge list of tasks :D I 
think a lot of effort can be saved on this front by, as you mention 
below, utilizing the likes of llvm, improving and tweaking the code base 
as needed. As for the other features, I guess it's a matter of time, 
some of these things will need to wait for D3 (lent/uniqueness), others 
just need people to put in the effort.


 So as D develops and grows it will get hard for a single person to
 write all patches to the language and other parts. As D grows this
 will become a bottleneck, and from what I've seen it already is. The
  disadvantage of allowing other people the rights to patch the
 front-end is some lost control, but Walter can review patches after
 they are already applied&  working (in a big project having a
 director is positive). This can speed up the patching process itself.
 The compiler can become more like a patchwork of different
 programming styles, and Walter has to ask to other people how some
 parts not written by him work. This can be doable if the front-end
 becomes more modular. LLVM shows a more modular design that can be
 copied. This is a lot of refractoring work.


I think more and more people are noticing this recently, with about 70 
patches now in bugzilla that need filtering through and pushing into the 
code base. I don't really think a huge refactor is practical right now, 
the time is better spent working out the bugs, and generally polishing 
up the compiler (particularly the front end, which all the current 
working D compilers use). Eventually as D gains momentum this will 
become practical, and we could end up with a clang style front end for D 
(I believe this was started but didn't get too far, Dang on DSource I 
believe :)).


 Increasing openess can increase the influx of devs and their
 willingness to help the project. This is quite positive and its
 importance can't be underestimated.


The truth of this has already been visible, when the DM backend became 
source available a few months ago (but not open source), a huge 
selection of patches appeared, and as a result DMD improved. Moving to a 
more open development model for dmd, and D in general will always be a 
good thing, the evidence is all around us.


 Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ )
 was forked in Cython (http://www.cython.org/ ) because Pyrex author
 was too much slow in patching. A fork will not happen in D soon
 because there are not enough people yet that care and work for D
 enough to make a fork viable. D is not a project as alive as Pyrex.
 Cython is a tiny rib of the Python language circus.


A side-effect of being completely open, eventually people will fork the 
project, and people have to choose what to use, causing a split in the 
community... Of course there have been many positive effects from forks 
of open source projects in the past, such as new features becoming 
available, and more stable code in general. The best things about forks 
is seeing the hard work paying off and seeing the forks merged back into 
the main codebase, so the advantages of each can be enjoyed by all :)


 I suggest to give patching rights to Don, it can be one more step
 forward toward Open Sourcing D development style :-) In future such
 right can be given to other few good people that have shown to
 deserve enough trust.


I have also suggested this, it would be good to see more people with 
commit access, even if it is just one person and they have a lot of 
restrictions with what can get in etc.


 I am not sure the future of D is in the dmd back-end, llvm looks in
 better shape for this purpose. LLVM is able to support 99.9% of the
 features of D2 (and I presume llvm devs are willing to add the few
 missing things if someone gives them patches; from the
 unladen-swallow project I have seen they are open enough), and it
 supports a large number of good features currently not done/present
 by/in the back-end of dmd. Currently ldc is a compiler much better
 than dmd (try it if you don't believe me!), but its devs are not
 appreciating D2 language yet much. I don't like to see the
 Walter-locomotive so detached from the present nice ldc D1 compiler,
  and from the future of LDC and llvm. I'd still like ldc to become
 the official D2 compiler, developed and cared of :-)


I don't believe the future is in the DM backend either, I don't see it 
disappearing for a long time though. Walter's worked on that backend for 
a significant proportion of his life, I can see why he would be 
reluctant to give it up too easily. DM will continue to evolve, 
particularly as D2 becomes more stable and work on the 64bit backend 
starts (hopefully Walter will make sure this is done in such a way that 
the new 64 bit code is open source and not under the restrictive backend 
license, we'll see though :)).

I'd like to see more effort put into ldc to get it working with D2, I 
guess that unless the ldc developers find time for it, or other people 
do it won't happen for a good while yet unfortunately. I did try a while 
back, but realised what a huge task it was, and how little time I had 
available for it :/ Maybe someone else will be able to pick up where I 
left off :)


 Bye, bearophile
Apr 10 2010
parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
On 4/10/2010 8:40 AM, Robert Clipsham wrote:

 I'd like to see more effort put into ldc to get it working with D2, I
 guess that unless the ldc developers find time for it, or other people
 do it won't happen for a good while yet unfortunately. I did try a while
 back, but realised what a huge task it was, and how little time I had
 available for it :/ Maybe someone else will be able to pick up where I
 left off :)


Speaking of ldc, does anyone know how Windows support is coming?  Last I 
heard llvm was lacking support for exception handling on Windows, which 
sort of stalled things.
Apr 10 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 10/04/10 15:49, Eric Poggel wrote:

 Speaking of ldc, does anyone know how Windows support is coming? Last I
 heard llvm was lacking support for exception handling on Windows, which
 sort of stalled things.


LDC on windows works just fine, providing you don't need exceptions. 
Until LLVM supports exceptions on Windows, Windows users most likely 
won't be able to use LDC on Windows. I believe the topic has come up 
many times, but no one has been willing to implement it. You'd have to 
ask the LLVM devs for the status about it.
Apr 10 2010
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Apr 10, 2010 at 08:09:34AM -0400, bearophile wrote:

 I like D, it's an alive project, but from what I've seen D so far is not
having a so significant success.


D2 hasn't even launched to beta status yet; it is pretty premature to say
anything
about its success.

"That fetus has a heartbeat, but from what I've seen so far, it hasn't landed
 a very good job."

 

 So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts.


There's about a dozen contributors now that I know of to phobos, and about half
the things you listed are library issues - some of those things have been
improved upon in just the last couple months, and in the next couple, there's
lots more in store.

IMO, the language itself is pretty well complete. The list I have of requests
is very small and all low priority - what's left is beautifying the library,
fixing bugs, and improving performance, and D has a pretty good team on this
today.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 10 2010
prev sibling next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/10/2010 07:09 AM, bearophile wrote:

 Currently ldc is a compiler much better than dmd (try it if you don't believe
me!)

 Bye,
 bearophile


I've tried it several times recently and I don't believe you as a 
result. I have yet to see it not crash AND generate faster code than dmd.
Apr 10 2010
prev sibling next sibling parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
bearophile wrote:

 After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.
 
 I like D, it's an alive project, but from what I've seen D so far is not
having a so significant success. I think lot of people (especially young
programmers) don't want "a better C++", they want no stinking C++ at all. They
want something quite different. (On the other hand now I am not so sure Scala
will have a widespread success, its type system makes it not easy to learn).
 
 A C++-class language compiler is a big project that requires quite different
skill sets: in the D compiler there is work to do on the vector operations,
lent/uniqueness, multi-core, 64 bit, work for keep it well updated on
Mac/Linux/Win and well packaged, development of Phobos and its data structures,
work on the back-end to use the SSE registers and future CPUs or GPUs, tuning
of the associative arrays, future improvements of the core language,
improvements in the unit test system, large improvement in the D web site and
the documentation, big improvements needed for the GC to turn it into something
more modern, and so on. Such things have to be refined, debugged, efficient,
cared of, polished.
 
 So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts. As D grows this will become a
bottleneck, and from what I've seen it already is. The disadvantage of allowing
other people the rights to patch the front-end is some lost control, but Walter
can review patches after they are already applied & working (in a big project
having a director is positive). This can speed up the patching process itself.
The compiler can become more like a patchwork of different programming styles,
and Walter has to ask to other people how some parts not written by him work.
This can be doable if the front-end becomes more modular. LLVM shows a more
modular design that can be copied. This is a lot of refractoring work.
 
 Increasing openess can increase the influx of devs and their willingness to
help the project. This is quite positive and its importance can't be
underestimated.
 
 Pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ) was forked
in Cython (http://www.cython.org/ ) because Pyrex author was too much slow in
patching. A fork will not happen in D soon because there are not enough people
yet that care and work for D enough to make a fork viable. D is not a project
as alive as Pyrex. Cython is a tiny rib of the Python language circus.
 
 I suggest to give patching rights to Don, it can be one more step forward
toward Open Sourcing D development style :-) In future such right can be given
to other few good people that have shown to deserve enough trust.
 
 I am not sure the future of D is in the dmd back-end, llvm looks in better
shape for this purpose. LLVM is able to support 99.9% of the features of D2
(and I presume llvm devs are willing to add the few missing things if someone
gives them patches; from the unladen-swallow project I have seen they are open
enough), and it supports a large number of good features currently not
done/present by/in the back-end of dmd. Currently ldc is a compiler much better
than dmd (try it if you don't believe me!), but its devs are not appreciating
D2 language yet much. I don't like to see the Walter-locomotive so detached
from the present nice ldc D1 compiler, and from the future of LDC and llvm. I'd
still like ldc to become the official D2 compiler, developed and cared of :-)
 
 Bye,
 bearophile


It's all true. I also think we should use a DVCS too so that Walter can 
apply patches easily and we can upload patch branches directly to 
somewhere that can be merged and or reconciled by the original authors 
in case of conflict. It's all good. The history of the patch itself can 
also be tracked even after merging. I suggest Bazaar but I am deeply 
biased on the matter.

Further, Don et al. could act as gatekeeper to prevent Walter getting 
bogged down with too many patches. And then things will be all good and 
I may find the time to get interested in D again.
Apr 13 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.
 
 I like D, it's an alive project, but from what I've seen D so far is not
having a so significant success. I think lot of people (especially young
programmers) don't want "a better C++", they want no stinking C++ at all.


D also falls down pretty badly in terms of marketing...


 A C++-class language compiler is a big project that requires quite different
skill sets: in the D compiler there is work to do on the vector operations,
lent/uniqueness, multi-core, 64 bit, work for keep it well updated on
Mac/Linux/Win and well packaged, development of Phobos and its data structures,
work on the back-end to use the SSE registers and future CPUs or GPUs, tuning
of the associative arrays, future improvements of the core language,
improvements in the unit test system, large improvement in the D web site and
the documentation, big improvements needed for the GC to turn it into something
more modern, and so on. Such things have to be refined, debugged, efficient,
cared of, polished.


Indeed, D is targetting the most difficult language market.
But, many of the things you've listed are library things. Walter has 
successfully handed over almost all the library stuff. And really, D 
doesn't need many people working on the DMD compiler. We really need a 
lot more library development.
That's where I see the bottleneck.


 So as D develops and grows it will get hard for a single person to write all
patches to the language and other parts.
 As D grows this will become a bottleneck, and from what I've seen it already
is. 


I think the folding in of compiler patches is far from being a 
bottleneck at present, and I doubt it ever will be. Some of the top 
developers on the Linux kernel are responsible for integrating thousands 
of patches.

Currently, there are 70 open compiler patches. 30 of them come from the 
last 2 weeks. Most of the older patches are incomplete or have some 
other problem; 12 are enhancements. So the situation really isn't too 
bad at all.


 I suggest to give patching rights to Don, it can be one more step 


forward toward Open Sourcing D development style :-) In future such 
right can be given to other few good people that have shown to deserve 
enough trust.

Many people have commit rights to Phobos and druntime, yet there are 
almost 40 open Phobos/Druntime patches.

OTOH Rainer and I are flooding Walter with patches; eventually he might 
get sick of spending all his time on our patches. Although after years 
of doing all the work alone, it probably hasn't irritated him yet <g>.
Apr 15 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Apr 15 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Apr 15, 2010 at 03:41:20PM -0400, bearophile wrote:

 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,


"Yeah, I know D doesn't work on Windows, or even many Linux boxes, but it
totally uses a `modern` back end! Yeah, I know it is hard to install too, but
if you spend all day following these obscure instructions and have God
smiling upon you, you might be able to get it to run on your Game Boy! WOOO!"


...not a trade I'm willing to make.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 15 2010
parent BCS <none anon.com> writes:
Hello Adam,


 On Thu, Apr 15, 2010 at 03:41:20PM -0400, bearophile wrote:
 

 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,
 


 "Yeah, I know D doesn't work on Windows, or even many Linux boxes, but
 it totally uses a `modern` back end! Yeah, I know it is hard to
 install too, but if you spend all day following these obscure
 instructions and have God smiling upon you, you might be able to get
 it to run on your Game Boy! WOOO!"
 
 ...not a trade I'm willing to make.
 


But solve those problems...


-- 
... <IXOYE><
Apr 15 2010
prev sibling next sibling parent Justin Spahr-Summers <Justin.SpahrSummers gmail.com> writes:
On Thu, 15 Apr 2010 15:41:20 -0400, bearophile 
<bearophileHUGS lycos.com> 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


I like DMD, personally, and I've liked the benchmarks that I've seen of 
it (although lack of PowerPC support saddens me). GCC is a behemoth 
according to anyone who's ever done any work with it, and I like DMD's 
official status... even if LDC (for instance) were to become the 
"official" D compiler, the D compilation is so dependent on the LLVM 
system that it'd probably eventually run into issues like what Apple had 
with GCC not doing what they wanted; in Apple's case, they started a new 
project (clang, for those not familiar) so they could have solid control 
over the codebase.

As far as computed gotos, I think Walter explains somewhere on the D 
website that D should be an easy language for compiler writers to 
implement. I don't know the relative implementation difficulty of 
computed gotos, but I think the rationale for minimizing features 
actually in the compiler itself is sound. Reduces feature creep and all 
that good stuff.
Apr 15 2010
prev sibling parent reply Don <nospam nospam.com> writes:
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.
Apr 16 2010
parent Fawzi Mohamed <fawzi gmx.ch> writes:
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
Apr 16 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 10 de abril a las 08:09 me escribiste:

 much slow in patching. A fork will not happen in D soon because there
 are not enough people yet that care and work for D enough to make a fork
 viable.


I think there were some sort of forks in the D history. I see Ares/Tango
as a fork of the runtime, and LDC has somehow forked the front-end too to
fix some bugs. But fortunatelly there are still intentions in the
D community to merge the forks. The problem is when Walter is not
responsive enough to the merge requests.


 I suggest to give patching rights to Don, it can be one more step
 forward toward Open Sourcing D development style :-) In future such
 right can be given to other few good people that have shown to deserve
 enough trust.


I agree that having more people with some kind of commit access would
improve the situation.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
And I am not frightened of dying, any time will do, I
don't mind. Why should I be frightened of dying?
There's no reason for it, you've gotta go sometime.
If you can hear this whispering you are dying.
I never said I was frightened of dying.
Apr 19 2010