Andrei Alexandrescu (See Website For Email) wrote:
> James Dennett wrote:
>> C++, of course, has std::for_each(e.begin(), e.end(), do_x);
>> in its library (though that's weaker than it could be because
>> of lack of support for convenient anonymous functions/lambdas).
>>
>> C++0x is very likely to have for(v: e).  It's implemented
>> in ConceptGCC already. Java already has essentially that,
>> as does C#.  This really doesn't set D apart (but at least
>> D isn't falling behind here).
> 
> BTW, D might soon have simultaneous iteration that will blow away all conventional languages:
> 
> foreach (i ; coll1) (j ; coll2)
> {
>   ... use i and j ...
> }
> continue foreach (i)
> {
>   ... coll2 finished; use i ...
> }
> continue foreach (j)
> {
>   ... coll1 finished; use j ...
> }
> 
> Andrei

Maybe its a bit to late here however this syntax seems very special case.  Can you explain why its necessary and how we would use it.  How would we do this currently (without meta programming)?

-Joel

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> James Dennett wrote:
>>
>>> C++, of course, has std::for_each(e.begin(), e.end(), do_x);
>>> in its library (though that's weaker than it could be because
>>> of lack of support for convenient anonymous functions/lambdas).
>>>
>>> C++0x is very likely to have for(v: e).  It's implemented
>>> in ConceptGCC already. Java already has essentially that,
>>> as does C#.  This really doesn't set D apart (but at least
>>> D isn't falling behind here).
>>
>>
>> BTW, D might soon have simultaneous iteration that will blow away all conventional languages:
>>
>> foreach (i ; coll1) (j ; coll2)
>> {
>>   ... use i and j ...
>> }
>> continue foreach (i)
>> {
>>   ... coll2 finished; use i ...
>> }
>> continue foreach (j)
>> {
>>   ... coll1 finished; use j ...
>> }
>>
>> Andrei
> 
> 
> Maybe its a bit to late here however this syntax seems very special case.  Can you explain why its necessary and how we would use it.  How would we do this currently (without meta programming)?
> 
> -Joel

You'd typically use something like an interleaved iterator. Tango has such an animal for traversing collections.

X Bunny wrote:
> Bill Baxter wrote:
...
> Also CL is not just a functional language, Like D CL is multiparadigm. With CL you can easily write procedural code with side effects like C++ or D or you can use object orientated, aspect orientated, functional, logic, pattern matching and many other programming concepts. Whats more you can add other programming concepts easily should you like.

First you suggest that there is some ignorance about what LISP can do; let me be the first to confess to having some of that.  Having said that...

It always seemed to me that LISP syntax for the 'other paradigms' and for iterative programming was designed to steer people away from them. I need to use a "let" and introduce a new scope just to define a variable.  I feel like I am using a spoon to cut carrots.  It can be made to work, but...  I know that that's mostly a syntax thing though.

>> My point is just that I don't think syntax is the *only* thing that's prevented lisp from becoming wildly popular.  If that were the case then the answer would be to simply create a different syntax for Lisp. (Actually, according to someone's comment here http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=1998 it's been done and it's called Dylan, another not-wildly popular language).  So I think the problem is more fundamental.

To me dylan looks more like ML than, say, C.  Different is not enough, but 'better' would be interesting to see.

> My personal feelings as to why Lisp isnt as popular as it could be are some of these misconceptions:
> 
> 1) Its all functional code and recursion
> 2) The syntax is weird and mindbending
> 3) Lisp is interpreted and therefore slow.
> 4) Its hard to interface Lisp with non Lisp libraries and operating system services.
> 5) Lisp is old and hasnt changed since the 50's
> 6) The features are really clever but they wouldnt be useful in a 'real' program
> 7) Its for AI or 'weird' programs
> 8) You have to be really clever to program in Lisp
> 9) Lisp is poorly documented and hard for a beginner to understand
> 10) Its irrelevant because we have Java/C++/something else now

I've looked at LISP a number of times but something always pushes me away, including some of the misconceptions here, however:

1. You can avoid this but the language, tutorials, books, libraries, other LISPers, and so on, all seem to want you to go down the recursion path.

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.

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.

Most importantly: If a chair hurts everyone that sits in it, but "only for the first year" its not a good chair.

3. I'm not sure I buy that this is a myth per se.

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.

Kevin

Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> janderson wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> janderson wrote:
>>>>>> Note: I'm not arguing that meta-programming should be higher priority then say reflection.  I'm just arguing that its just an extension to what programmers do on a day-to-day basis.
>>>>>
>>>>> But metaprogramming *gives* reflection (as even you and others discussed recently). The half-assed way to do reflection is to have the language implementer sit down and define the run-time reflection mechanism. The full-assed way is to define compile-time reflection, to then allow people to define and refine run-time reflection mechanisms as libraries, in addition to many other useful libraries! It's like in the fish vs. fishing parable.
>>>>
>>>> I agree but its like the stl vectors.  I'm unsure weather it just is easier to have that kinda thing in the language because it already has much of that information. 
>>>
>>> The information being there is all the more reason to make it available during compilation, for reflection and many other purposes, e.g. PyD being one of them.
>>>
>>>> Also to write a reflection program that doesn't require wrapping each and every call you'd need to write a fully fledged compiler which may become out of sync with the compiler.   I'm undecided on this matter.
>>>
>>> Not sure I understand. All that will be needed to make Widget available is:
>>>
>>> mixin Manifest!(Widget);
>>>
>>> I don't see where the syncing problem occurs.
>>
>> This is wrapping each class.  What if the the code was hidden in a library or something.  How would you get a such information?  Also wrapping each class is not as neat as a complete code analysis could be (which is possible in mixin, just very difficult and slow).
>>
>> Syncing problems could still occur if Walter decides to make some change in the language syntax.
> 
> I find it reasonable to require one line per exposed class. This is even easier than writing a manifest file.
> 
> 
> Andrei

Ah, but what if I want to deal with non-exposed classes, i.e. serialize a complex graph or similar data structure to disk?  I think python has 'pickling' that does this either in the language or in a fairly standard library.

For this kind of purpose, it would be useful to have some in-language and some library support; the library support can ride on top of the language support, and shouldn't require too much more.

Once you can get the useful parts of the parse tree or the equivalent data from the language, most or all of the rest can go in a library.

It would help my argument a lot if the unused bits could be left out of the program on the basis of some kind of analysis; that implies that the language support be triggered by the library instances on some level, something like C++'s automatically generated methods.  (For some reason I suspect that idea won't be popular...)

Kevin

Sean Kelly wrote:
> Walter Bright wrote:
>> 8) I've never been able to create usable C++ templates. Notice that the DMD front end (in C++) doesn't use a single template. I know how they work (in intimate detail) but I still can't use them.
> 
> I have no problem with C++ templates, but the syntax is such that I don't consider them appropriate for a lot of the uses to which they're being put.  Also, in many ways, C++ templates feel like a hack.  The need to sprinkle such code with "template" and "typename" qualifiers just so the compiler knows what it's parsing sends up a huge red flag that something is wrong.
> 
>> 9) But I see what C++ templates can do. So to me, the problem is to design templates in such a way that they are as simple to write as ordinary functions. *Then*, what templates can do can be accessible and maintainable. It's like cars - they used to be very difficult to drive, but now anyone can hop in, turn the key, and go.
> 
> Yup.  It may be that the D community is more technically adept than the C++ community on average simply because of the type of people new languages tend to attract, but I've seen a lot of interesting template code around here.

I'm certain that it's just easier in D. I'm a bit amused by the ninja reference to myself, since I've never done anything very sophisticated with C++ templates. Andrei on the other hand...

My feeling is, that 'static if' instead of specialisation removes 60% of the mystery from template metaprogramming. Tuples remove another chunk.
I think that if basic uses of recursion could be replaced with iteration and compile-time variables (even if they were mutable only inside foreach), it would become readable to average joe.

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> James Dennett wrote:
>>> C++, of course, has std::for_each(e.begin(), e.end(), do_x);
>>> in its library (though that's weaker than it could be because
>>> of lack of support for convenient anonymous functions/lambdas).
>>>
>>> C++0x is very likely to have for(v: e).  It's implemented
>>> in ConceptGCC already. Java already has essentially that,
>>> as does C#.  This really doesn't set D apart (but at least
>>> D isn't falling behind here).
>>
>> BTW, D might soon have simultaneous iteration that will blow away all conventional languages:
>>
>> foreach (i ; coll1) (j ; coll2)
>> {
>>   ... use i and j ...
>> }
>> continue foreach (i)
>> {
>>   ... coll2 finished; use i ...
>> }
>> continue foreach (j)
>> {
>>   ... coll1 finished; use j ...
>> }
>>
>> Andrei
> 
> Maybe its a bit to late here however this syntax seems very special case.  Can you explain why its necessary and how we would use it.  How would we do this currently (without meta programming)?
> 

Yeh, I don't get it either.  How would that help me implement merge() from merge sort for instance?

--bb

janderson wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> James Dennett wrote:
>>> C++, of course, has std::for_each(e.begin(), e.end(), do_x);
>>> in its library (though that's weaker than it could be because
>>> of lack of support for convenient anonymous functions/lambdas).
>>>
>>> C++0x is very likely to have for(v: e).  It's implemented
>>> in ConceptGCC already. Java already has essentially that,
>>> as does C#.  This really doesn't set D apart (but at least
>>> D isn't falling behind here).
>>
>> BTW, D might soon have simultaneous iteration that will blow away all conventional languages:
>>
>> foreach (i ; coll1) (j ; coll2)
>> {
>>   ... use i and j ...
>> }
>> continue foreach (i)
>> {
>>   ... coll2 finished; use i ...
>> }
>> continue foreach (j)
>> {
>>   ... coll1 finished; use j ...
>> }
>>
>> Andrei
> 
> Maybe its a bit to late here however this syntax seems very special case.  Can you explain why its necessary and how we would use it.  How would we do this currently (without meta programming)?
> 
> -Joel

Take the following:

int[] a = [1, 2, 3, 4];
int[] b = [5, 6, 7, 8];

In current D, you can do:

for (int i=0; i<a.length; ++i) {
    writefln("%s %s", a[i], b[i]);
}

With this syntax that Andrei mentions:

foreach (i; a) (j; b) {
    writefln("%s %s", i, j);
}

This has the additional feature of properly handling differently-sized collections automatically.

Things get immensely more complicated as soon as you start talking about opApply. My sleep-addled brain isn't coming up with a way to do it in current D, though I suspect it's possible.

Personally, I think this syntax would be awesome.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Kevin Bealer wrote:
>> My personal feelings as to why Lisp isnt as popular as it could be are some of these misconceptions:
>>
>> 1) Its all functional code and recursion
>> 2) The syntax is weird and mindbending
>> 3) Lisp is interpreted and therefore slow.
>> 4) Its hard to interface Lisp with non Lisp libraries and operating system services.
>> 5) Lisp is old and hasnt changed since the 50's
>> 6) The features are really clever but they wouldnt be useful in a 'real' program
>> 7) Its for AI or 'weird' programs
>> 8) You have to be really clever to program in Lisp
>> 9) Lisp is poorly documented and hard for a beginner to understand
>> 10) Its irrelevant because we have Java/C++/something else now
> 
> I've looked at LISP a number of times but something always pushes me away, including some of the misconceptions here, however:
> 

> 
> 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.

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)

Its also worth noting though that in Lisp the deffoo expression may or maynot define a function also (depending on whatever deffoo does). This is an important part of the language though, Im not sure how atall in D you could make a macro which defined and generated based on some code as input, a new function.

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.

> 
> 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!)

> 
> 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? :-)

> 
> 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.

> 
> 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.


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

James Dennett wrote:
> Familiarity with Lisp does help when working with C++ templates, it seems.  That might also be true for templates in D.

I can confirm that. I was never able to grok even easy metaprogramming with templates in D until I learned a little Lisp. The whole first chapter of SICP (all the examples and excersises) can be translated to metaprograms directly, and they look like lisp too. I think it is the static if / else and alias (template template) parameters which make this so easy.

X Bunny wrote:

> Bill Baxter wrote:
>>> Besides, many people naturally think recursively,
>> 
>> The statement was about why LISP is never going to be wildly popular. There may very well be "many" people who naturally think recursively, but if they're not a majority then that's a hurdle to LISP becoming popular.
>> 
>>> and many problems (e.g. parsing) can be easiest thought of that way.
>> 
>> Sure.  However, you can write recursive algorithms in most any procedural language to handle those naturally recursive tasks when they come up.   With Lisp or <my-favorite-functional-language> you're pretty much /forced/ to look at everything recursively.  And I think that makes joe coder nervous, thus presenting a major hurdle to any functional language ever becoming truly popular.
> 
> You havent qualified what you mean by Lisp, assuming that means Common
> Lisp (CL) then you are uniformed, CL offers a number of iteration
> constructs (they are implemented as macros as a great deal of the
> language is). dolist is very simple, loop is almost a language within
> itself. A common package used is called iterate which is a popular
> alternative to loop.
> Also CL is not just a functional language, Like D CL is multiparadigm.
> With CL you can easily write procedural code with side effects like C++
> or D or you can use object orientated, aspect orientated, functional,
> logic, pattern matching and many other programming concepts. Whats more
> you can add other programming concepts easily should you like.
> 
>> 
>> My point is just that I don't think syntax is the *only* thing that's prevented lisp from becoming wildly popular.  If that were the case then the answer would be to simply create a different syntax for Lisp. (Actually, according to someone's comment here http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=1998 it's been done and it's called Dylan, another not-wildly popular language).  So I think the problem is more fundamental.
>> 
> 
> People often try to modify Lisp to have a syntax more familiar to C language programmers, Dylan aside, it seems its often people who are new to Lisp who do this, after they learn more of Lisp they then can see why it is the way it is and although initially alien its design makes the language easier to use. Im not actually convinced that you can make a language with the features of CL without its syntax. There is an infix package also which allows you to use infix for things like math formulas and the like.
> 
> My personal feelings as to why Lisp isnt as popular as it could be are some of these misconceptions:
> 
> 1) Its all functional code and recursion
> 2) The syntax is weird and mindbending
> 3) Lisp is interpreted and therefore slow.
> 4) Its hard to interface Lisp with non Lisp libraries and operating
> system services.
> 5) Lisp is old and hasnt changed since the 50's
> 6) The features are really clever but they wouldnt be useful in a 'real'
> program
> 7) Its for AI or 'weird' programs
> 8) You have to be really clever to program in Lisp
> 9) Lisp is poorly documented and hard for a beginner to understand
> 10) Its irrelevant because we have Java/C++/something else now
> 
> Its interesting to contrast these with D which tends to present an image which is the opposite of many of these notions.
> 
> Regarding the syntax issue; is this suggestion: (from an earlier post)
> 
> AddExpressionTemplate!(
>     MultExpressionTemplate!(
>        SubExpressionTemplate!(Vector,Vector),
>        Vector),
>     Vector)
> 
> anymore more readable than this?
> 
> (defmacro mymacro (a b c d)
>    (+ (* (- a b) c) d))
> 
> Bunny

From my attempt to learn lisp some months ago i think that at least 4 and 9 is true (please correct me if I'm wrong). A big part of that issue is that it looks like the different implementations does things slightly differently and that creates a fragmentation of the community and causes libraries to require specific implementations (I'm mainly talking of the C interface here as that is what I looked at). Regarding 9 if you know a good lisp tutorial please post a link. (especially how to build code and the quote special syntax)