About Go, D module naming

[Paulo Pinto]

On Friday, 21 December 2012 at 05:42:04 UTC, Walter Bright wrote:
> 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.
>

Actually it does have one, it is part of Go's toolchain.

Go developers favor the way I advocate to write portable C and 
C++ code.

No preprocessor, instead create OS/Compiler specific files for 
the platform, for example:

btree.c
btree_windows.c
btree_linux.c
btree_solaris.c

The toolchain will then pick all required files depending on your 
target architecture.

The less one uses the preprocessor the better, specially when 
working in code that outlives programmers. Personally I hate 
#ifdef hell.

As for the other points, you're right.

--
Paulo