On 24.12.2011 16:33, Andrei Alexandrescu wrote:
On 12/24/2011 09:11 AM, Derek wrote:
On Sat, 24 Dec 2011 23:42:41 +1100, bearophile
<bearophileh...@lycos.com> wrote:
In theory functional-style is a good to shrink the code, but in D
functional-style code is a jungle of (({}){()}) so it's hard to write
and hard to read.
As I mentioned once, the proposition of writing functional code in D is
quite a bit different from other languages. In languages dedicated to
pure or almost pure functional semantics, there may literally be no
other way to achieve anything except in functional style; if there is,
the style is almost invariably stilted.
In D, functional style code must compete with a well honed imperative
paradigm. And as unpleasant as that may be, sometimes code that uses
mutation may be "better" than functional code by some metrics.
I once, long ago, suggested to Walter/Andrei that D is approaching the
ASCII equivalent of APL. The actual text of D source code can be a
hindrance to reading the code, let alone understanding what has been
written. I know it is hyperbole, but some D source modules are close to
write-only code, meaning that it takes specialist/expert D knowledge to
understand some source code. I'm not so certain that this is a desirable
feature of any programming language.
We recently discussed this a bit in connection with the standard
library. It definitely could be written in a manner that is easier to
understand for the more casual reader, but that would mean reducing the
capabilities (e.g. no reduce with multiple parameters) and making it
slower.
That being said, I personally find contemporary application D code very
readable. It's a pleasure to get to it after using C++ at work.
Anyhow, is there anything you have in mind that we have the chance of
improving at this point?
Improved syntax for compile-time reflection. is() expressions,
especially is(typeof()), and __traits, are the least readable parts of
the language. They inevitably lead to a mass of braces and parentheses.
