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
