== Quote from Leandro Lucarella (luca@llucax.com.ar)'s article
> I know you can do separate compilation as in C/C++ writing the
> declarations in a different file, or generating/using .di files, but
> also you'll probably end up using libraries that don't do that (as
> somebody mentioned for C++ + STL) and end up in a dependency madness
> anyway. It's just not natural to do so in D, it even encourages not
> doing it as one of the main advertised features is you don't have to
> separate declarations from definitions.
> And I'm not saying that is an easy to solve problem, I'm just saying
> that I agree D doesn't scale well in terms of incremental compilations
> for big projects, unless you go against D natural way on doing things.

I think this is a perfectly reasonable design principle.  Sometimes you have to resort to things that are ugly, unsafe, a PITA, etc. to deal with some practical reality.  What D gets right is that you shouldn't have to be burdened with it when you don't need it, and the simple, clean, safe way that works most of the time should be the idiomatic way, but the ugly/unsafe/inconvenient way that works in the corner cases should be available, even if no serious effort is put into making it not ugly/unsafe/inconvenient.

Languages like C++ and Java tend to ignore the simple, common case and force you to do things the hard way all the time, even when you don't need the benefits of doing things the hard way.  Thus, these languages are utterly useless for anything but huge, enterprisey projects.

Leandro Lucarella wrote:
> I think in D you can do the same level of incremental compilation as in
> C/C++ but is not as natural. For one, in D is not natural to separate
> declarations from definitions, so a file in D tends to be dependent in
> *many* *many* other files because of excessive imports, so even when you
> can do separate compilation, unless you are *extremely* careful (much
> more than in C/C++ I think) you'll end up having to recompile the whole
> project even you change just one file because of the dependency madness.

That's why dmd can *automatically* generate .di files. But still, even writing .di files by hand cannot be any harder than writing a C++ .h file.


> I know you can do separate compilation as in C/C++ writing the
> declarations in a different file, or generating/using .di files, but
> also you'll probably end up using libraries that don't do that (as
> somebody mentioned for C++ + STL) and end up in a dependency madness
> anyway. It's just not natural to do so in D, it even encourages not
> doing it as one of the main advertised features is you don't have to
> separate declarations from definitions.
> 
> And I'm not saying that is an easy to solve problem, I'm just saying
> that I agree D doesn't scale well in terms of incremental compilations
> for big projects, unless you go against D natural way on doing things.

In no case is it worse than C++, and as soon as you import a file more than once you're faster.

Walter Bright wrote:
> Walter Bright wrote:
>> http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html
>>
>> I'll be doing a followup on why D compiles fast.
> 
> On reddit:
> 
> http://www.reddit.com/r/programming/comments/d2wwp/why_c_compiles_slow/

Hacker News:

http://news.ycombinator.com/item?id=1617133

On 8/19/2010 11:13 AM, Leandro Lucarella wrote:
> Andrei Alexandrescu, el 19 de agosto a las 08:50 me escribiste:
>> On 08/19/2010 07:48 AM, Eldar Insafutdinov wrote:
>>>> I'll be doing a followup on why D compiles fast.
>>>
>>> I will say the contrary. Compiling medium size projects doesn't matter in either
>>> language. But when the size of your project starts getting very big you will have
>>> troubles in D because there is no incremental compilation.
>>
>> I'm a bit confused - how do you define incremental compilation? The
>> build system can be easily set up to compile individual D files to
>> object files, and the use the linker in a traditional manner.
>
> I think in D you can do the same level of incremental compilation as in
> C/C++ but is not as natural. For one, in D is not natural to separate
> declarations from definitions, so a file in D tends to be dependent in
> *many* *many* other files because of excessive imports, so even when you
> can do separate compilation, unless you are *extremely* careful (much
> more than in C/C++ I think) you'll end up having to recompile the whole
> project even you change just one file because of the dependency madness.
>
> I know you can do separate compilation as in C/C++ writing the
> declarations in a different file, or generating/using .di files, but
> also you'll probably end up using libraries that don't do that (as
> somebody mentioned for C++ + STL) and end up in a dependency madness
> anyway. It's just not natural to do so in D, it even encourages not
> doing it as one of the main advertised features is you don't have to
> separate declarations from definitions.
>
> And I'm not saying that is an easy to solve problem, I'm just saying
> that I agree D doesn't scale well in terms of incremental compilations
> for big projects, unless you go against D natural way on doing things.
>
>

I link my game engine (20kloc) with derelict, which is much larger.  On my 5 year old laptop, it takes about 3-4 seconds to compile the engine, importing the non di'd derelict headers, and linking with the derelict lib.  If I compile the whole lot, it takes about 30 seconds.

Just wanted to share some real-world stats.

dsimcha:
> What D gets right is that you shouldn't have to be burdened with it when
> you don't need it, and the simple, clean, safe way that works most of the time
> should be the idiomatic way, but the ugly/unsafe/inconvenient way that works in
> the corner cases should be available, even if no serious effort is put into making
> it not ugly/unsafe/inconvenient.
> 
> Languages like C++ and Java tend to ignore the simple, common case and force you to do things the hard way all the time, even when you don't need the benefits of doing things the hard way.  Thus, these languages are utterly useless for anything but huge, enterprisey projects.

When you compile a Java program the compiler is able to find and fetch the files it needs. DMD isn't able to. So Java is more handy for small projects composed of something like 10-20 files. So I don't agree with you.
(It's a feature I've asked for in my second message on the D newsgroups.)

Bye,
bearophile

Thu, 19 Aug 2010 15:52:25 -0400, bearophile wrote:

> dsimcha:
>> What D gets right is that you shouldn't have to be burdened with it when you don't need it, and the simple, clean, safe way that works most of the time should be the idiomatic way, but the ugly/unsafe/inconvenient way that works in the corner cases should be available, even if no serious effort is put into making it not ugly/unsafe/inconvenient.
>> 
>> Languages like C++ and Java tend to ignore the simple, common case and force you to do things the hard way all the time, even when you don't need the benefits of doing things the hard way.  Thus, these languages are utterly useless for anything but huge, enterprisey projects.
> 
> When you compile a Java program the compiler is able to find and fetch the files it needs. DMD isn't able to. So Java is more handy for small projects composed of something like 10-20 files. So I don't agree with you. (It's a feature I've asked for in my second message on the D newsgroups.)

Having written several university assignments in Java, small (< 500 LOC) to medium size (50000 LOC), I haven't encountered a single compilation related problem. One exception to this are some bindings to native code libraries -- you need to be careful with URLs when packaging external libraries inside a JAR.

The class centric programming paradigm often gets in your way when programming in the small, but it's quite acceptable on large scale IMO. How is Java so utterly useless and D much better? Any use cases?

Walter Bright, el 19 de agosto a las 11:00 me escribiste:
> >I know you can do separate compilation as in C/C++ writing the declarations in a different file, or generating/using .di files, but also you'll probably end up using libraries that don't do that (as somebody mentioned for C++ + STL) and end up in a dependency madness anyway. It's just not natural to do so in D, it even encourages not doing it as one of the main advertised features is you don't have to separate declarations from definitions.
> >
> >And I'm not saying that is an easy to solve problem, I'm just saying that I agree D doesn't scale well in terms of incremental compilations for big projects, unless you go against D natural way on doing things.
> 
> In no case is it worse than C++, and as soon as you import a file more than once you're faster.

Is worse in the sense that you have the feeling that is free in D, but it's not. In C++ you *have* to be careful, otherwise the compiler eats you. In D, when this starts to be significant, you already have a huge project.

And again, I agree that it might be a very reasonable trade-off, but that doesn't mean the problem doesn't exist. That's all. I'm not trying to convince anyone that C++ is better, I'm just saying in C++ the problem is obvious while in D is much less visible, and you note it *only* when your project is big enough and you *need* incremental compilation.


And I know also that DMD (and every DMD-based D compiler) can generate .di files. It would be really nice to have a -M option like GCC that automatically writes Makefile dependencies. But that's another topic.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
A veces quisiera ser un barco,
para flotar como floto siendo humano,
y no hundirme como me hundo

== Quote from retard (re@tard.com.invalid)'s article
> Thu, 19 Aug 2010 15:52:25 -0400, bearophile wrote:
> > dsimcha:
> >> What D gets right is that you shouldn't have to be burdened with it when you don't need it, and the simple, clean, safe way that works most of the time should be the idiomatic way, but the ugly/unsafe/inconvenient way that works in the corner cases should be available, even if no serious effort is put into making it not ugly/unsafe/inconvenient.
> >>
> >> Languages like C++ and Java tend to ignore the simple, common case and force you to do things the hard way all the time, even when you don't need the benefits of doing things the hard way.  Thus, these languages are utterly useless for anything but huge, enterprisey projects.
> >
> > When you compile a Java program the compiler is able to find and fetch the files it needs. DMD isn't able to. So Java is more handy for small projects composed of something like 10-20 files. So I don't agree with you. (It's a feature I've asked for in my second message on the D newsgroups.)
> Having written several university assignments in Java, small (< 500 LOC)
> to medium size (50000 LOC), I haven't encountered a single compilation
> related problem. One exception to this are some bindings to native code
> libraries -- you need to be careful with URLs when packaging external
> libraries inside a JAR.
> The class centric programming paradigm often gets in your way when
> programming in the small, but it's quite acceptable on large scale IMO.
> How is Java so utterly useless and D much better? Any use cases?

I didn't mean my comment in terms of the compilation system.  I meant it as a more general statement of how these languages eschew convenience features.  Examples:

The class centric paradigm is one example.

The ridiculously fine grained standard library import system.  If you really want to make your imports this fine-grained, you should use selective imports.

Strictly explicit, nominative typing.

Lack of higher order functions and closure just because you **can** simulate these with classes, even though this is horribly verbose.

No RAII, scope statements, or anything similar just because you **can** get by with finally statements, even though this is again horribly verbose, error-prone and unreadable.

The requirement that you only have one top-level, public class per file.

Lack of default function arguments just because these **can** be simulated with overloading, even though this is ridiculously verbose.

Lack of operator overloading just because you **can** use regular method calls, even though properly used operator overloading makes code much more succinct and readable.

"dsimcha" <dsimcha@yahoo.com> wrote in message news:i4k4b4$jsj$1@digitalmars.com...
>
> I didn't mean my comment in terms of the compilation system.  I meant it
> as a more
> general statement of how these languages eschew convenience features.
> Examples:
>
> The class centric paradigm is one example.
>
> The ridiculously fine grained standard library import system.  If you
> really want
> to make your imports this fine-grained, you should use selective imports.
>
> Strictly explicit, nominative typing.
>
> Lack of higher order functions and closure just because you **can**
> simulate these
> with classes, even though this is horribly verbose.
>
> No RAII, scope statements, or anything similar just because you **can**
> get by
> with finally statements, even though this is again horribly verbose,
> error-prone
> and unreadable.
>
> The requirement that you only have one top-level, public class per file.
>
> Lack of default function arguments just because these **can** be simulated
> with
> overloading, even though this is ridiculously verbose.
>
> Lack of operator overloading just because you **can** use regular method
> calls,
> even though properly used operator overloading makes code much more
> succinct and
> readable.

Yea. If Java's design philosophy were a valid one, there would never have been any reason to move beyond Altair-style programming (ie, entering machine code (not asm) in binary, one byte at a time, via physical toggle switches). You *can* do anything you need like that (It's Turing-complete!).

Nick Sabalausky wrote:
> Yea. If Java's design philosophy were a valid one, there would never have been any reason to move beyond Altair-style programming (ie, entering machine code (not asm) in binary, one byte at a time, via physical toggle switches). You *can* do anything you need like that (It's Turing-complete!).

Yeah, and I've seen OOP done in C, and it works. It's just awful. I've even seen OOP done in assembler (Optlink!).