Super-dee-duper D features

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Tue Feb 13 21:27:17 PST 2007


Kevin Bealer wrote:
> X Bunny wrote:
>> Kevin Bealer wrote:
>>> X Bunny wrote:
>>>> Kevin Bealer wrote:
>>>>>
>>>>> 2. The syntax doesn't provide visual hints that let you read a 
>>>>> program.
>>> What I mean, is this (from the Computer Language Shootout):
>>>
>>> (defun ack (x y)
>>>   (declare (fixnum x y))
>>>   (the fixnum
>>>     (if (zerop x)
>>>     (1+ y)
>>>       (if (zerop y)
>>>       (ack (1- x) 1)
>>>     (ack (1- x) (ack x (1- y)))))))
>>>
>>> as compared to this:
>>>
>>> int Ack(int x, int y)
>>> {
>>>     if (x == 0) {
>>>         return y + 1;
>>>     } else if (y == 0) {
>>>         return Ack(x-1, 1);
>>>     } else {
>>>         return Ack(x-1, Ack(x, y-1));
>>>     }
>>> }
>>>
>>> These two things do the same thing in the same way, but the structure 
>>> and syntax make the C example much more readable.  If I want to know 
>>> input and output types, I can find them.  When I see the top of the 
>>> if/elseif/else structure, I can find each part.  It's layed out like 
>>> a table, rather than like a ball of yarn.
>>
>> If the C was indented like this would it be as unreadable as the Lisp?
>>
>> int ack(int x, int y)
>> {
>>     if(x == 0)
>>     { return y + 1; }
>>         else if(y == 0)
>>         { return ack(x-1, 1); }
>>             else {
>>                 return ack(x-1, ack(x, y-1));
>>             }
>> }
> 
> Yes - indenting badly makes it less readable in either case; I'm not 
> sure if I was indenting the LISP example in a reasonable way. (I took it 
> from someone else's page.)
> 
>> (I cant even match up all the brackets with that one!)
>>        My editor indents the Lisp like this:
>>
>> (defun ack (x y)
>>   (declare (fixnum x y))
>>   (the fixnum
>>     (if (zerop x)
>>     (1+ y)
>>       (if (zerop y)
>>       (ack (1- x) 1)
>>     (ack (1- x) (ack x (1- y)))))))
>>
>> The structure is no less obvious to me then the C. I can see the input 
>> and output types are clearly fixnums. The branches of the ifs are 
>> obvious.
> 
> Maybe one day it will be for me if I keep trying to do things in LISP, 
> but I can't shake the feeling that I'm learning to shoe horses -- a 
> skill that had its place and time.
> 
>>> More importantly, I can understand *parts* of this code without 
>>> understanding the whole thing.
>>
>> Mmmm I dont what to say about that, for me with the Lisp I can do the 
>> same.
>>
>> Bunny
> 
> Actually, I can understand the structure in both languages for this 
> simple example without too much trouble.  But the LISP one is a lot 
> 'slower' for me to scan with my eyes.  Some of that is a learned reflex, 
> of course, but personally I don't think all of it is.
> 
> My point is less about indentation than the other aspects of syntax. For 
> one thing, the '(){};,' punctuation, which for me, is a win over the 
> LISP way (again, assuming both examples are indented).  If the LISP 
> syntax is readable for you throughout, then that's okay.  For me it 
> definitely isn't -- I think most people would agree.
> 
> Someone I know at work told me today that the LISP notation is very much 
> like mathematical formulas.  I couldn't help remembering math classes in 
> college, when (at the time) I was always thinking, 'why can't they break 
> this up into simple steps like a computer program would?'  (Of course, I 
> learned a lot about programming before I took algebra, so maybe that's 
> part of the problem.)

Probably this might be helpful. I think I should give it a shot, too:

http://srfi.schemers.org/srfi-49/srfi-49.html

A big-time Scheme champion (wrote an entire Scheme system and two dozens 
of great papers) admitted to me that syntax is a big hurdle for 
acceptance and that he is looking into offering alternatives. The 
advantage is that they come from the "right" place. Unix started as a 
system for professionals with security, flexibility, etc. in place, and 
it's much harder to make Windows, which started as a consumer product, 
get to the same level.


Andrei



More information about the Digitalmars-d mailing list