View mode: basic / threaded / horizontal-split · Log in · Help
December 24, 2011
Re: Carmack about static analysis
On 12/24/11 9:45 AM, Jakob Ovrum wrote:
> On Saturday, 24 December 2011 at 15:33:04 UTC, Andrei Alexandrescu wrote:
>> Anyhow, is there anything you have in mind that we have the chance of
>> improving at this point?
>>
>>
>> Thanks,
>>
>> Andrei
>
> For one, we should follow up on:
>
> foo!(a => a * 2)(bar);
>
> vs.
>
> foo!((a) { return a * 2; })(bar);

OK.

Andrei
December 24, 2011
Re: Carmack about static analysis
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
December 24, 2011
Re: Carmack about static analysis
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/ ?

Bye,
bearophile
December 24, 2011
Re: Carmack about static analysis
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
December 24, 2011
Re: Carmack about static analysis
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.
December 24, 2011
Re: Carmack about static analysis
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
December 24, 2011
Re: Carmack about static analysis
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
December 24, 2011
Re: Carmack about static analysis
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?
December 24, 2011
Re: Carmack about static analysis
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
December 24, 2011
Re: Carmack about static analysis
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home