Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> kris wrote:
>>
>>>>> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.
>>>>
>>>> Yet, Lisp will always remain a niche language. You have to wonder why.
>>>
>>> I'm pretty sure it's the syntax.
>>
>> And the recursion.
>> People just don't naturally think recursively.
>>
>> And the lack of mutable data structures.
>> OCaml tried to fix that, but OCaml's probably always going to be niche as well (see first point).
> 
> LISP does have mutation. Besides, many people naturally think recursively, and many problems (e.g. parsing) can be easiest thought of that way.
> 
> Andrei

One nit: I agree with Walter here.  People do *not* "naturally think recursively".  Computer Scientists, most definitely. Developers, likely.  People who make Russian dolls for a living, perhaps.  Normal people, not a chance.  I'd argue that most folks can't even spell the word, much less know what it means.

Proof?  Well, how many people go about defining things in terms of the very things they're trying to define?

-- 
- EricAnderton at yahoo

Sean Kelly wrote:
> kris wrote:
>>
>> Of course, the trick would be to find a reasonable tripping point where the abuse-potential starts to require some serious respect; like the vehicle noted above. However, it could be done; perhaps with a 'level'? I understand you're not crazy about switches and so on, but please consider it ... it could potentially be responsible for alleviating adoption fears. That's a pretty darned powerful switch.
> 
> I think this is a very good idea, and if some reasonable means of implementing it could be found then it might actually aid D's adopting in conservative circles without prohibiting powerful meta features from being added.
> 
> What fuels my concern is that because the new mixin/import features are so general, it is as easy to envision horrors rivaling the worst of C macro code as it is to envision elegant and practical applications.  

It's funny you mention that.  Ever since the start, I've been trying to figure out how one could have an "obfuscated code contest" using D.  Until recently, it was only in the far corners of my imagination since you could only abuse operator overloads and identifier names.  For better or for worse, this just became a very real possibility - mixin("foo") evaluates recursively, right?

> I suppose this is why I've been kind of hoping an alternate solution would present itself :-)  I think the general idea is fantastic, but these are the first features in D that I might actually be inclined to prohibit in certain development environments.  The potential for abuse undermines a lot of what appeals to be about D: elegance, clarity, etc.  At the same time, I'm excited about the direction in which things are progressing.

I agree with Sean and Kris on this - a goalie of some kind might be a nice attractor for project management.  However, I wonder if this is truly something that fits the role of the D compiler itself.  Isn't this more of a coding-policy-enforcement tool, akin to something that manages coding style, whitespace, etc?


-- 
- EricAnderton at yahoo

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

Pragma wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>> kris wrote:
>>>
>>>>>> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.
>>>>>
>>>>> Yet, Lisp will always remain a niche language. You have to wonder why.
>>>>
>>>> I'm pretty sure it's the syntax.
>>>
>>> And the recursion.
>>> People just don't naturally think recursively.
>>>
>>> And the lack of mutable data structures.
>>> OCaml tried to fix that, but OCaml's probably always going to be niche as well (see first point).
>>
>> LISP does have mutation. Besides, many people naturally think recursively, and many problems (e.g. parsing) can be easiest thought of that way.
>>
>> Andrei
> 
> One nit: I agree with Walter here.  People do *not* "naturally think recursively".  Computer Scientists, most definitely. Developers, likely.  People who make Russian dolls for a living, perhaps.  Normal people, not a chance.  I'd argue that most folks can't even spell the word, much less know what it means.
> 
> Proof?  Well, how many people go about defining things in terms of the very things they're trying to define?

Hard to define a tree otherwise :o).

But I do agree with your point.

Andrei

Pragma wrote:
> One nit: I agree with Walter here.  People do *not* "naturally think
> recursively".  Computer Scientists, most
> definitely. Developers, likely.  People who make Russian dolls for a
> living, perhaps.  Normal people, not a chance.  I'd argue that most folks
> can't even spell the word, much less know what it means.
> 
> Proof?  Well, how many people go about defining things in terms of the very things they're trying to define?
>

I'm not sure this is true. Many simple tasks are described as 'do X to Y until Z,' which can be expressed easily as a recursive procedure. I doubt non-programmers would think of a task as iterating over a collection of objects with mutable state either. :)

Sometimes I get the feeling that recursion is made out to be more difficult than it is, for programming I mean. As an average Joe I do like to learn more, but when you look up material on the use of recursion, the vast bulk of it pretty much assumes you at least have a pretty good programming knowledge and often require mathematics too. </rant>

Recursion just has a nerdy aura around it. It probably doesn't help that most programmers are learned to think iteratively too.

Walter Bright wrote:
> kris wrote:
>> Walter Bright wrote:
>>> 3) Less code == more productivity, less bugs. I don't mean gratuitously less code, I mean less code in the sense that one can write directly what one means, rather than a lot of tedious bother. For example, if I want to visit each element in an array:
>>>
>>>     foreach(v; e)
>>>     {...}
>>>
>>> is more direct than:
>>>
>>>     for (size_t i = 0; i < sizeof(e)/sizeof(e[0]); i++)
>>>     { T v = e[i];
>>>      ... }
>>>
>>
>> Yep, that's great! One of the reasons I like D so much, along with array slicing.
> 
> The C++ version is even *worse* than the C one (for wordiness bother):
> 
>     for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>     {  T v = *i;
>     ... }

C++ can, of course, also do (with type-safety)
  for (size_t i = 0; i < size(e); ++i)

> I mean I know the reasons for every bit of the syntax there, and in isolation they make sense, but put it all together and it seems to go backwards.

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

>>> 5) Lisp gets things right, according to what I've read from heavy Lisp users, by being a language that can be modified on the fly to suit the task at hand, in other words, by having a customizable language one can achieve dramatic productivity gains.
>>
>> Yet, Lisp will always remain a niche language. You have to wonder why.
> 
> I'm pretty sure it's the syntax.

Yup, syntax does matter.

[snip]

>>> 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.
>>
>> Same here.
> 
> But I have been able to create usable D templates <g>.

The problems are mostly syntactical; writing C++ templates isn't much harder, by and large, than writing other robust, reusable, flexible code.  (Which is hard, by most measures.)

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

[snip]

> It's like Paul Mensonidas being recognized as the "World's Leading Expert on the C Preprocessor." Obviously, something is seriously wrong with the preprocessor if there's an ecological niche for a world's leading expert on it. (By the way, Paul is a very nice fellow and has been kind enough to help me iron out several subtle bugs in the DMC++ preprocessor. As long as we're saddled with that preprocessor spec, I'm glad there is a Paul to help!)

I'll second that, though it's offtopic.  My knowledge of
the dark corners of the C++ preprocessor was heavily
influenced by Paul's writing.  (Most of what I learned
just reconfirmed the view that this tool is a beast.)

-- James

[With apologies for following on from my own post:]

James Dennett wrote:
> Walter Bright wrote:
>> kris wrote:
>>> Walter Bright wrote:
>>>> 3) Less code == more productivity, less bugs. I don't mean gratuitously less code, I mean less code in the sense that one can write directly what one means, rather than a lot of tedious bother. For example, if I want to visit each element in an array:
>>>>
>>>>     foreach(v; e)
>>>>     {...}
>>>>
>>>> is more direct than:
>>>>
>>>>     for (size_t i = 0; i < sizeof(e)/sizeof(e[0]); i++)
>>>>     { T v = e[i];
>>>>      ... }
>>>>
>>> Yep, that's great! One of the reasons I like D so much, along with array slicing.
>> The C++ version is even *worse* than the C one (for wordiness bother):
>>
>>     for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>>     {  T v = *i;
>>     ... }
> 
> C++ can, of course, also do (with type-safety)
>   for (size_t i = 0; i < size(e); ++i)
> 
>> I mean I know the reasons for every bit of the syntax there, and in isolation they make sense, but put it all together and it seems to go backwards.
> 
> 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).

For completeness (and maybe incidentally illustrating how
easy it is to miss something relevant) I should mention
that the current working paper for C++ also supports type
deduction to allow
  for (auto i = e.begin(); i != e.end(); ++i)
which is a big step forward (though in this simple case,
the range form of "for" will still be the better/normal
choice.)  Giving "auto" some use in this way will remove
a lot of verbose repetition from C++ code -- but it's
good that D benefits from some of the points learned
during the evolution of C++.

(I hope it can learn from the excessive implicit conversions in C++ too, and eliminate implicit conversions from character and boolean types to integers.)

-- James

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

Best languages out there are at best ho-hum when it comes about iterating through simultaneous streams. Most lose their elegant iteration statement entirely and come with something that looks like an old hooker early in the morning.


Andrei

A what??

That's a rather odd and disturbing analogy... :p

-JJR

James Dennett wrote:
> [With apologies for following on from my own post:]
> 
> 
> For completeness (and maybe incidentally illustrating how
> easy it is to miss something relevant) I should mention
> that the current working paper for C++ also supports type
> deduction to allow
>   for (auto i = e.begin(); i != e.end(); ++i)
> which is a big step forward (though in this simple case,
> the range form of "for" will still be the better/normal
> choice.)  Giving "auto" some use in this way will remove
> a lot of verbose repetition from C++ code -- but it's
> good that D benefits from some of the points learned
> during the evolution of C++.

This shows how D is a head of the game when compared to C++.  By the time CC+ get this, D will be on the next level.  C++ will always be playing catchup with D's syntax.

> 
> (I hope it can learn from the excessive implicit conversions
> in C++ too, and eliminate implicit conversions from character
> and boolean types to integers.)
> 
> -- James