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:
--0015174c16ac299b6c0491b43060
Content-Type: text/plain; charset=ISO-8859-1

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 --0015174c16ac299b6c0491b43060 Content-Type: text/html; charset=ISO-8859-1 Interesting, would have loved to be there :)<br><br><div class="gmail_quote">On 3 October 2010 12:28, Walter Bright <span dir="ltr">&lt;<a href="mailto:newshound2 digitalmars.com">newshound2 digitalmar .com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The slides for my Sep. 15 talk at NWCPP:<br> <br> <a href="http://nwcpp.org/images/stories/nwcpp-2010-09.pdf" target="_blank">http://nwcpp.org/images/stories/nwcpp-2010-09.pdf</a><br> </blockquote></div><br><br clear="all"><br>-- <br>// Yours sincerely<br>// Emil &#39;Skeen&#39; Madsen<br> --0015174c16ac299b6c0491b43060--
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:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

 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 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 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
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 next sibling parent "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
prev sibling 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:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

bearophile wrote:
 SiegeLord:
=20
 Back when I was programming Python I found the array comprehension syn=


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

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=

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

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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

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

=20

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

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

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

–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

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



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

Good :-) Bye and thank you, bearophile
Oct 03 2010
prev sibling 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 :-)


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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

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

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

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 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 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
parent 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] ) );
 }

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
prev sibling next 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 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 and C#, and when you combine the users of C, C++, Java, and C# you're probably covering 90+% of the programmers out there. That's a feature, not something sad.
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 next sibling parent "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
prev sibling next sibling parent "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
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 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 next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--0015174bdc5c9b68c90491ba71c0
Content-Type: text/plain; charset=ISO-8859-1

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

--0015174bdc5c9b68c90491ba71c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The Python version:<blockquote class=3D"webkit-indent-blockquote" style=3D"= margin: 0 0 0 40px; border: none; padding: 0px;"><div><span class=3D"Apple-= style-span" style=3D"font-family: arial, sans-serif; font-size: 13px; borde= r-collapse: collapse; ">sum(item * item for item in sequence)</span></div> </blockquote><div><font class=3D"Apple-style-span" face=3D"arial, sans-seri= f"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">ca= n be translated to English as:</span></font></div><blockquote class=3D"webk= it-indent-blockquote" style=3D"margin: 0 0 0 40px; border: none; padding: 0= px;"> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;">&quot;Sum of (i= tem * item) foreach item in sequence&quot;</span></font></div><div><font cl= ass=3D"Apple-style-span" face=3D"arial, sans-serif"><span class=3D"Apple-st= yle-span" style=3D"border-collapse: collapse;"><br> </span></font></div></blockquote><font class=3D"Apple-style-span" face=3D"a= rial, sans-serif"><span class=3D"Apple-style-span" style=3D"border-collapse= : collapse;">While the D version:</span></font><blockquote class=3D"webkit-= indent-blockquote" style=3D"margin: 0 0 0 40px; border: none; padding: 0px;= "> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><span class=3D"= Apple-style-span" style=3D"border-collapse: separate; font-family: arial; "=
reduce!(&quot;a+b&quot;)(map!(&quot;a*a&quot;)(sequence), 0);</span></span=
</font></div>

</blockquote>looks to me like:<blockquote class=3D"webkit-indent-blockquote= " style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>Reduce! a = plus b map! a times a (sequence) (and a random 0 here).</div></blockquote> <div> <div><font class=3D"Apple-style-span" face=3D"arial, sans-serif"><span clas= s=3D"Apple-style-span" style=3D"border-collapse: collapse;"><br></span></fo= nt><div><br><div class=3D"gmail_quote">On Sun, Oct 3, 2010 at 12:59 PM, And= rei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail= erdani.org">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On 10/03/2010 10:37 AM, b= earophile wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Peter Alexander:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Out of curiosity, what syntax did you propose?<br> </blockquote> <br> <a href=3D"http://www.digitalmars.com/webnews/newsgroups.php?art_group=3Ddi= gitalmars.D&amp;article_id=3D73868" target=3D"_blank">http://www.digitalmar= s.com/webnews/newsgroups.php?art_group=3Ddigitalmars.D&amp;article_id=3D738= 68</a><br> <br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> That said, the current D way of writing it isn&#39;t all that different<br> from Python:<br> <br> return reduce!(&quot;a+b&quot;)(map!(&quot;a*a&quot;)(sequence), 0);<br> </blockquote> <br> That&#39;s many times worse than the Python syntax.<br> </blockquote> <br></div> This entails there&#39;s a way to measure that. How?<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Array/range comprehensions are syntax sugar, their point is to give<br> something clean and readable that helps chunking:<br> <a href=3D"http://en.wikipedia.org/wiki/Chunking_%28psychology%29" target= =3D"_blank">http://en.wikipedia.org/wiki/Chunking_%28psychology%29</a><br> </blockquote> <br></div> You&#39;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 go= ogled for<br> <br> array comprehensions help chunking<br> <br> to no avail.<br><font color=3D"#888888"> <br> <br> Andrei<br> </font></blockquote></div><br></div></div></div> --0015174bdc5c9b68c90491ba71c0--
Oct 03 2010
prev sibling next 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 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
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
 similar to Java and C#, and when you combine the users of C, C++, Java,
 and C# you're probably covering 90+% of the programmers out there. That's
 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 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 next sibling 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 next 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=


 ) );
 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 "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
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