Jarrett Billingsley schrieb:
On Wed, Jul 22, 2009 at 6:30 PM, Walter
Bright<[email protected]> wrote:
Much of D's improvements appear to be small, but the aggregate is large
enough that once you write a project in D, you'll find it pretty hard to go
back to another language.
This is EXACTLY the point I always try to make to newcomers. It's so
significant that I think it should be on the front page of the
language spec, in bold, 72 point, red letters.
Seconded.
Even though the road is paved with obstacles I can't imagine going back
to C++ or any other language.
By obstacles I mean among others:
- D1<->D2 and Phobos<->Tango problem - esp. when creating a library that
shall be compilable with any combination the end user wants you have to
use a lot of versions and aliases to accommodate that, like it is done
in DFL.
- dozens of more or less abandoned projects that aren't usable with
latest compilers anymore,
- furthermore many users tend to maintaining their own fork rather than
contributing to the project, thus useful functionality is often spread
and sometimes even unknown cause the fork isn't publicly available
- lack of IDEs, Descent is pretty good (and the only one regularly
updated), but still has a long way to go. It's only reasonably usable
with dsss, but rebuild is horribly outdated and always gets trapped in
an infinite loop when using D2 and sometimes also refuses to work with D1.
xf.build is still in the early stages and using the compiler directly is
out of question.
The newly added -deps parameter is probably a step forward, but wouldn't
it be possible to simply include that rebuild functionality in dmd?
I mean if it is possible to scan the dependencies and write them to a
file, it shouldn't be that hard to simply add those found modules to the
"working queue", should it?
Build tools could then concentrate on the stuff dsss actually does like
project management, installing and so on (which it does in a brilliant
way imho, I really like the dsss.conf style)
