Super-dee-duper D features

[Kevin Bealer]

X Bunny wrote:
> Kevin Bealer wrote:
>>
>> 2. The syntax doesn't provide visual hints that let you read a program.
>>
>> Web pages use different colors, road signs use different shapes, other 
>> languages use different punctuation, etc.  I can accept that they all 
>> turn into trees on some level, but it makes it unreadable to represent 
>> that in the syntax.  It's like writing all strings in hex notation. 
>> Yes, yes, I know they turn into numbers.  Show me the strings anyway; 
>> and use quotes when you do it.
> 
> I kinda follow you in the first part of this, that different punctuation 
> makes it obvious that something important is happening at that point, ie:
> 
> (defun foo (x y)
>   (+ x y))
> 
> is not syntactically different from:
> 
> (deffoo frob (x y)
>   (+ x y))
 >
 > and so you might miss the point that the first expression is probably
 > defining a function. Syntax highlighting in the editor is a simple
 > solution to that though. Really its no different than in another
 > langauge, when you see:
 >
 > Mixin!(Frob) Nuts;
 >
 > Has any of the syntax made this more obvious about what it actually
 > does? You know its a Mixin but so what, its not the punctuation which
 > matters its the actually 'stuff' the symbols.

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.

More importantly, I can understand *parts* of this code without 
understanding the whole thing.

> Lisp can be extended with extra punctuation though without having to 
> rewrite Lisp if you think it helps. This is valid syntax which looks 
> nothing like Lisp if you use the infix package:
> 
> #I(if x<y<=z then f(x)=x^^2+y^^2 else f(x)=x^^2-y^^2)

The fact that you can rewrite the language in this way is powerful, but 
I think it would be better to start at a really readable syntax.

The fact is that most people will use the 'base' syntax regardless of 
how it looks.  Otherwise, you have the problem of coordinating with the 
author of every piece of code that you use and somehow getting them to 
adopt the better syntax.  They won't, so you end up working in a kind of 
shanty-town syntax.  There is strong pressure to find one 'style' of 
programming and use that -- for LISP the default syntax is already 
established.

> Regarding the second part, its worth considering at what point do you 
> consider syntactic sugar useful and why is it part of the language? 
> certainly inputting a string as a list of hex values would be 
> impractical but running with that if you did have a Lisp which only 
> internally supported strings as a list of numbers it wouldnt matter 
> since you could make a " macro character which generated the list for 
> you. Its even argueably more useful than a system which only understands 
> strings because it is hardcoded to generate a list of bytes when it sees 
> text enclosed in quotes.

When you need to interact with large libraries of functionality to do 
things, having to know ten different syntaxes that accomplish exactly 
the same thing all in the same code base is going to be really annoying.

>> Accountants use paper with green bars on every other line, so that 
>> your eye can *follow* it.  The green bars don't do anything else, but 
>> they still help a lot with readability -- I've actually thought that 
>> other books, i.e. novels might benefit from being printed this way.  
>> Good syntax needs to consider *ergonomic* concerns, not teach an 
>> important lesson about parse trees.
> 
> I think theres even an Emacs mode which as you nest statements colours 
> the matching parantheses a different colour. As for green bars, just my 
> opinion but if you have a function with so many statements that it needs 
> green bars to delimit them then its probably too big. With Lisp or D I 
> can break the code up and probably would. (and use comments too!)

I can syntax highlight D or C++ and benefit from both kind of visual hints.

>> Most importantly: If a chair hurts everyone that sits in it, but "only 
>> for the first year" its not a good chair.
> 
> Its there a reason to sit on the chair that makes the initial discomfort 
> seem worthwhile? Is there a more comfortable alternative chair which 
> does everything the chair does? Is it painful because you have bad 
> posture from sitting too long on a beanbag? :-)

This seems to be a very common view in the LISP community, 'programming 
in other languages has made you soft'.  I don't believe in the power of 
'hazing' to make better programmers.

My point in this paragraph (I admit it wasn't clearly made), is this:

If you ask 100 people about LISP syntax, at least 90 of them will say 
they don't like it and find it hard to use.  The benefits you mention 
are real, but I don't buy that they come from the syntax itself.


>> 3. I'm not sure I buy that this is a myth per se.
> 
> If you mean its true and therefore not a myth then you are wrong.
> Almost all Common Lisp systems are compilers, most generate native code, 
> some dont include an interpreter at all and compile interactively if you 
> are programming interactively. Another misconception is that Lisp doesnt 
> support typed variables and therefore is unable to generate fast but 
> specific code like C or something else, again simply not true.

I didn't mean the part about being interpreted.  LISP code *tends* to be
slower than C++, sometimes a little, sometimes a lot.  For many types of 
code this is not too important, etc, but for some, it is crucial.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=sbcl

>> The rest I'll grant as probably misconceptions, especially 6.
>>
>> I think the real clincher is that when people describe these kinds of 
>> issues the LISP community's response seems to be something like "get 
>> used to it and you won't notice it".  Other languages may catch up 
>> with some of LISP's features, but what I consider to be the problems 
>> with LISP can't be fixed because they aren't seen as problems.
> 
> I reckon there probably is a future possibility for a language which 
> encompasses Lisps features but which is not Lisp. To be honest I dont 
> really see it, since Lisp can already be extended to support additional 
> syntax, those people who need to can implement it anyways and it would 
> still be Lisp. Its worth noting that s-expressions (the Lisp syntax 
> everyone but Lisp programmers has a problem with) wasnt the end-all of 
> Lisp syntax there were also m-expressions which were supposed to be more 
> human readable and an original goal of the development, programmers 
> genuinely prefered sexp.

Interesting, I didn't know about m-expressions.

> I think a nifty thing would be a D parser written in Lisp, the D parser 
> would emit Lisp forms which would then be compiled like anyother Lisp 
> code, additionally it could then interact with the rest of Lisp and if 
> people felt the desire to write more off the wall stuff they could, D 
> would remain what it is, extensions could be as D like as they wished. 
> Probably the parser could be simpler than the complete D spec since 
> probably the template stuff would be replaced by macros. Who knows?
> 
> Bunny

You can already go the other direction -- there is a LISP environment 
written in D on dsource.

http://www.dsource.org/projects/dlisp

Kevin