Sean Kelly wrote:
> Walter Bright wrote:
>> An oldie, but some very thought provoking observations on what makes a language productive:
>>
>> http://faculty.cs.byu.edu/~irenelg/courses/330/CTM/Resources/C++-vs-Lisp.txt 
> 
> 
> Interestingly, this same analysis was posted by Josh Stern in 2006 on D.announce.  You were even involved in the ensuing discussion quite a bit :-)

Oops!  Seems you even created a webpage for it at the time.  May be worth referencing:

http://www.digitalmars.com/d/2.0/lisp-java-d.html


Sean

On Sat, 17 May 2008 23:45:40 +0200, Nick Sabalausky <a@a.a> wrote:

> "Neal Alexander" <WQEQWEUQY@HOTMAIL.COM> wrote in message
> news:g0nha0$1s9l$1@digitalmars.com...
>> - Function composition: (process . reverse . sort) list
>> vs
>> process(reverse(sort(list)))
>>
>
> Did you mean:
>
> (sort . reverse . process) list
> vs
> process(reverse(sort(list)))
>
> Or does Haskell put them in order of (last . first)?  FWIW, I really like
> the style I've seen in some languages that's basically:
>
> list.sort().reverse().process()
> vs
> process(reverse(sort(list)))
>
> Which, I'm assuming is what you're talking about, but not certain.

In D, you can* use list.sort.reverse.process or list.sort().reverse().process(), if you like parentheses.

* "If the first parameter to a function is an array, the function can be called as if it were a property of the array" (http://www.digitalmars.com/d/2.0/arrays.html)

-- Simen

Simen Kjaeraas:
> In D, you can* use list.sort.reverse.process or list.sort().reverse().process(), if you like parentheses.

You must use parentheses there :-)

Bye,
bearophile

bearophile Wrote:

> Simen Kjaeraas:
> > In D, you can* use list.sort.reverse.process or list.sort().reverse().process(), if you like parentheses.
> 
> You must use parentheses there :-)

Not according to my programs. Well, for process, maybe. I just tested with sort and reverse, which works without parentheses.

-- Simen

Simen Kjaeraas wrote:
> bearophile Wrote:
> 
>> Simen Kjaeraas:
>>> In D, you can* use list.sort.reverse.process or  list.sort().reverse().process(), if you like parentheses.
>> You must use parentheses there :-)
> 
> Not according to my programs. Well, for process, maybe. I just tested with sort and reverse, which works without parentheses.

And if list is a built-in array, you must *not* use parentheses on sort and reverse.

--bb

On Mon, 19 May 2008 17:01:28 +0200, Bill Baxter <dnewsgroup@billbaxter.com> wrote:

> Simen Kjaeraas wrote:
>> bearophile Wrote:
>>
>>> Simen Kjaeraas:
>>>> In D, you can* use list.sort.reverse.process or  list.sort().reverse().process(), if you like parentheses.
>>> You must use parentheses there :-)
>>  Not according to my programs. Well, for process, maybe. I just tested with sort and reverse, which works without parentheses.
>
> And if list is a built-in array, you must *not* use parentheses on sort and reverse.
>
> --bb

And if the moon is in senit, and it's cloudy and tuesday?

Simen Kjaeraas wrote:
> On Mon, 19 May 2008 17:01:28 +0200, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> 
>> Simen Kjaeraas wrote:
>>> bearophile Wrote:
>>>
>>>> Simen Kjaeraas:
>>>>> In D, you can* use list.sort.reverse.process or  list.sort().reverse().process(), if you like parentheses.
>>>> You must use parentheses there :-)
>>>  Not according to my programs. Well, for process, maybe. I just tested with sort and reverse, which works without parentheses.
>>
>> And if list is a built-in array, you must *not* use parentheses on sort and reverse.
>>
>> --bb
> 
> And if the moon is in senit, and it's cloudy and tuesday?

Indeed, it's indeed a bit confusing. Sort and reverse are built-in array properties (so cannot have parentheses), while user or library-defined array functions can be called as members only with trailing parentheses.

In my onion, sort and reverse should not be built-ins, since libraries (other than the runtime) can devise better algorithms for these things.

2008/5/20 Robert Fraser <fraserofthenight@gmail.com>:
> In my onion, sort and reverse should not be built-ins, since libraries
> (other than the runtime) can

and have

> devise better algorithms for these things.

std.algorithm.sort is way better than the built-in sort, for example, at least in D2. It's way time built-in sort was dropped.

Simen Kjaeraas a écrit :
> On Mon, 19 May 2008 17:01:28 +0200, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> Simen Kjaeraas wrote:
>>> bearophile Wrote:
>>>> Simen Kjaeraas:
>>>>> In D, you can* use list.sort.reverse.process or  list.sort().reverse().process(), if you like parentheses.
>>>> You must use parentheses there :-)
>>>  Not according to my programs. Well, for process, maybe. I just tested with sort and reverse, which works without parentheses.
>>
>> And if list is a built-in array, you must *not* use parentheses on sort and reverse.
>>
>> --bb
> 
> And if the moon is in senit, and it's cloudy and tuesday?

Agreed, 'properties' are in my book (well in OOSC book actually) a way to hide the distinction between attributes and functions, to go further in hiding implementation details both normal functions and member functions should be callable without ().

Of course this means that to get the address of a function, you need a prefix operator(&), but this is a not so frequent operation..

Regards,
renoX

Robert Fraser wrote:
> Walter Bright wrote:
> 
>> An oldie, but some very thought provoking observations on what
>> makes a language productive:
>> 
>> http://faculty.cs.byu.edu/~irenelg/courses/330/CTM/Resources/C++-vs-Lisp.txt
>> 
> 
> Concise does not always mean readable, and reducing lines of code
> should *never* be a design goal.

Correct!

> For example, if I removed many temporary variables and used long
> expressions (as is the style in many functional languages), I could
> probably chop off 1/5-1/4 of the LOC of my program, but
> debugging/fixing it would get much harder. Additionally, redundancy (as stated in the ";" topic) is not necessarily a bad thing as it
> helps reinforce meaning to readers.

Too concise and non-redundant, and it becomes inintelligible.

As an example, I looked up the Idiom Library by the Finnish APL-Association, (ISBN 951-95886-0-4), Helsinki 1984, in my bookshelf. Here's a routine that removes duplicate entries from an array:

(1 1Q<\Xo.=X)/X

And this is from the easy side.

Of course, having a language where you can write a 20 page D program in 25 lines is nice and all. But debugging this stuff is way harder than debugging old Perl programs. The word Nightmare doesn't even begin to describe it. Anything you've written more than two days ago, you simply can't debug. You have to rewrite it. But what if it took ten days to write in the first place?

The other option would be to splash comments all over the place, but then the stuff becomes just as long as D, and we all know how up-to-date the comments will be in reality. (And yes, I was impressed with the language for a month, but then using it for real started to turn my stomach.)