On 11/18/2013 1:14 AM, Jacob Carlborg wrote:
Sure, what I'm saying is that you can do stupid things with other features than
macros.
Yes, you can write terrible code with all features.
My point is not that you can do stupid things with macros. It is that macros
encourage this to a high degree, and in fact the flexibility that macros have
over lazy parameters / expression templates / mixin templates are exactly those
features that are abused to the point it is hard to see much good come from
them. I am not making this up, this is what happens with macro systems again and
again. I know this is a difficult position to argue from and convince people about.
D has a deliberate lack of capability in some areas because long experience
shows that little good comes from them. Examples include lack of ability to
overload && and ||, and lack of expression support for version statements. This
is not because these features are hard - they're easy to implement. I've seen
attempts to replace version statements with static if in order to get back the
ugliness, and the result is ugly and unnecessary and damned hard to figure out
what was actually intended and why it didn't work.
I fear that implementing these things with the idea that they'll somehow be used
with restraint is a pipe dream and that D will degenerate into an ugly snarl
that everyone hates, and then some D-Go will be invented that everyone will
cheer because it won't allow such code to be written.
Case in point - again and again I see utterly wretched use of macros in C++ from
the top level of C++ programmers who really ought to know better. Want to see a
lovely example? Take a look at the C header files for openssl:
https://github.com/D-Programming-Deimos/openssl/tree/master/C
This is not unusual.
I try to put my money where my mouth is. If you look at older parts of dmd,
you'll see macro abuse that I cleverly wrote. The newer bits contain fewer and
fewer use of any macros, and I've made an ongoing effort to try and eliminate
all of it (yebblies has campaigned to get rid of it, too, even crap I tried to
hang on to). This has been done this without compromise on performance and
usability and readability of the code - and I hope you'll agree that it looks
nice without the usual rat's nest of preprocessor abuse one sees in typical C++
code.
