On 12/24/11 9:54 AM, Derek wrote:
> I'm sure you are totally correct; I'm not really a C++ coder. And I'm
> sure you also process the specialist/expert level of D knowledge to make
> reading contemporary D code a non-issue.
Well I'm also a specialist in C++, actually more so than D as I have
longer experience with C++ and wrote more code in it.
> But when compared to spoken
> language text, D code can appear quite obtuse to average coders. And I
> believe this is main do to the very high use of non-alphabetic symbols
> and a level of overloading of both punctuation characters and reserved
> words.
This issue (analogy with human language) has been a long preoccupation
of me. I have ended up at an odd point - I lost interest.
Analogies of programming language with human language are flawed and
take nowhere interesting. The only text that gets close to the level of
precision and non-ambiguity needed is legal text; reading any amount of
legal text blunts one's desire to be more like it.
Second, natural language text has a very different use pattern. A body
of natural language text is meant to be written once and then read many
times; the notion that people need to maintain, enhance, and modify a
large body of natural language text is quite foreign. It follows that
programming language code must optimize for different directions.
Third, analogy with math is inevitable; math is the most concise means
known by humankind to encode theories. A good part of mathematics is
dedicated to inventing good notation, and math notations have inevitably
shunned natural language.
Andrei

Derek Parnell:
> But isn't lint written by humans?
Right, but this doesn't mean a lot, because most programs don't work the same way humans and human brains think.
>I'm under the impression that a //lint// program is an attempt to emulate a very pedantic (if not anal-retentive) person who in real life would have no real friends, due to their obsessiveâ€“compulsive habit for extreme nit-picking.<
But the mind of such person and a lint work in very different ways. So they are often able to spot different classes of problems.
>The article you reference is primarily saying that this specific lint-like functionality contains bugs. It is not an argument to convince us to abandon lint functionality.<
Both my post and that link weren't meant to abadon lints, I like the idea of lints :-) I have shown that blog post as an example of the wide difference between lints skills and human programmers skills.
>I once, long ago, suggested to Walter/Andrei that D is approaching the ASCII equivalent of APL.<
I have used the K language a bit, that is one "ASCII equivalent" of APL, and it's nowhere D both in semantics, readability, and conciseness :-) Writing K code is more like solving a puzzle. And reading it is like solving a different puzzle.
Bye,
bearophile

On 12/24/2011 12:38 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> the notion that people need to maintain, enhance, and modify a
>> large body of natural language text is quite foreign.
>
> http://www.wikipedia.org/ ?
Wikipedia's text often shows an effect of maintenance similar to source code -
additions are often jarring and break up the flow.

Andrei Alexandrescu:
>Anyhow, is there anything you have in mind that we have the chance of improving at this point?<
Two things that I think are able to improve the D code (beside a shorter lambda syntax) are Python Lazy/eager array comps (I'd like to write a post about this...).
If this is not possible then I think introducing amap and afilter (that means array(map()) and array(filter())) in Phobos is able to remove several parentheses from my current D code.
Bye,
bearophile

On 12/24/11 2:55 PM, bearophile wrote:
> If this is not possible then I think introducing amap and afilter
> (that means array(map()) and array(filter())) in Phobos is able to
> remove several parentheses from my current D code.
I've never gotten why you wouldn't define amap and afilter for your own
code, thus avoiding parentheses.
Andrei

On Saturday, 24 December 2011 at 12:42:41 UTC, bearophile 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.
I think code would have a lot fewer bugs if we forced all
identifiers
to be one character long. Then it'd be a lot shorter.
Let's enforce this in the language. Walter? Andrei?

On Sun, 25 Dec 2011 07:19:47 +1100, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:
> On 12/24/11 9:54 AM, Derek wrote:
>> I'm sure you are totally correct; I'm not really a C++ coder. And I'm
>> sure you also process the specialist/expert level of D knowledge to make
>> reading contemporary D code a non-issue.
>
> Well I'm also a specialist in C++, actually more so than D as I have
> longer experience with C++ and wrote more code in it.
LOL ... that went without saying ... your reputation precedes you.
>> But when compared to spoken
>> language text, D code can appear quite obtuse to average coders. And I
>> believe this is main do to the very high use of non-alphabetic symbols
>> and a level of overloading of both punctuation characters and reserved
>> words.
>
> This issue (analogy with human language) has been a long preoccupation
> of me. I have ended up at an odd point - I lost interest.
I'm sorry that I wasn't clear enough (irony?) but I'm not advocating that
programming languages resemble human languages, just that in comparison -
comparing D text with English text for example - D source code can be
harder to read. Probably because D relies much more on the precise use of
punctuation symbols than English text does. Our latin-alphabet focused
training has to take in a larger character set, and with nearly all D
punctuation being single-character entities, one has to read the text more
carefully than English text.
I am not suggesting that D change any of this because that would turn D
into something else and thus alienate most of its adherents.
--
Derek Parnell
Melbourne, Australia

Adam D. Ruppe:
> I think code would have a lot fewer bugs if we forced all
> identifiers
> to be one character long. Then it'd be a lot shorter.
I was talking about the abundance of (({}){()}) and not about identifiers length.
When they think about code conciseness (that is quite correlated with bug count, as Carmack too says) they refer to something more like tokens number, instead of character count.
Bye,
bearophile