On 12/20/2012 8:06 PM, Andrei Alexandrescu wrote:
On 12/20/12 10:06 PM, bearophile wrote:
Walter Bright:
There'd also be a revolt here if circular importing were removed.
I didn't ask for the removal of circular importing. (But I suggest to
read the rationale of the Go designers.)
I did read the piece and found it surprisingly weak. The problems with C's
modularity are misidentified. The entire discussion on include guards is
irrelevant because it's been obsoleted by today's compilers, which trivially
recognize include guards. The problem of bloated includes in C and C++ does
exist but its causes are different.
Then, the approach to simplifying smacks of making the lives of the implementer
easier while passing the buck to the user.
Other issues:
1. Error for unused imports. This can be extremely irritating if you're trying
to find the source of a bug by commenting out swaths of code. Also, Go doesn't
have conditional compilation, another large source of irritation if unused
imports are errors.
2. Name for module must match file name. Again, a nuisance if you're trying to
rearrange code looking for a problem. If you want to always have the module name
match the file name, just omit the module statement.
> That nice article about the Go language shows that in the long run and for
larger projects a little bit more strictness is a better decision.
It makes a claim, it does not show it.
D has an excellent module system. No, I don't think Go or anyone else has a
better one.
