What are the worst parts of D?

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 24 21:23:11 PDT 2014


On 9/24/14, 9:15 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 07:05:32PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 9/24/14, 6:54 PM, H. S. Teoh via Digitalmars-d wrote:
>>> On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>>>> On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
>>>>> You're misrepresenting my position.*In spite of their current
>>>>> flaws*, modern build systems like SCons and Tup already far exceed
>>>>> make in their basic capabilities and reliability.
>>>>
>>>> Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be
>>>> the change you want to see in dlang's build system" :o). -- Andrei
>>>
>>> Well, Cliff & I (and whoever's interested) will see what we can do
>>> about that. Perhaps in the not-so-distant future we may have a D
>>> build tool that can serve as the go-to build tool for D projects.
>>
>> Sounds like a fun project. In case you'll allow me an opinion: I think
>> dependency management is important for D, but a build tool is highly
>> liable to become a distraction. Other ways to improve dependency
>> management are likely to be more impactful.
> [...]
>
> Clearly, the more automatic dependency management can be, the better.
> In an ideal world, one should be able to say, "here is my source tree,
> and here's the file that contains main()", and the build tool should
> automatically figure out all the dependencies as well as how to compile
> the sources into the final executable. In pseudocode, all one needs to
> write should in theory be simply:
>
> 	Program("mySuperApp", "src/main.d");
>
> and everything else will be automatically figured out.
>
> But of course, this is currently not yet fully practical. So some amount
> of manual dependency specification will be needed. But the idea is to
> keep those minimal.

Actually you can't do this for D properly without enlisting the help of 
the compiler. Scoped import is a very interesting conditional dependency 
(it is realized only if the template is instantiated).

Also, lazy opening of imports is almost guaranteed to have a huge good 
impact on build times.

Your reply confirms my worst fear: you're looking at yet another general 
build system, of which there are plenty of carcasses rotting in the 
drought are plenty left and right of highway 101.

The build system that will be successful for D will cooperate with the 
compiler, which will give it fine-grained dependency information. 
Haskell does the same with good results.


Andrei




More information about the Digitalmars-d mailing list