www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Many Faces of D - slides

reply Walter Bright <newshound2 digitalmars.com> writes:
The slides for my Sep. 15 talk at NWCPP:

http://nwcpp.org/images/stories/nwcpp-2010-09.pdf
Oct 03 2010
next sibling parent reply Emil Madsen <sovende gmail.com> writes:
Interesting, would have loved to be there :)

On 3 October 2010 12:28, Walter Bright <newshound2 digitalmars.com> wrote:


 The slides for my Sep. 15 talk at NWCPP:

 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf




-- 
// Yours sincerely
// Emil 'Skeen' Madsen
Oct 03 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Emil Madsen wrote:

 Interesting, would have loved to be there :)


It was actually one of the most fun ones I've done. The audience was very
engaging.
Oct 03 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote:


 The slides for my Sep. 15 talk at NWCPP:
 
 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


On a side note, I noticed that Walter is still using OpenOffice 2.4 from 
March 2008. 9 new releases have been announced after that :-) I doubt it 
has any effect on these slides, but the latest versions might offer 
better user experience.
Oct 03 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 03 October 2010 04:01:10 retard wrote:

 Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote:

 The slides for my Sep. 15 talk at NWCPP:
 
 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


 
 On a side note, I noticed that Walter is still using OpenOffice 2.4 from
 March 2008. 9 new releases have been announced after that :-) I doubt it
 has any effect on these slides, but the latest versions might offer
 better user experience.


I just use latex for everything. That way I can use vim. It's much more
pleasant 
that way.

- Jonathan M Davis
Oct 03 2010
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote:
[ . . . ]

 I just use latex for everything. That way I can use vim. It's much more p=


leasant=20

 that way.


Also you can put the material into version control since the source is
mergeable -- unlike OOo files.

Sadly though LaTeX, even with the beamer package, just isn't up to doing
what is easy with OOo.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/03/2010 06:57 AM, Russel Winder wrote:

 On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote:
 [ . . . ]

 I just use latex for everything. That way I can use vim. It's much more
pleasant
 that way.


 Also you can put the material into version control since the source is
 mergeable -- unlike OOo files.

 Sadly though LaTeX, even with the beamer package, just isn't up to doing
 what is easy with OOo.


I agree, though I'd also add that the likes of PowerPoint don't make it 
easy to create good presetations. In PowerPoint et al you are forced to 
focus on a flat structure that gets you boggled in details. For example 
it's trivial in PowerPoint to move slides around, which should be rare 
and odd in a well-conceived presentation. However imparting hierarchy to 
a presentation is not a feature.

Though a text-based presentation engine does not help with structure 
either, at least it doesn't stay in the way.


Andrei
Oct 03 2010
parent reply retard <re tard.com.invalid> writes:
Sun, 03 Oct 2010 11:00:43 -0500, Andrei Alexandrescu wrote:


 On 10/03/2010 06:57 AM, Russel Winder wrote:

 On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote: [ . . . ]

 I just use latex for everything. That way I can use vim. It's much
 more pleasant that way.


 Also you can put the material into version control since the source is
 mergeable -- unlike OOo files.

 Sadly though LaTeX, even with the beamer package, just isn't up to
 doing what is easy with OOo.


 
 I agree, though I'd also add that the likes of PowerPoint don't make it
 easy to create good presetations. In PowerPoint et al you are forced to
 focus on a flat structure that gets you boggled in details. For example
 it's trivial in PowerPoint to move slides around, which should be rare
 and odd in a well-conceived presentation. However imparting hierarchy to
 a presentation is not a feature.
 
 Though a text-based presentation engine does not help with structure
 either, at least it doesn't stay in the way.


LyX (lyx.org) provides an alternative with WYSIWYM GUI and TeX export 
(LyX is very close to LaTeX). The only problem is, embedded TeX code 
blocks sometimes do not work and sometimes LyX stumbles into parsing bugs 
or fails to produce valid LaTeX for the backend. If I have to choose 
between the real PowerPoint and OpenOffice Impress, PowerPoint beats 
OpenOffice hands down.
Oct 03 2010
parent Lutger <lutger.blijdestijn gmail.com> writes:
retard wrote:


 Sun, 03 Oct 2010 11:00:43 -0500, Andrei Alexandrescu wrote:
 

 On 10/03/2010 06:57 AM, Russel Winder wrote:

 On Sun, 2010-10-03 at 04:40 -0700, Jonathan M Davis wrote: [ . . . ]

 I just use latex for everything. That way I can use vim. It's much
 more pleasant that way.


 Also you can put the material into version control since the source is
 mergeable -- unlike OOo files.

 Sadly though LaTeX, even with the beamer package, just isn't up to
 doing what is easy with OOo.


 
 I agree, though I'd also add that the likes of PowerPoint don't make it
 easy to create good presetations. In PowerPoint et al you are forced to
 focus on a flat structure that gets you boggled in details. For example
 it's trivial in PowerPoint to move slides around, which should be rare
 and odd in a well-conceived presentation. However imparting hierarchy to
 a presentation is not a feature.
 
 Though a text-based presentation engine does not help with structure
 either, at least it doesn't stay in the way.


 
 LyX (lyx.org) provides an alternative with WYSIWYM GUI and TeX export
 (LyX is very close to LaTeX). The only problem is, embedded TeX code
 blocks sometimes do not work and sometimes LyX stumbles into parsing bugs
 or fails to produce valid LaTeX for the backend. If I have to choose
 between the real PowerPoint and OpenOffice Impress, PowerPoint beats
 OpenOffice hands down.


I have good experience with making a presentation with Lyx, even starting with 
almost zero knowledge of Latex. Some things with beamer you get for free are 
more cumbersome to do with PP / Impress.
Oct 03 2010
prev sibling next sibling parent reply Justin Johansson <no spam.com> writes:
On 3/10/2010 10:01 PM, retard wrote:

 Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote:


 The slides for my Sep. 15 talk at NWCPP:

 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


 On a side note, I noticed that Walter is still using OpenOffice 2.4 from
 March 2008. 9 new releases have been announced after that :-) I doubt it
 has any effect on these slides, but the latest versions might offer
 better user experience.


Ahh, while that is a polite observation, it is not (to me at least) very
interesting.  What would be more interesting is some indication of
interest to take up D as a PL from this (C++) audience***.

*** http://www.nwcpp.org/

May I ask Walter if, as coming away from the meeting, you felt
that there might be converts (to D) amongst this group?

Cheers
Justin Johansson
Oct 03 2010
next sibling parent Dave Mustaine <a a.a> writes:
Justin Johansson Wrote:


 On 3/10/2010 10:01 PM, retard wrote:

 Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote:


 The slides for my Sep. 15 talk at NWCPP:

 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


 On a side note, I noticed that Walter is still using OpenOffice 2.4 from
 March 2008. 9 new releases have been announced after that :-) I doubt it
 has any effect on these slides, but the latest versions might offer
 better user experience.


 
 Ahh, while that is a polite observation, it is not (to me at least) very
 interesting.  What would be more interesting is some indication of
 interest to take up D as a PL from this (C++) audience***.
 
 *** http://www.nwcpp.org/
 
 May I ask Walter if, as coming away from the meeting, you felt
 that there might be converts (to D) amongst this group?


I bet all democrats and friends of heavier music like me enjoyed it :)
Oct 03 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Justin Johansson wrote:

 May I ask Walter if, as coming away from the meeting, you felt
 that there might be converts (to D) amongst this group?


I can say it was a very friendly and engaging audience, and they asked good 
questions.
Oct 03 2010
parent reply Justin Johansson <no spam.com> writes:
On 4/10/2010 6:35 AM, Walter Bright wrote:

 Justin Johansson wrote:

 May I ask Walter if, as coming away from the meeting, you felt
 that there might be converts (to D) amongst this group?


 I can say it was a very friendly and engaging audience, and they asked
 good questions.


Congrats.  Sounds like speaker and audience alike enjoyed the talk.
Oct 04 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Justin Johansson wrote:

 On 4/10/2010 6:35 AM, Walter Bright wrote:

 Justin Johansson wrote:

 May I ask Walter if, as coming away from the meeting, you felt
 that there might be converts (to D) amongst this group?


 I can say it was a very friendly and engaging audience, and they asked
 good questions.


 
 Congrats.  Sounds like speaker and audience alike enjoyed the talk.


Intriguingly, the audience showed a lot of interest in D's scripting 
capabilities (thanks, Andrei!).
Oct 04 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 On a side note, I noticed that Walter is still using OpenOffice 2.4 from 
 March 2008. 9 new releases have been announced after that :-) I doubt it 
 has any effect on these slides, but the latest versions might offer 
 better user experience.


The last time I upgraded Ubuntu it destroyed all the installed software, all my 
vmware subsystems, etc. I had to wipe the hard disk, reformat, and start over. 
Since then, I've been reluctant to upgrade.
Oct 03 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i89npm$tst$2 digitalmars.com...

 Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote:


 The slides for my Sep. 15 talk at NWCPP:

 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


 On a side note, I noticed that Walter is still using OpenOffice 2.4 from
 March 2008. 9 new releases have been announced after that :-) I doubt it
 has any effect on these slides, but the latest versions might offer
 better user experience.


Heh, I'm still using OpenOffice 1.1 just because it doesn't have those 
terribly ugly menubar/toolbar gradients (an old screenshot I used to 
demonstrate it to the boneheaded OOO developers who tried to tell me that it 
was just my system and not OpenOffice: 
http://www.semitwist.com/download/OpenOfficeVisualCompare.jpg They ended up 
ignoring it.) I know that's a really trivial reason, but I haven't had any 
problems with 1.1, so I've had no real reason to upgrade either.
Oct 03 2010
next sibling parent retard <re tard.com.invalid> writes:
Sun, 03 Oct 2010 16:46:19 -0400, Nick Sabalausky wrote:


 "retard" <re tard.com.invalid> wrote in message
 news:i89npm$tst$2 digitalmars.com...

 Sun, 03 Oct 2010 03:28:09 -0700, Walter Bright wrote:


 The slides for my Sep. 15 talk at NWCPP:

 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


 On a side note, I noticed that Walter is still using OpenOffice 2.4
 from March 2008. 9 new releases have been announced after that :-) I
 doubt it has any effect on these slides, but the latest versions might
 offer better user experience.


 
 Heh, I'm still using OpenOffice 1.1 just because it doesn't have those
 terribly ugly menubar/toolbar gradients (an old screenshot I used to
 demonstrate it to the boneheaded OOO developers who tried to tell me
 that it was just my system and not OpenOffice:
 http://www.semitwist.com/download/OpenOfficeVisualCompare.jpg They ended
 up ignoring it.) I know that's a really trivial reason, but I haven't
 had any problems with 1.1, so I've had no real reason to upgrade either.


This is what OpenOffice 3.2.1 looks like [on Linux] (sorry for having a 
bit larger resolution):

http://www.freeimagehosting.net/image.php?72b470923c.png

Last time I heard, the next OpenOffice/LibreOffice might switch to the 
ribbon style, though.

The more recent versions have lots of new features. For example 
compatibility with the unholy office xml formats is much better.
Oct 03 2010
prev sibling parent Puneet Goel <puneet.goel.d gmail.com> writes:
 Heh, I'm still using OpenOffice 1.1 just because it doesn't have those
 terribly ugly menubar/toolbar gradients (an old screenshot I used to
 demonstrate it to the boneheaded OOO developers who tried to tell me that it
 was just my system and not OpenOffice:
 http://www.semitwist.com/download/OpenOfficeVisualCompare.jpg They ended up
 ignoring it.) I know that's a really trivial reason, but I haven't had any
 problems with 1.1, so I've had no real reason to upgrade either.


Nick

OpenOffice (at least version 3.2 that I have on my Ubuntu box), picks
up the menu and toolbar styling from your Desktop theme. And I am
using the Gnome Desktop.

Well, I am also trying to tell you that it might be just your system :-)

Regards
- Puneet
Oct 03 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 The slides for my Sep. 15 talk at NWCPP:
 http://nwcpp.org/images/stories/nwcpp-2010-09.pdf


Thank you for the slides.

Few comments:

Page 10, and in other pages I'd like a non-proportional font for the code,
because I find it a little more readable (even better if it's colorized, there
are online tools able to produce colorized HTML from D1 code too).


Page 19:

Unlike C++, values can be moved in memory  Postblit is used to “adjust” things
after a move<


OK, so a moving GC needs to call the Postblit each time it moves a struct.


Page 20: is that functional? It even contains a mutable "sum" value. It may be
seen as kind-of-functional. A more functional style is to use a reduce (fold)
there, from std.algorithm.


Page 30: that little concurrent test program gives me an error:
...\dmd\src\phobos\std\typecons.d(336): Error: no property 'length' for type
'immutable(char)'

This is the part of typecons.d that gives the error:

    static string injectNamedFields()
    {
        string decl = "";
        foreach (i, name; staticMap!(extractName, fieldSpecs))
        {
            auto    field = text("Identity!(field[", i, "])");
            auto numbered = text("_", i);
            decl ~= text("alias ", field, " ", numbered, ";");
            if (name.length != 0) // line 336
            {
                decl ~= text("alias ", numbered, " ", name, ";");
            }
        }
        return decl;
    }

Bye,
bearophile
Oct 03 2010
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sun, 2010-10-03 at 09:59 -0400, bearophile wrote:
[ . . . ]


 Page 10, and in other pages I'd like a non-proportional font for the
 code, because I find it a little more readable (even better if it's
 colorized, there are online tools able to produce colorized HTML from
 D1 code too).


I continue to be intrigued by people who believe that code, unlike text,
is more readable in a monospace font.  Personally I think monospace
fonts make code unreadable, I always prefer proportional fonts for code.
Currently I use Ocean Sans MT.

Colourized though, I agree, makes things more readable -- as long as the
colourization theme matches the semantics of the code fragment,
obviously.

[ . . . ]


 Page 20: is that functional? It even contains a mutable "sum" value.
 It may be seen as kind-of-functional. A more functional style is to
 use a reduce (fold) there, from std.algorithm.


I agree this is a weird sort of an example of "functional".
sum_of_squares as a function has no external side-effects (though
clearly the iteration has a side effect internally) and is referentially
transparent.  So as a thing that can be used as a "functional
programming" function it is fine, its implementation is though very much
imperative programming -- at its worst ;-)

Given an imperative language with no tail recursion capability then one
has to declare a non-functional floor even when doing functional style
programming.  In effect the execution graph has to be allowed to have
leaqf nodes that are implemented imperatively.

Coming from a Pythonic realization of these ideas, list comprehensions
seems to be the best way out of this sort of thing, so instead of:

        def sumOfSquares ( sequence ) :
            sum =3D 0.0
            for item in sequence :
                sum +=3D  item * item
            return sum

it is better to write:

        def sumOfSquares ( sequence ) :
            return sum ( [ item * item for item in sequence ] )
       =20
So the question is whether there is an idiomatic D version of this.

[ . . . ]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Russel Winder:


I continue to be intrigued by people who believe that code, unlike text, is
more readable in a monospace font.  Personally I think monospace fonts make
code unreadable,<


I guess it's a matter of personal preferences. But non-proportional fonts have
two advantages: 
- it's easy to count spaces, vertical alignments and so on;
- often if the non-proportional is well designed it's simpler to tell apart
glyphs like Jl1j0oO;:.



 Given an imperative language with no tail recursion capability


Both DMD and LDC (and probably GDC too) currently are able to turn some cases
of tail recursion to iterative code.



         def sumOfSquares ( sequence ) :
             return sum ( [ item * item for item in sequence ] )


Since many years and many versions of Python the pythonic way to write that is
to use a lazy iterable:

    def sumOfSquares (sequence):
        return sum(item * item for item in sequence)


I have suggested few times a list/lazy comp syntax for D too, and I have tried
to explain why it's a good thing (it helps "chunking" in the mind of the
programmer).

Bye,
bearophile
Oct 03 2010
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 Since many years and many versions of Python the pythonic way to write that is
to use a lazy iterable:
     def sumOfSquares (sequence):
         return sum(item * item for item in sequence)
 I have suggested few times a list/lazy comp syntax for D too, and I have tried
to explain why it's a


good thing (it helps "chunking" in the mind of the programmer).

Out of curiosity, what syntax did you propose? I definitely agree that lazy
range comprehensions would
be a Good Thing (tm).

That said, the current D way of writing it isn't all that different from Python:

return reduce!("a+b")(map!("a*a")(sequence), 0);
Oct 03 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:


 Out of curiosity, what syntax did you propose?


http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=73868



 That said, the current D way of writing it isn't all that different from
Python:
 
 return reduce!("a+b")(map!("a*a")(sequence), 0);


That's many times worse than the Python syntax. Array/range comprehensions are
syntax sugar, their point is to give something clean and readable that helps
chunking:
http://en.wikipedia.org/wiki/Chunking_%28psychology%29

Bye,
bearophile
Oct 03 2010
next sibling parent reply SiegeLord <none none.com> writes:
bearophile Wrote:


 That's many times worse than the Python syntax. Array/range comprehensions are
syntax sugar, their point is to give something clean and readable that helps
chunking:
 http://en.wikipedia.org/wiki/Chunking_%28psychology%29
 
 Bye,
 bearophile


YMMW. Back when I was programming Python I found the array comprehension syntax
unreadable, so I always used the map equivalent. It's helpful to realize that
the definitions of "clean" and "readable" differ from person to person, and may
in fact be the exact opposite between two people.

-SiegeLord
Oct 03 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
SiegeLord:


 Back when I was programming Python I found the array comprehension syntax
unreadable, so I always used the map equivalent.


Python devs have introduced list comps only after asking about their
"ergonomicity" level to many people. And for most of those people code like
this:

result1 = [x * x + 5 for x in xrange(10)]
result2 = {x: x * x for x in xrange(20)}

Allows the programmer to see code purpose better and create higher-level mental
chunks than code like:

result1 = map(lambda x: x * x + 5, xrange(10))
result2 = {}
for x in xrange(20):
    result2[x] = x * x

Bye,
bearophile
Oct 03 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
bearophile wrote:

 SiegeLord:
=20

 Back when I was programming Python I found the array comprehension syn=




tax unreadable, so I always used the map equivalent.

=20
 Python devs have introduced list comps only after asking about their "e=


rgonomicity" level to many people. And for most of those people code like=
 this:

=20
 result1 =3D [x * x + 5 for x in xrange(10)]
 result2 =3D {x: x * x for x in xrange(20)}
=20
 Allows the programmer to see code purpose better and create higher-leve=


l mental chunks than code like:

=20
 result1 =3D map(lambda x: x * x + 5, xrange(10))
 result2 =3D {}
 for x in xrange(20):
     result2[x] =3D x * x
=20


	Why didn't you write the second like this to keep it functional:
result2 =3D dict (map (lambda x: (x, x*x), xrange (20)))

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 03 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jérôme M. Berger:


 	Why didn't you write the second like this to keep it functional:
 result2 = dict (map (lambda x: (x, x*x), xrange (20)))


Because I've never seen people write it that way, and because for me it's less
readable than the normal imperative code.

Bye,
bearophile
Oct 03 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
bearophile wrote:

 J=C3=A9r=C3=B4me M. Berger:
=20

 	Why didn't you write the second like this to keep it functional:
 result2 =3D dict (map (lambda x: (x, x*x), xrange (20)))


=20
 Because I've never seen people write it that way, and because for me it=


's less readable than the normal imperative code.

=20


	Oh, I agree that it's less readable, but wasn't that your point?
After all, the functional list generation with "map" is also less
readable than the corresponding imperative code.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 03 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/03/2010 10:37 AM, bearophile wrote:

 Peter Alexander:


 Out of curiosity, what syntax did you propose?


 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=73868




 That said, the current D way of writing it isn't all that different
 from Python:

 return reduce!("a+b")(map!("a*a")(sequence), 0);


 That's many times worse than the Python syntax.


This entails there's a way to measure that. How?


 Array/range comprehensions are syntax sugar, their point is to give
 something clean and readable that helps chunking:
 http://en.wikipedia.org/wiki/Chunking_%28psychology%29


You'd need to bring a pointer to a document that confirms that (and how) 
array and range comprehensions have helping chunking as their point. I 
googled for

array comprehensions help chunking

to no avail.


Andrei
Oct 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 return reduce!("a+b")(map!("a*a")(sequence), 0);


 That's many times worse than the Python syntax.


 
 This entails there's a way to measure that. How?


Probably the only way good for you is to take a group of programmers and
perform some experiments of experimental psychology, similar to the experiments
of ergonomics done to find if the design of a car gear shift stick is good
enough for most users.



 You'd need to bring a pointer to a document that confirms that (and how) 
 array and range comprehensions have helping chunking as their point.


It's a theory of mine :-) This too needs psychology experiments, but I need a
backup life to find the time to perform them.

In my code I have seen that I need several tries to catch a correct way to
write those reduce!(...)..., while I don't have the same problems in Python.

In Python3 they have even removed the built-in reduce (and moved it into the
standard library) because practical experience has shown that many newbies and
Python programmers find the semantics of reduce() not so easy to understand
(like when they read code written by other people). S the usage of reduce() is
a bit discouraged in normal Python code. This is also why I have suggested
(http://d.puremagic.com/issues/show_bug.cgi?id=4725 ) to add a sum() to Phobos2.

Bye,
bearophile
Oct 03 2010
next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 It's a theory of mine :-) This too needs psychology experiments, but I need a
backup life to find the


time to perform them.

 In my code I have seen that I need several tries to catch a correct way to
write those reduce!(...)...,


while I don't have the same problems in Python.

That's interesting, because I have no trouble at all using reduce/map/filter
etc.

I think the difference is between top-down thinkers and bottom-up thinkers, but
this is just a theory of
my own as well :-)
Oct 03 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/03/2010 01:24 PM, bearophile wrote:

 Andrei Alexandrescu:


 return reduce!("a+b")(map!("a*a")(sequence), 0);


 That's many times worse than the Python syntax.


 This entails there's a way to measure that. How?


 Probably the only way good for you is to take a group of programmers
 and perform some experiments of experimental psychology, similar to
 the experiments of ergonomics done to find if the design of a car
 gear shift stick is good enough for most users.


That's not the way for "me", it would be a simple application of the
scientific method that could impart credibility to the argument. And 
it's more similar to the experiments done routinely in software 
engineering research than in automotive industry.


 You'd need to bring a pointer to a document that confirms that (and
 how) array and range comprehensions have helping chunking as their
 point.


 It's a theory of mine :-)


Not labeling it as such hurts the quality of the conversation.


 This too needs psychology experiments, but I need a backup life to
 find the time to perform them.


Again, it's a common method in software engineering research. The point 
is one shouldn't make claims without being able to substantiate them.


 In my code I have seen that I need several tries to catch a correct
 way to write those reduce!(...)..., while I don't have the same
 problems in Python.


Alright, there's one user experience. A few more and we can collect some 
statistics :o).


 In Python3 they have even removed the built-in reduce (and moved it
 into the standard library) because practical experience has shown
 that many newbies and Python programmers find the semantics of
 reduce() not so easy to understand (like when they read code written
 by other people).


A link to a document that illustrates that motivation would be great. 
For all I know Python 3 also transformed print from a statement into a 
function, but for very different reasons.


 S the usage of reduce() is a bit discouraged in
 normal Python code. This is also why I have suggested
 (http://d.puremagic.com/issues/show_bug.cgi?id=4725 ) to add a sum()
 to Phobos2.


Yeah, sum() is probably popular enough to deserve a special case. 
Anyway, I just changed filter:

http://www.dsource.org/projects/phobos/changeset/2081

in ways that it should allow:

assert(equal(compose!(map!"2 * a", filter!"a & 1")([1,2,3,4,5]),
                     [2,6,10]));
assert(equal(pipe!(filter!"a & 1", map!"2 * a")([1,2,3,4,5]),
             [2,6,10]));

both of which group operations in separation from their inputs.


Andrei
Oct 03 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 Not labeling it as such hurts the quality of the conversation.



 one shouldn't make claims without being able to substantiate them.


You are right, sorry.



 A link to a document that illustrates that motivation would be great.
 For all I know Python 3 also transformed print from a statement into a
 function, but for very different reasons.


One of the first times I've seen a rationale behind the removal of reduce() was
here, page 4, a text by Guido van Rossum, the Python main designer:
http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf



* reduce()
–nobody uses it, few understand it
–a for loop is clearer & (usually) faster
<


Later this was the answer, by Guido still:
http://www.artima.com/forums/flat.jsp?forum=106&thread=211200



Q.  If you're killing reduce(), why are you keeping map() and filter()?

A. I'm not killing reduce() because I hate functional programming; I'm killing
it because almost all code using reduce() is less readable than the same thing
written out using a for loop and an accumulator variable. On the other hand,
map() and filter() are often useful and when used with a pre-existing function
(e.g. a built-in) they are clearer than a list comprehension or generator
expression. (Don't use these with a lambda though; then a list comprehension is
clearer and faster.)<

I have used reduce() only a 2 or 3 times in some years of Python usage. Most
other times a sum() or product() was enough. A simple implementation of
product() using reduce():


 import operator
 product = lambda seq: reduce(operator.mul, seq)
 product(xrange(1, 10))






362880



 Yeah, sum() is probably popular enough to deserve a special case.


Good :-)

Bye and thank you,
bearophile



 Oct 03 2010



prev sibling  parent reply Jimmy Cao <jcao219 gmail.com>  writes:


The Python version:

sum(item * item for item in sequence)

can be translated to English as:

"Sum of (item * item) foreach item in sequence"

While the D version:

reduce!("a+b")(map!("a*a")(sequence), 0);

looks to me like:

Reduce! a plus b map! a times a (sequence) (and a random 0 here).



On Sun, Oct 3, 2010 at 12:59 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 10/03/2010 10:37 AM, bearophile wrote:


 Peter Alexander:

  Out of curiosity, what syntax did you propose?



 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=73868



  That said, the current D way of writing it isn't all that different

 from Python:

 return reduce!("a+b")(map!("a*a")(sequence), 0);


 That's many times worse than the Python syntax.


 This entails there's a way to measure that. How?


  Array/range comprehensions are syntax sugar, their point is to give

 something clean and readable that helps chunking:
 http://en.wikipedia.org/wiki/Chunking_%28psychology%29


 You'd need to bring a pointer to a document that confirms that (and how)
 array and range comprehensions have helping chunking as their point. I
 googled for

 array comprehensions help chunking

 to no avail.


 Andrei





 Oct 03 2010



  parent reply Peter Alexander <peter.alexander.au gmail.com>  writes:


== Quote from Jimmy Cao (jcao219 gmail.com)'s article

 The Python version:
 sum(item * item for item in sequence)
 can be translated to English as:
 "Sum of (item * item) foreach item in sequence"
 While the D version:
 reduce!("a+b")(map!("a*a")(sequence), 0);
 looks to me like:
 Reduce! a plus b map! a times a (sequence) (and a random 0 here).


If you write it as:

auto sum(Range)(Range r) { return reduce!("a+b")(r, 0); }
alias unaryFun("a*a") square;
alias map!(square) squares;

return sum(squares(sequence));

then it looks better than Python :-)

Or can we only judge a language by what's in its standard library?



 Oct 03 2010



 next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Peter Alexander:


 then it looks better than Python :-)


No, it doesn't, at all :-)



 Or can we only judge a language by what's in its standard library?


A standard library is kind of the extension of a language.
And sum() and list comps are built-in in Python.

Bye,
bearophile



 Oct 03 2010



  parent  Peter Alexander <peter.alexander.au gmail.com>  writes:


== Quote from bearophile (bearophileHUGS lycos.com)'s article

 Peter Alexander:

 then it looks better than Python :-)


 No, it doesn't, at all :-)


Then we must agree to disagree :-P

But at least we can take this as evidence that different people have quite
different views on this matter.



 Oct 03 2010



prev sibling  parent  =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


Peter Alexander wrote:

 =3D=3D Quote from Jimmy Cao (jcao219 gmail.com)'s article

 The Python version:
 sum(item * item for item in sequence)
 can be translated to English as:
 "Sum of (item * item) foreach item in sequence"
 While the D version:
 reduce!("a+b")(map!("a*a")(sequence), 0);
 looks to me like:
 Reduce! a plus b map! a times a (sequence) (and a random 0 here).


=20
 If you write it as:
=20
 auto sum(Range)(Range r) { return reduce!("a+b")(r, 0); }
 alias unaryFun("a*a") square;
 alias map!(square) squares;
=20
 return sum(squares(sequence));
=20
 then it looks better than Python :-)
=20
 Or can we only judge a language by what's in its standard library?
=20


	Given that you can do the same but shorter in Python, then I'd say
yes. Especially since even when choosing an obscure way to define
"squares" it's still more readable...

squares =3D lambda s: type (s) (x*x for x in seq)

return sum (squares (sequence))

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Oct 04 2010



prev sibling  parent  BCS <none anon.com>  writes:


Hello bearophile,


 Russel Winder:
 

 I continue to be intrigued by people who believe that code, unlike
 text, is more readable in a monospace font.  Personally I think
 monospace fonts make code unreadable,<
 


 I guess it's a matter of personal preferences. But non-proportional
 fonts have two advantages:
 - it's easy to count spaces, vertical alignments and so on;


Bingo. While it might be possible to make a single line of code in proportional 
font as readable as in mon-space, as soon as you have more than one line 
you can't make things line up, and I want that way to often to give it up.


 def sumOfSquares (sequence):
 return sum(item * item for item in sequence)
 I have suggested few times a list/lazy comp syntax for D too, and I
 have tried to explain why it's a good thing (it helps "chunking" in
 the mind of the programmer).


I believe that you can do it via map/reduce.

-- 
... <IXOYE><



 Oct 04 2010



prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Russel Winder <russel russel.org.uk> wrote:


         def sumOfSquares ( sequence ) :
             return sum ( [ item * item for item in sequence ] )
 So the question is whether there is an idiomatic D version of this.


Probably this:

auto sum( R )( R range ) {
     return reduce!"a+b"( 0, range );
}

auto sumOfSquares( R )( R range ) {
     return sum( map!"a*a"( range ) );
}

I have written an implementation of list
comprehensions for D, but it is not perfect.

Usage example:
     ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" )

"2 * a" and "a & 1" may be replaced by any callable or a string
mixin, just like functions in std.algorithm.
[1,2,3,4,5] may be replaced with any range.

This is actually two parts, so the following are also allowed
usages:

( list!"2 * a" | [1,2,3] )
( [1,2,3] & where!"a & 1" )

Using this, the solution to the above would be:

auto sum( R )( R range ) {
     return reduce!"a+b"( 0, range );
}

auto sumOfSquares( R )( R range ) {
     return sum( list!"a*a" | range );
}

////////////////////////////////////////////////////////////////
module listcomp;

import std.algorithm;
import std.range;
import std.array;

struct List( alias pred ) {
     auto opBinary( string op : "|", Range )( Range other ) {
         return map!pred(other);
     }
}

struct Where( alias pred ) {
     auto opBinaryRight( string op : "&", R )( R range ) {
         return filter!pred(range);
     }
}

 property
whereImpl!pred where( alias pred )( ) {
     Where!pred result;
     return result;
}

 property
listImpl!pred list( alias pred )( ) {
     List!pred result;
     return result;
}

unittest {
     assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ),  
[2,6,10] ) );
     assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
}
-- 
Simen



 Oct 03 2010



 next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


Simen kjaeraas:


 auto sum( R )( R range ) {
      return reduce!"a+b"( 0, range );
 }


Summing an iterable is a really common operation, and using reduce is not an
intuitive&easy thing. So I think a sum() needs to be added to std.algorithm,
this was my enhancement request for it:

http://d.puremagic.com/issues/show_bug.cgi?id=4725

Bye,
bearophile



 Oct 03 2010



prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Simen kjaeraas <simen.kjaras gmail.com> wrote:


 Russel Winder <russel russel.org.uk> wrote:


         def sumOfSquares ( sequence ) :
             return sum ( [ item * item for item in sequence ] )
 So the question is whether there is an idiomatic D version of this.


 Probably this:

 auto sum( R )( R range ) {
      return reduce!"a+b"( 0, range );
 }

 auto sumOfSquares( R )( R range ) {
      return sum( map!"a*a"( range ) );
 }

 I have written an implementation of list
 comprehensions for D, but it is not perfect.

 Usage example:
      ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" )

 "2 * a" and "a & 1" may be replaced by any callable or a string
 mixin, just like functions in std.algorithm.
 [1,2,3,4,5] may be replaced with any range.

 This is actually two parts, so the following are also allowed
 usages:

 ( list!"2 * a" | [1,2,3] )
 ( [1,2,3] & where!"a & 1" )

 Using this, the solution to the above would be:

 auto sum( R )( R range ) {
      return reduce!"a+b"( 0, range );
 }

 auto sumOfSquares( R )( R range ) {
      return sum( list!"a*a" | range );
 }


Sorry, code was wrong. Update:


module listcomp;

import std.algorithm;
import std.range;
import std.array;

struct List( alias pred ) {
     auto opBinary( string op : "|", Range )( Range other ) {
         return map!pred(other);
     }
}

struct Where( alias pred ) {
     auto opBinaryRight( string op : "&", R )( R range ) {
         return filter!pred(range);
     }
}

 property
auto where( alias pred )( ) {
     Where!pred result;
     return result;
}

 property
auto list( alias pred )( ) {
     List!pred result;
     return result;
}

unittest {
     assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ),  
[2,6,10] ) );
     assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
}

-- 
Simen



 Oct 03 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/03/2010 10:21 AM, Simen kjaeraas wrote:

 Simen kjaeraas <simen.kjaras gmail.com> wrote:


 Russel Winder <russel russel.org.uk> wrote:


 def sumOfSquares ( sequence ) :
 return sum ( [ item * item for item in sequence ] )
 So the question is whether there is an idiomatic D version of this.


 Probably this:

 auto sum( R )( R range ) {
 return reduce!"a+b"( 0, range );
 }

 auto sumOfSquares( R )( R range ) {
 return sum( map!"a*a"( range ) );
 }

 I have written an implementation of list
 comprehensions for D, but it is not perfect.

 Usage example:
 ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" )

 "2 * a" and "a & 1" may be replaced by any callable or a string
 mixin, just like functions in std.algorithm.
 [1,2,3,4,5] may be replaced with any range.

 This is actually two parts, so the following are also allowed
 usages:

 ( list!"2 * a" | [1,2,3] )
 ( [1,2,3] & where!"a & 1" )

 Using this, the solution to the above would be:

 auto sum( R )( R range ) {
 return reduce!"a+b"( 0, range );
 }

 auto sumOfSquares( R )( R range ) {
 return sum( list!"a*a" | range );
 }


 Sorry, code was wrong. Update:


 module listcomp;

 import std.algorithm;
 import std.range;
 import std.array;

 struct List( alias pred ) {
 auto opBinary( string op : "|", Range )( Range other ) {
 return map!pred(other);
 }
 }

 struct Where( alias pred ) {
 auto opBinaryRight( string op : "&", R )( R range ) {
 return filter!pred(range);
 }
 }

  property
 auto where( alias pred )( ) {
 Where!pred result;
 return result;
 }

  property
 auto list( alias pred )( ) {
 List!pred result;
 return result;
 }

 unittest {
 assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ), [2,6,10]
 ) );
 assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
 }


I wonder to what extent this improves

assert(equal(map!"2 * a"(filter!"a & 1"([1,2,3,4,5])), [2,6,10]));

One thing that's nicer with comprehensions is that you save a bit on 
nested parens.


Andrei



 Oct 03 2010



 next sibling parent reply Peter Alexander <peter.alexander.au gmail.com>  writes:


== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 On 10/03/2010 10:21 AM, Simen kjaeraas wrote:

 unittest {
 assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ), [2,6,10]
 ) );
 assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
 }


 I wonder to what extent this improves
 assert(equal(map!"2 * a"(filter!"a & 1"([1,2,3,4,5])), [2,6,10]));
 One thing that's nicer with comprehensions is that you save a bit on
 nested parens.
 Andrei


It would be nice if we could just write:

assert(equal(iota(1,6).filter!("a&1").map!("2*a"), [2,6,10]));

Incidentally, why doesn't the uniform function call syntax allow this?



 Oct 03 2010



  parent  "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Peter Alexander <peter.alexander.au gmail.com> wrote:


 It would be nice if we could just write:

 assert(equal(iota(1,6).filter!("a&1").map!("2*a"), [2,6,10]));

 Incidentally, why doesn't the uniform function call syntax allow this?


Mostly because it isn't implemented yet, I think. Well, it is for arrays,
but not for any other type, like the lazier ranges returned from iota,
filter and map.

-- 
Simen



 Oct 03 2010



prev sibling  parent  "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 assert( equal( ( list!"2 * a" | [1,2,3,4,5] & where!"a & 1" ), [2,6,1=




0]

 ) );
 assert( equal( ( list!"2 * a" | [1,2,3] ), [2,4,6] ) );
 }


 I wonder to what extent this improves

 assert(equal(map!"2 * a"(filter!"a & 1"([1,2,3,4,5])), [2,6,10]));

 One thing that's nicer with comprehensions is that you save a bit on  =



 nested parens.


In my opinion, it improves it by looking more like math language (with
which I am familiar, but this is of course a subjective measure):

( list!"2 * a" | [ 1, 2, 3, 4, 5 ] & where!"a & 1" )
vs
{ 2 * a | a =E2=88=88 [ 1, 2, 3, 4, 5 ], a & 1 !=3D 0 }

I also feel it is less cluttered and 'flows' better than your example,
but this may very well be the same issue as above.

-- =

Simen



 Oct 03 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Simen kjaeraas wrote:

 auto sum( R )( R range ) {
     return reduce!"a+b"( 0, range );
 }


This can be defined instead as:

alias reduce!"a+b" sum;



 Oct 03 2010



  parent reply Peter Alexander <peter.alexander.au gmail.com>  writes:


== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 This can be defined instead as:
 alias reduce!"a+b" sum;


But then you have to write:

    sum(sequence, 0)

which is very unintuitive.

Haskell has foldl1 and foldr1 in addition to foldl and foldr, which partially
take care of this issue (by
assuming a non-zero length list), but this is not ideal as it's perfectly
reasonable to expect a sum of a
zero-length range of integers to be 0.

In an ideal world, we would be able to define reduce something like:

auto reduce(alias Func, Range)(Range range, ElementType!Range init =
Identity!(Func,
ElementType!Range))

where

Identity!("a+b", int) = 0
Identity!("a*b", int) = 1
Identity!("a~b", char[]) = "";
etc.

However, what if people wrote reduce!((a, b) { return a+b; })(...) instead?
There's no way you could
easily relate the two; you would have to try and equate the expression trees of
the functions, which I
imagine would be no easy task, and even then you have to figure out a common
syntax for Identity...

Actually, I'm now curious as to how Andrei plans on adding sum to the standard
library in a way that
supports all summable types. Simply using 0 as the initialiser is incorrect, as
it won't work for vectors
or matrices, and requiring the user to specify the 0 (for ints) seems
unacceptable in my opinion.



 Oct 03 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Peter Alexander wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 This can be defined instead as:
 alias reduce!"a+b" sum;


 
 But then you have to write:
 
     sum(sequence, 0)
 
 which is very unintuitive.


This works:

import std.stdio;
import std.algorithm;

alias reduce!"a+b" sum;

auto sumOfSquares( R )( R range ) {
      return sum( map!"a*a"( range ) );
}

void main()
{
     writeln(sumOfSquares([1,2,3]));
}



 Oct 04 2010



  parent reply Peter Alexander <peter.alexander.au gmail.com>  writes:


== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 This works:
 import std.stdio;
 import std.algorithm;
 alias reduce!"a+b" sum;
 auto sumOfSquares( R )( R range ) {
       return sum( map!"a*a"( range ) );
 }
 void main()
 {
      writeln(sumOfSquares([1,2,3]));
 }


But then this doesn't:

int[] xs = [];
writeln(sum(xs));

but mathematically the sum is well-defined as 0 (and the product as 1).



 Oct 04 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Peter Alexander wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 This works:
 import std.stdio;
 import std.algorithm;
 alias reduce!"a+b" sum;
 auto sumOfSquares( R )( R range ) {
       return sum( map!"a*a"( range ) );
 }
 void main()
 {
      writeln(sumOfSquares([1,2,3]));
 }


 
 But then this doesn't:


Darn!


 
 int[] xs = [];
 writeln(sum(xs));
 
 but mathematically the sum is well-defined as 0 (and the product as 1).
 





 Oct 04 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Russel Winder wrote:

 On Sun, 2010-10-03 at 09:59 -0400, bearophile wrote:

 Page 20: is that functional? It even contains a mutable "sum" value.
 It may be seen as kind-of-functional. A more functional style is to
 use a reduce (fold) there, from std.algorithm.


 
 I agree this is a weird sort of an example of "functional".
 sum_of_squares as a function has no external side-effects (though
 clearly the iteration has a side effect internally) and is referentially
 transparent.  So as a thing that can be used as a "functional
 programming" function it is fine, its implementation is though very much
 imperative programming -- at its worst ;-)
 
 Given an imperative language with no tail recursion capability then one
 has to declare a non-functional floor even when doing functional style
 programming.  In effect the execution graph has to be allowed to have
 leaqf nodes that are implemented imperatively.
 
 Coming from a Pythonic realization of these ideas, list comprehensions
 seems to be the best way out of this sort of thing, so instead of:
 
         def sumOfSquares ( sequence ) :
             sum = 0.0
             for item in sequence :
                 sum +=  item * item
             return sum
 
 it is better to write:
 
         def sumOfSquares ( sequence ) :
             return sum ( [ item * item for item in sequence ] )
         
 So the question is whether there is an idiomatic D version of this.


This is quite deliberate on my part, and I'm glad it piqued your interest. D's 
support for functional programming is NOT about all data being immutable. It is 
about being able to draw a circle around a block of code (i.e. a function) and 
saying that "THIS block of code has no side effects." If it modifies variables 
internally that is of no import if those modifications are not visible outside 
of that block.

This is, in my not so humble opinion, of great value in that one does NOT have 
to rethink one's approach to coding in order to gain the advantages of 
functional programming. I.e. one can write a normal loop such as the sum one, 
rather than trying to figure out list comprehensions and tail recursion.

It's like what's wrong with C++ metaprogramming - you have to learn a whole new 
language. D metaprogramming can be done using ordinary D functions. Nothing new 
to learn.



 Oct 03 2010



  parent reply retard <re tard.com.invalid>  writes:


Sun, 03 Oct 2010 12:43:07 -0700, Walter Bright wrote:


 Russel Winder wrote:

 On Sun, 2010-10-03 at 09:59 -0400, bearophile wrote:

 Page 20: is that functional? It even contains a mutable "sum" value.
 It may be seen as kind-of-functional. A more functional style is to
 use a reduce (fold) there, from std.algorithm.


 
 I agree this is a weird sort of an example of "functional".
 sum_of_squares as a function has no external side-effects (though
 clearly the iteration has a side effect internally) and is
 referentially transparent.  So as a thing that can be used as a
 "functional programming" function it is fine, its implementation is
 though very much imperative programming -- at its worst ;-)
 
 Given an imperative language with no tail recursion capability then one
 has to declare a non-functional floor even when doing functional style
 programming.  In effect the execution graph has to be allowed to have
 leaqf nodes that are implemented imperatively.
 


 
 This is quite deliberate on my part, and I'm glad it piqued your
 interest. D's support for functional programming is NOT about all data
 being immutable. It is about being able to draw a circle around a block
 of code (i.e. a function) and saying that "THIS block of code has no
 side effects." If it modifies variables internally that is of no import
 if those modifications are not visible outside of that block.
 
 This is, in my not so humble opinion, of great value in that one does
 NOT have to rethink one's approach to coding in order to gain the
 advantages of functional programming. I.e. one can write a normal loop
 such as the sum one, rather than trying to figure out list
 comprehensions and tail recursion.
 
 It's like what's wrong with C++ metaprogramming - you have to learn a
 whole new language. D metaprogramming can be done using ordinary D
 functions. Nothing new to learn.


Is this also true for Haskell/OCaml/SML/Erlang/Clojure/Lisp programmers? 
Nothing new to learn when using the "functional" features of D? Does TCO 
work well? Other common optimizations such as common deforestation 
techniques? The sad fact is, there's no need to learn new stuff ONLY when 
one comes from C/C++. Users of every other language have very much to 
learn. Not necessarily in a good way.



 Oct 03 2010



 next sibling parent  Daniel Gibson <metalcaedes gmail.com>  writes:


On Mon, Oct 4, 2010 at 12:44 AM, retard <re tard.com.invalid> wrote:

 Sun, 03 Oct 2010 12:43:07 -0700, Walter Bright wrote:

 It's like what's wrong with C++ metaprogramming - you have to learn a
 whole new language. D metaprogramming can be done using ordinary D
 functions. Nothing new to learn.


 Is this also true for Haskell/OCaml/SML/Erlang/Clojure/Lisp programmers?
 Nothing new to learn when using the "functional" features of D? Does TCO
 work well? Other common optimizations such as common deforestation
 techniques? The sad fact is, there's no need to learn new stuff ONLY when
 one comes from C/C++. Users of every other language have very much to
 learn. Not necessarily in a good way.


If you're gonna use the "functional features" in D you'll want to
learn "normal" D and its syntax anyway, so what's your point?



 Oct 03 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


retard wrote:

 Is this also true for Haskell/OCaml/SML/Erlang/Clojure/Lisp programmers? 
 Nothing new to learn when using the "functional" features of D? Does TCO 
 work well? Other common optimizations such as common deforestation 
 techniques? The sad fact is, there's no need to learn new stuff ONLY when 
 one comes from C/C++. Users of every other language have very much to 
 learn. Not necessarily in a good way.


If they're already using D, they don't have to learn a totally new
grammar/style 
when deciding to use a functional style.

Really, *why* force people to rewrite their loops to use tail recursion? It's a 
giant turn-off, and completely unnecessary.

And D does do tail call elimination, if you *want* to write your code that way. 
The point is, D doesn't require it if you don't like it.

I also think you're way, way overstating your case when you argue that the only 
language D is grammatically similar to is C and C++. It's also similar to Java 

covering 90+% of the programmers out there. That's a feature, not something sad.



 Oct 03 2010



  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Sunday 03 October 2010 16:05:19 Walter Bright wrote:

 I also think you're way, way overstating your case when you argue that the
 only language D is grammatically similar to is C and C++. It's also


 a feature, not something sad.


Oh course it's sad. That 90% should be using D instead. ;)

- Jonathan M Davis



 Oct 03 2010



prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-10-03 09:59:16 -0400, bearophile <bearophileHUGS lycos.com> said:


 Page 19:

 Unlike C++, values can be moved in memory  Postblit is used to “adjust” 
 things after a move<


 
 OK, so a moving GC needs to call the Postblit each time it moves a struct.


But isn't postblit used only when doing a copy? I think the last word 
in the quote should be "copy", not "move". So a moving GC does not have 
to call postblit.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Oct 03 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Michel Fortin wrote:

 On 2010-10-03 09:59:16 -0400, bearophile <bearophileHUGS lycos.com> said:
 

 Page 19:

 Unlike C++, values can be moved in memory  Postblit is used to 
 “adjust” things after a move<


 OK, so a moving GC needs to call the Postblit each time it moves a 
 struct.


 
 But isn't postblit used only when doing a copy? I think the last word in 
 the quote should be "copy", not "move". So a moving GC does not have to 
 call postblit.


Right.

In D, all struct (and class) instances are, by definition, movable using
memcpy().

The advantage is not just enabling a moving GC, but it also enables a whole
host 
of optimizations that are not possible in C++.

C++0x tries to address this problem with rvalue references and moving
constructors.



 Oct 03 2010



  parent reply Max Samukha <spambox d-coding.com>  writes:


On 10/03/2010 10:47 PM, Walter Bright wrote:

 In D, all struct (and class) instances are, by definition, movable using
 memcpy().


Structs are ok. Classes are not. Do you really want to forbid this use case:

class A
{
     private A _parent;
     private A[] _children;

     this(A parent)
     {
         if (parent !is null) {
             _parent = parent;
	    _parent._children ~= this;
         }
     }
}

auto parent = new A;
auto child = new A(parent);

?



 Oct 04 2010



  parent reply "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Max Samukha <spambox d-coding.com> wrote:


 On 10/03/2010 10:47 PM, Walter Bright wrote:

 In D, all struct (and class) instances are, by definition, movable using
 memcpy().


 Structs are ok. Classes are not. Do you really want to forbid this use  
 case:

 class A
 {
      private A _parent;
      private A[] _children;

      this(A parent)
      {
          if (parent !is null) {
              _parent = parent;
 	    _parent._children ~= this;
          }
      }
 }

 auto parent = new A;
 auto child = new A(parent);

 ?


I don't see how that is incompatible with what Walter said. Of course
one would need to update pointers to the moved classes.

-- 
Simen



 Oct 04 2010



  parent reply Max Samukha <spambox d-coding.com>  writes:


On 10/04/2010 10:47 PM, Simen kjaeraas wrote:

 Max Samukha <spambox d-coding.com> wrote:


 On 10/03/2010 10:47 PM, Walter Bright wrote:

 In D, all struct (and class) instances are, by definition, movable using
 memcpy().


 Structs are ok. Classes are not. Do you really want to forbid this use
 case:

 class A
 {
 private A _parent;
 private A[] _children;

 this(A parent)
 {
 if (parent !is null) {
 _parent = parent;
 _parent._children ~= this;
 }
 }
 }

 auto parent = new A;
 auto child = new A(parent);

 ?


 I don't see how that is incompatible with what Walter said. Of course
 one would need to update pointers to the moved classes.


He said "movable using memcpy()". He didn't say anything about adjusting 
pointers. A moving GC should and will adjust pointers, but I don't see 
how the memcpy() is relevant here.



 Oct 04 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Max Samukha wrote:

 He said "movable using memcpy()". He didn't say anything about adjusting 
 pointers. A moving GC should and will adjust pointers, but I don't see 
 how the memcpy() is relevant here.


The moving GC would adjust the pointers, but the memcpy() means that other 
things would not need to be done, such as incrementing counters, all the things 
that non-trivial copy constructors do.



 Oct 04 2010



  parent  Max Samukha <spambox d-coding.com>  writes:


On 10/05/2010 02:42 AM, Walter Bright wrote:

 Max Samukha wrote:

 He said "movable using memcpy()". He didn't say anything about
 adjusting pointers. A moving GC should and will adjust pointers, but I
 don't see how the memcpy() is relevant here.


 The moving GC would adjust the pointers, but the memcpy() means that
 other things would not need to be done, such as incrementing counters,
 all the things that non-trivial copy constructors do.


Now I see what you meant. Thanks for the explanation.



 Oct 05 2010



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


bearophile wrote:

 Page 10, and in other pages I'd like a non-proportional font for the code,
 because I find it a little more readable (even better if it's colorized,
 there are online tools able to produce colorized HTML from D1 code too).


I normally prefer monospaced fonts for code, but using a proportional font here 
made it easier to fit more code on the slide.

Presenting meaningful code on a slide is always a big problem.



 Oct 03 2010



prev sibling next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


 Page 30: that little concurrent test program gives me an error:
 ...\dmd\src\phobos\std\typecons.d(336): Error: no property 'length' for type
'immutable(char)'


A reduced test case:

import std.concurrency: spawn, send;
void foo() {}
void main() {
    foreach (b; [cast(immutable(ubyte)[])[1]])
        send(spawn(&foo), b);
}

Bye,
bearophile



 Oct 03 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Looks like it hit reddit:

http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/



 Oct 03 2010



  parent reply Gary Whatmore <no spam.spam>  writes:


Walter Bright Wrote:


 Looks like it hit reddit:
 
 http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/


Their already criticizing D. We must defend ourselves.

 - G.W.



 Oct 03 2010



  parent  Gary Whatmore <no spam.spam>  writes:


Gary Whatmore Wrote:


 Walter Bright Wrote:
 

 Looks like it hit reddit:
 
 http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/




http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/c11d2ie

There's a new tough comment that would make our efforts look amateurish if some
reddit troll manages to answer it too quickly!

 - G.W.



 Oct 04 2010