www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why Ruby?

reply Ary Borenszweig <ary esperanto.org.ar> writes:
http://vimeo.com/17420638

A very interesting talk.

I used to like D. To write code in a high level while at the same
time being very close to the machine, with class invariants, unit
tests and many other features seemed very appealing. But I always
felt there was something wrong.


Python and D kind of ugly and uncomfortable. Why? Exactly because of
what it is said in that video.

This is not to start a flame war or trolling, it's just to show you
why I changed my mind so much about D, and why I think (IMHO) you
should care about naming conventions (like bearophile says), more
powerful unittests (and not having unittests integrated into the
language but rather being able to build your own test frameworks
with ease) and stop caring about being C-syntax friendly. The world
doesn't need that many semicolons and parenthesis. :-)
Dec 10 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/10 5:26 PM, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


I watched the video until the enthusiastic comment that "unless" was a 
huge eye opener, when I stopped. I think I'll try watching again now.

Andrei
Dec 10 2010
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Yes, haha, that "unless" part is a bit silly. :-P

The interesting part comes when he talks about the testing philosophy,
the beauty of code and the focus on the happiness of programmers.
Dec 10 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/10 5:41 PM, Ary Borenszweig wrote:

 Yes, haha, that "unless" part is a bit silly. :-P

 The interesting part comes when he talks about the testing philosophy,
 the beauty of code and the focus on the happiness of programmers.


I watched the entire talk now. Quite entertaining, but there are a few 
things that don't quite sit all that well. I am in fact fairly surprised 
that you found it insightful.

One is, the talk starts with this extreme syntax exegesis where the 
position of literally every space and every letter matters a lot, and 
how exactly one choice for each is perfect and no other. Then a large 
part of the talk is dedicated to more or less successful metaphors and 
comparisons centered on freedom. This to me amounts to a guy who would 
want the freedom to smoke pot, but would beat his wife if she didn't 
align the towels on the bathroom rack.

Now, the part about freedom is also a bit odd. The discussion is about 
freedom in a system that confines _from day one_ a memory model on you 
that makes a great deal of things difficult or impossible.



Andrei
Dec 10 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:iduqor$1kj0$1 digitalmars.com...

 One is, the talk starts with this extreme syntax exegesis where the 
 position of literally every space and every letter matters a lot, and how 
 exactly one choice for each is perfect and no other. Then a large part of 
 the talk is dedicated to more or less successful metaphors and comparisons 
 centered on freedom. This to me amounts to a guy who would want the 
 freedom to smoke pot, but would beat his wife if she didn't align the 
 towels on the bathroom rack.


I've been using Ruby (with Rake) for roughly a year to manage the build 
process of a fairly complex (in terms of number of different 
tools/languages/technologies/etc involved) server/client web app. While 
there are nice things about it, I think your description of it is exactly 
on-the-mark.

I can definitely see in Ruby how the designer was trying for a "natural 
language/thought-process" feel, but it just ends up feeling 
sloppily-designed. I never feel completely confident that what I write is 
actually going to get parsed as I intended. It's like playing with voodoo, 
especially when you toss in the syntax-tricks that idiomatic-Rake uses. It 
certainly gets the job done for what I'm using it for, but if there was a 
DRake, I'd be using it instead.
Dec 10 2010
next sibling parent Russel Winder <russel russel.org.uk> writes:
On Sat, 2010-12-11 at 01:12 -0500, Nick Sabalausky wrote:
[ . . . ]

 I can definitely see in Ruby how the designer was trying for a "natural=


=20

 language/thought-process" feel, but it just ends up feeling=20
 sloppily-designed. I never feel completely confident that what I write is=


=20

 actually going to get parsed as I intended. It's like playing with voodoo=


,=20

 especially when you toss in the syntax-tricks that idiomatic-Rake uses. I=


t=20

 certainly gets the job done for what I'm using it for, but if there was a=


=20

 DRake, I'd be using it instead.


I tried Rake some time ago when I decided that external DSL-ish Make
(whilst a huge revolution and revelation in 1978) had gone past it's
"use by" date -- GNU Make tries hard to cope but . . . Internal DSL, so
having the power of the programming language to hand, seem to be the way
forward.  Rake though seemed totally centred on supporting only Ruby
activity.  No real support for C, C++, Fortran, LaTeX, except "do it
yourself" stuff.  I then found Rant which was trying to replace Rake but
with proper infrastructure to have great support for C, C++, Fortran,
LaTeX.  Sadly the project died for lack of interest.  Conclusion:
anyone with sufficient interest in Ruby and "build" was unlikely to be
doing anything other than Ruby :-(  I then moved attention to SCons.
Python instead of Ruby, but lots, and lots of support for C, C++,
Fortran, LaTeX.  Actually too much support for C and C++, it is too
hardwired into the core of SCons.  Also there are some issued of speed.
Waf was originally a fork of SCons, but is now completely its own thing.
Waf is an Autotool replacement, where as SCons is a Make replacement.  I
end up using both, Waf in a project context and SCons where I need more
generality, no project structure per se.

Both SCons and Waf have support for D -- but both could do with more and
better usage, community and support.

Generally it seems that for any new language, those interested in build
have the knee jerk reaction of having to write a new build system.
Usually the build system has little generality, too focused on the
language of origin, and having lots of zealots.  The JVM-based-verse is
full of such things.  But let's leave them to it.

I would suggest that a dynamic language is the right platform on which
to create a build framework.  This would seem to rule out D as a
language for construction of build systems -- though SBT in Scala has
ploughed effectively this "static language as platform" furrow, so
maybe . . .

The Go community seems to have an unusually large supply of the "must
write a new build framework using this new language" folk, I seem to
count seven new build frameworks at the last count.  The Google folk who
are the core Go team have though stuck with Make -- which really seems
strange.

OK so what the purpose of this email:  I think it would be good to line
up behind one or two build frameworks and make sure they have seriously
good support for D build, especially given the relationship of D to C
and C++.  This would seem to indicate SCons and Waf from the current
batch, though I bet most people are still using Make.    But it is so
hard to provide "plugin tools" with make, especially compared to SCons
and Waf.

I am assuming that people are not going to vote in favour of Autotools
being the one true build framework for D ;-)

I should stop writing here and open things up to the floor . . .=20
--=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
Dec 11 2010
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/11/2010 12:12 AM, Nick Sabalausky wrote:

 I can definitely see in Ruby how the designer was trying for a "natural
 language/thought-process" feel, but it just ends up feeling
 sloppily-designed. I never feel completely confident that what I write is
 actually going to get parsed as I intended.


First time I used ruby, I did something like

a = 1 * (4
          + 5
          + 6)

cuz you can do that in python and you would expect ruby to be similar.
So I scratched my head for about an hour trying to figure out why a was 
always 6. I don't know why, but ruby ignores the 4 and 5 unless they are 
all on the same line.

That was about the last time I used ruby.
Dec 11 2010
prev sibling next sibling parent so <so so.do> writes:
On Sat, 11 Dec 2010 03:26:01 +0200, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


Before watching, i have to say two things.


reason is that you can afford to use that language.
Second, D is above those languages, don't make the mistake of comparing  
them. This is also not to start a flame war.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 10 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/10 5:26 PM, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


BTW I first got to the talk from the reddit discussion here:

http://www.reddit.com/r/programming/comments/ej2be/dhhs_rubyconf_keynote_on_why_he_loves_ruby_turns/


Andrei
Dec 10 2010
prev sibling next sibling parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 12/10/10 19:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638
 
 A very interesting talk.
 
 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.
 

 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.
 
 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
use the tool that feels best for the job, whatever that may be at a
given time.  Sitting on a disc somewhere are some personal tools I used
to use when working with D... which are themselves written in Ruby (and
bash script, but hey).

Then again, I'm the same one who really really likes Ruby on Rails...
and yet still does most things with PHP.  Why?  Well for one, because
for plenty of projects, Rails is less an aid and more a hindrance.  (And
yes, before someone brings it up, I'm well aware of CakePHP... and don't
care for it much.)

There are times in D when I find myself wishing, momentarily, for the
loose typing of Ruby... but then there are times in Ruby when I find
myself wishing for stricter typing.

There are times when I wish D had open classes... but then there are
times when Ruby's open classes give me headaches.

I could go on like this... but the point was really just: use the right
tool for the job.  Keep several tools in your toolbox.  There is no "THE
BEST LANGUAGE OMG!!!"  There is just the best one for a given programmer
in a given scenario.  Some of the things I've done could probably have
been better written in, say, Pike!  But I don't really know Pike (very
well), and don't feel the need to learn it just for those few things
that might have benefited.

-- Chris N-S
Dec 10 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:

 On 12/10/10 19:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


 I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
 use the tool that feels best for the job, whatever that may be at a
 given time.  Sitting on a disc somewhere are some personal tools I used
 to use when working with D... which are themselves written in Ruby (and
 bash script, but hey).

 Then again, I'm the same one who really really likes Ruby on Rails...
 and yet still does most things with PHP.  Why?  Well for one, because
 for plenty of projects, Rails is less an aid and more a hindrance.  (And
 yes, before someone brings it up, I'm well aware of CakePHP... and don't
 care for it much.)

 There are times in D when I find myself wishing, momentarily, for the
 loose typing of Ruby... but then there are times in Ruby when I find
 myself wishing for stricter typing.

 There are times when I wish D had open classes... but then there are
 times when Ruby's open classes give me headaches.

 I could go on like this... but the point was really just: use the right
 tool for the job.  Keep several tools in your toolbox.  There is no "THE
 BEST LANGUAGE OMG!!!"  There is just the best one for a given programmer
 in a given scenario.  Some of the things I've done could probably have
 been better written in, say, Pike!  But I don't really know Pike (very
 well), and don't feel the need to learn it just for those few things
 that might have benefited.

 -- Chris N-S


Agreed. One issue with the talk is non-acceptance of "the right tool for 
the job" (the speaker literally says he's tired of that phrase). There 
is one best tool - and that's Ruby. Ahem.


Andrei
Dec 11 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 11 December 2010 00:01:35 Andrei Alexandrescu wrote:

 On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:

 On 12/10/10 19:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638
 
 A very interesting talk.
 
 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.
 

 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.
 
 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


 
 I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
 use the tool that feels best for the job, whatever that may be at a
 given time.  Sitting on a disc somewhere are some personal tools I used
 to use when working with D... which are themselves written in Ruby (and
 bash script, but hey).
 
 Then again, I'm the same one who really really likes Ruby on Rails...
 and yet still does most things with PHP.  Why?  Well for one, because
 for plenty of projects, Rails is less an aid and more a hindrance.  (And
 yes, before someone brings it up, I'm well aware of CakePHP... and don't
 care for it much.)
 
 There are times in D when I find myself wishing, momentarily, for the
 loose typing of Ruby... but then there are times in Ruby when I find
 myself wishing for stricter typing.
 
 There are times when I wish D had open classes... but then there are
 times when Ruby's open classes give me headaches.
 
 I could go on like this... but the point was really just: use the right
 tool for the job.  Keep several tools in your toolbox.  There is no "THE
 BEST LANGUAGE OMG!!!"  There is just the best one for a given programmer
 in a given scenario.  Some of the things I've done could probably have
 been better written in, say, Pike!  But I don't really know Pike (very
 well), and don't feel the need to learn it just for those few things
 that might have benefited.
 
 -- Chris N-S


 
 Agreed. One issue with the talk is non-acceptance of "the right tool for
 the job" (the speaker literally says he's tired of that phrase). There
 is one best tool - and that's Ruby. Ahem.


LOL. I'd _love_ to use D at work, but so much of our code is in C++ and must 
compile with Visual Studio that the fact that C++ doesn't integrate with D all 
that well and the fact that you have to use dmc on Windows for the C or C++
code 
if you want to link it with D code make it so that it doesn't make any sense at 
all to use D at this point.

And of course, there are plenty of cases where a particular language is just 
incredibly well suited for a particular job, and the best general purpose 
language just isn't as good.

I think that it's good to strive to a have a language that is excellent for
most 
use cases, but ultimately, you always have to pick the best tool for the job.
No 
language is the best for all scenarios even if it's the best for most scenarios.

- Jonathan M Davis
Dec 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:

 I think that it's good to strive to a have a language that is excellent for
most 
 use cases, but ultimately, you always have to pick the best tool for the job.
No 
 language is the best for all scenarios even if it's the best for most
scenarios.



If you're an expert on X, it still is probably more productive to use X for the 
job rather than Y, even if Y is the better tool for the job.
Dec 11 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 11 December 2010 03:35:29 Walter Bright wrote:

 Jonathan M Davis wrote:

 I think that it's good to strive to a have a language that is excellent
 for most use cases, but ultimately, you always have to pick the best
 tool for the job. No language is the best for all scenarios even if it's
 the best for most scenarios.


 
 If you're an expert on X, it still is probably more productive to use X for
 the job rather than Y, even if Y is the better tool for the job.


Well, in a way, you could say that that tool was _not_ the best tool for the
job 
because it wouldn't do as good a job simply because you weren't as proficient
in 
it. Ultimately, you have to take the whole situation - including your
particular 
skill set - into account when choosing which tool to use for a particular job - 
especially when talking about programming lanugages.

- Jonathan M Davis
Dec 11 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:

 On 12/10/10 19:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


 I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
 use the tool that feels best for the job, whatever that may be at a
 given time.  Sitting on a disc somewhere are some personal tools I used
 to use when working with D... which are themselves written in Ruby (and
 bash script, but hey).

 Then again, I'm the same one who really really likes Ruby on Rails...
 and yet still does most things with PHP.  Why?  Well for one, because
 for plenty of projects, Rails is less an aid and more a hindrance.  (And
 yes, before someone brings it up, I'm well aware of CakePHP... and don't
 care for it much.)

 There are times in D when I find myself wishing, momentarily, for the
 loose typing of Ruby... but then there are times in Ruby when I find
 myself wishing for stricter typing.

 There are times when I wish D had open classes... but then there are
 times when Ruby's open classes give me headaches.

 I could go on like this... but the point was really just: use the right
 tool for the job.  Keep several tools in your toolbox.  There is no "THE
 BEST LANGUAGE OMG!!!"  There is just the best one for a given programmer
 in a given scenario.  Some of the things I've done could probably have
 been better written in, say, Pike!  But I don't really know Pike (very
 well), and don't feel the need to learn it just for those few things
 that might have benefited.

 -- Chris N-S


 
 Agreed. One issue with the talk is non-acceptance of "the right tool for 
 the job" (the speaker literally says he's tired of that phrase). There 
 is one best tool - and that's Ruby. Ahem.
 
 Andrei


I find this issue interesting. I think the "the right tool for the job"
is justification for the existence of multiple languages, but on the 
other hand, I'd agree with him that it's overused.

If you consider all problem domains, and then ask: what is the minimum 
number of languages required to be "the best tool" or "close enough to 
the best tool" for all those jobs? For sure the minimum number is > 1.
But I suspect the minimum isn't very high, essentially because most real 
world tasks involve a combination of several problem domains.
I think the minimum might be as small as five, and I seriously doubt 
it's more than a dozen.
Dec 11 2010
next sibling parent spir <denis.spir gmail.com> writes:
On Sat, 11 Dec 2010 10:22:19 +0100
Don <nospam nospam.com> wrote:


 Andrei Alexandrescu wrote:

 Agreed. One issue with the talk is non-acceptance of "the right tool fo=




r=20

 the job" (the speaker literally says he's tired of that phrase). There=




=20

 is one best tool - and that's Ruby. Ahem.


=20
 I find this issue interesting. I think the "the right tool for the job"
 is justification for the existence of multiple languages, but on the=20
 other hand, I'd agree with him that it's overused.
=20
 If you consider all problem domains, and then ask: what is the minimum=20
 number of languages required to be "the best tool" or "close enough to=20
 the best tool" for all those jobs? For sure the minimum number is > 1.
 But I suspect the minimum isn't very high, essentially because most real=


=20

 world tasks involve a combination of several problem domains.
 I think the minimum might be as small as five, and I seriously doubt=20
 it's more than a dozen.


I agree with that. This number is around 3 ;-)
"the right tool for the job" is about meaningless for me, since noone would=
 make me program with 99% of existing PLs even if they were proved to be "i=
t". I rather believe in "the right tool for the right person".

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 11 2010
prev sibling next sibling parent reply so <so so.do> writes:
 I find this issue interesting. I think the "the right tool for the job"
 is justification for the existence of multiple languages, but on the  
 other hand, I'd agree with him that it's overused.

 If you consider all problem domains, and then ask: what is the minimum  
 number of languages required to be "the best tool" or "close enough to  
 the best tool" for all those jobs? For sure the minimum number is > 1.
 But I suspect the minimum isn't very high, essentially because most real  
 world tasks involve a combination of several problem domains.
 I think the minimum might be as small as five, and I seriously doubt  
 it's more than a dozen.


The usage of "the right tool for the job" is sometimes just BS.
For example scripting C/C++/D.

You use another language there mostly because you have to. Not because  
they are the right tool.
Providing that feature probably not that hard for a language. If it is so  
hard/impossible i want to know reasons, please enlighten me!
If you don't provide one, the lesser beings(programmers) fall back to  
another languages, create a culture that make other lesser beings believe  
that is the way it should be.

Not to hijack this one but on the other thread i asked why this is needed.
I am not here asking for syntax or commanding phobos team to implement  
something, I just want to know about technical limitations and license  
issues, but got no answer to these.
Why? Either i am labeled here as a troll (maybe something worse since my  
usage of English is not the best) or people here lack the vision (Oh  
vision here actually bad usage since this bad practice have been here  
forever, lack of eyesight would be the better definition)
One another thing might be that the community finds this issue is not an  
important, (which makes me ask myself what you guys actually developing).

Thanks!

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 11 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/10 11:05 AM, so wrote:

 I find this issue interesting. I think the "the right tool for the job"
 is justification for the existence of multiple languages, but on the
 other hand, I'd agree with him that it's overused.

 If you consider all problem domains, and then ask: what is the minimum
 number of languages required to be "the best tool" or "close enough to
 the best tool" for all those jobs? For sure the minimum number is > 1.
 But I suspect the minimum isn't very high, essentially because most
 real world tasks involve a combination of several problem domains.
 I think the minimum might be as small as five, and I seriously doubt
 it's more than a dozen.


 The usage of "the right tool for the job" is sometimes just BS.
 For example scripting C/C++/D.

 You use another language there mostly because you have to. Not because
 they are the right tool.


Those are the same ways of saying the same thing. You use C to implement 
Ruby's garbage collector. Why? Because you have to. Why again? Because 
it's the right tool for the job. In particular, C can do that because it 
has pointer arithmetic - a freedom discriminated against by the speaker. 
Consistency FTW I guess :o).

Andrei
Dec 11 2010
parent so <so so.do> writes:
 Those are the same ways of saying the same thing. You use C to implement  
 Ruby's garbage collector. Why? Because you have to. Why again? Because  
 it's the right tool for the job. In particular, C can do that because it  
 has pointer arithmetic - a freedom discriminated against by the speaker.  
 Consistency FTW I guess :o).


I agree, in your example you are right and the reasons obvious.
My example is (i think) a bit different and the reasons not all obvious  
(to me), which is why i am trying to learn more about it.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 11 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/10 11:05 AM, so wrote:

 Not to hijack this one but on the other thread i asked why this is needed.
 I am not here asking for syntax or commanding phobos team to implement
 something, I just want to know about technical limitations and license
 issues, but got no answer to these.
 Why? Either i am labeled here as a troll (maybe something worse since my
 usage of English is not the best) or people here lack the vision (Oh
 vision here actually bad usage since this bad practice have been here
 forever, lack of eyesight would be the better definition)
 One another thing might be that the community finds this issue is not an
 important, (which makes me ask myself what you guys actually developing).


I don't think you're near the danger of being labeled as a troll. Would 
be great to focus the discussion a bit.

For example, let's take a look at the code example given in the talk's 
first part that shows the beauty of Ruby. What does it look like in D? 
What can we do to make it look and behave better?


Andrei
Dec 11 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-11 18:21, Andrei Alexandrescu wrote:

 On 12/11/10 11:05 AM, so wrote:

 Not to hijack this one but on the other thread i asked why this is
 needed.
 I am not here asking for syntax or commanding phobos team to implement
 something, I just want to know about technical limitations and license
 issues, but got no answer to these.
 Why? Either i am labeled here as a troll (maybe something worse since my
 usage of English is not the best) or people here lack the vision (Oh
 vision here actually bad usage since this bad practice have been here
 forever, lack of eyesight would be the better definition)
 One another thing might be that the community finds this issue is not an
 important, (which makes me ask myself what you guys actually developing).


 I don't think you're near the danger of being labeled as a troll. Would
 be great to focus the discussion a bit.

 For example, let's take a look at the code example given in the talk's
 first part that shows the beauty of Ruby. What does it look like in D?
 What can we do to make it look and behave better?


 Andrei


If we take a look at the very first code example from the talk it looks 
like this:

account.people.each do |person|
     puts person.name
end

You could translate this in two ways when translating into D.
First way:

foreach (person ; account.people)
     writeln(person.name);

I guess this is the most natural translation into D. If we want to be 
closer to the Ruby code which uses a block we can translate the code to 
use a delegate like this:

account.people.each((Person person) {
     writeln(person.name);
});

In my opinion this looks really ugly, D has no way of passing a delegate 
to a function that looks good. If D could allow to pass a delegate to a 
function outside the parameter list, after the function call, and had 
better type inference it could look like this:

account.people.each(person) {
     writeln(person.name);
}

The above code is very close to the original Ruby code the only 
differences is that D uses {} and Ruby uses "do" and "end".

If we have a look at the next code example from the talk there is no 
clear and natural way to translate it into D, first the Ruby code:

class PeopleController < ActionController::Base
     before_filter :authenticate

     def index
          people = Person.where("age > 30").order("name DESC")

         respond_to do |format|
             format.html
             format.xml { render :xml =>  people.to_xml }
         end
     end
end

And then the translated D code:

class PeopleController : ActionController.Base
{
     Person[] people;

     mixin before_filter!(authenticate);

     void index ()
     {
         people = Person.where("age > 30").order("name DESC");

         respond_to((Format format) {
             format.html;
             format.xml({
                 render(["xml" : people.to_xml]);
             });
         });
     }
}

In D there is no way to call a function in a class declaration like you 
can in Ruby so I guess the closest translation would be the mixin used 
above (maybe one could use "static this"). Again we can see in the D 
translation that the lack of a nice way of passing delegates to a 
function makes the code look uglier. Also the requirements of 
parentheses in function calls and square brackets in aa literals makes 
the code look less appealing in D. (Note, I'm pretty sure that 
activerecord doesn't return a plain Ruby array but instead some other 
class that behaves like an array but I took the freedom of translating 
it into a plain D array).

If we take a look at an enhanced D translation it could look like this:

class PeopleController : ActionController.Base
{
     Person[] people;

     mixin before_filter!(authenticate);

     void index ()
     {
         people = Person.where("age > 30").order("name DESC");

         respond_to(format) {
             format.html;
             format.xml {
                 render(["xml" : people.to_xml]);
             }
         }
     }
}

Here the only change is how delegates are passed to the functions, same 
as in the previous code example.

Conclusion:

D needs a better and nicer looking syntax for passing delegates to 
functions.

Suggestion:

If a function takes a delegate as its last parameter allow the delegate 
literal to be passed outside the parameter list, after the function 
call, and allow to drop the semicolon. Also allow type inference of the 
delegate parameters. Looking like this:

foo(bar) {
     // do something with bar
}

If the function takes other arguments before the delegate I have two 
suggestions, either just have two parameter lists, each in its own pair 
of parentheses:

foo(3, 'a')(bar) {
     // do something with bar
}

Or have two parameter lists in one pair of parentheses seperated by a 
semicolon:

foo(3, 'a' ; bar) {
     // do something with bar
}

I think that the syntax I've used in these examples has previously been 
proposed.

-- 
/Jacob Carlborg
Dec 12 2010
next sibling parent reply foobar <foo bar.com> writes:
I agree with Jacob Carlborg regarding the problem. It would indeed be nice to
have better delegates syntax. But, why are we trying so hard to force the same
syntax that's used for 'regular' function calls? I'm unconvinced that the
suggestions provided are clearer to either the programmer or the compiler. 
We all agree that Ruby has a nice syntax but it too has a _separate_ syntax. 
I therefore suggest to adopt some variant of Ruby's syntax. 
e.g.
foo (a, b) | foo, bar| {
  use(foo, bar);
}

and maybe also: 
collection.each |item| use(item);

in any case, Even though I LOVE Ruby's easiness in this regard, I still feel
that this is low priority for D. I'd also like to request to NOT create many
different syntax variants like delegate vs. lambda vs. proc vs block ... which
add little benefit and lots of unnecessary confusion IMO.
Dec 12 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-12-12 15:25, foobar wrote:

 I agree with Jacob Carlborg regarding the problem. It would indeed be nice to
have better delegates syntax. But, why are we trying so hard to force the same
syntax that's used for 'regular' function calls? I'm unconvinced that the
suggestions provided are clearer to either the programmer or the compiler.
 We all agree that Ruby has a nice syntax but it too has a _separate_ syntax.
 I therefore suggest to adopt some variant of Ruby's syntax.
 e.g.
 foo (a, b) | foo, bar| {
    use(foo, bar);
 }

 and maybe also:
 collection.each |item| use(item);

 in any case, Even though I LOVE Ruby's easiness in this regard, I still feel
that this is low priority for D. I'd also like to request to NOT create many
different syntax variants like delegate vs. lambda vs. proc vs block ... which
add little benefit and lots of unnecessary confusion IMO.


I don't like that syntax, it doesn't feel D.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Jacob Carlborg wrote:

...

 
 If we have a look at the next code example from the talk there is no
 clear and natural way to translate it into D, first the Ruby code:
 
 class PeopleController < ActionController::Base
      before_filter :authenticate
 
      def index
           people = Person.where("age > 30").order("name DESC")
 
          respond_to do |format|
              format.html
              format.xml { render :xml =>  people.to_xml }
          end
      end
 end
 
 And then the translated D code:
 
 class PeopleController : ActionController.Base
 {
      Person[] people;
 
      mixin before_filter!(authenticate);
 
      void index ()
      {
          people = Person.where("age > 30").order("name DESC");
 
          respond_to((Format format) {
              format.html;
              format.xml({
                  render(["xml" : people.to_xml]);
              });
          });
      }
 }


I agree with lambda syntax, iirc the trailing delegate was introduced around 
the time lazy made it into the language. However, D has some features of its 
own that could make for a better translation. 

In rails associative array literals are used as a workaround for the lack of 
named parameters in ruby. You can take advantage of overloading and template 
specialization in D to reduce the need for such a feature, which looks very 
strange anyway in D code. Furthermore, the code block syntax is used in ruby 
everywhere, but in D we also have nested functions, alias template 
parameters and lazy parameters. 

I'm sure a skilled designer could make a much better api than literally 
translating RoR. Perhaps something like this is already better:

class PeopleController 
    : ActionController!( before_filter!authenticate )
{
    People[] people;

    void index ()
    {
        people = Person.where("age > 30").order("name DESC");

        void respond(Format format)
        {
            format.html;
            format.xml( render(people.toXml) );
        }
        
        doResponse( &respond );
    }
}

One thing to consider is that a certain class of errors in D is caught by 
the type system. Even when you don't see static typing as an advantage 
perse, you can't ignore the fact that you have to write unittests for all 
these cases in a dynamic language whereas with static typing you save this 
need.
Dec 12 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-12-12 15:24, Lutger Blijdestijn wrote:

 Jacob Carlborg wrote:

 I agree with lambda syntax, iirc the trailing delegate was introduced around
 the time lazy made it into the language. However, D has some features of its
 own that could make for a better translation.

 In rails associative array literals are used as a workaround for the lack of
 named parameters in ruby. You can take advantage of overloading and template
 specialization in D to reduce the need for such a feature, which looks very
 strange anyway in D code. Furthermore, the code block syntax is used in ruby
 everywhere, but in D we also have nested functions, alias template
 parameters and lazy parameters.

 I'm sure a skilled designer could make a much better api than literally
 translating RoR. Perhaps something like this is already better:

 class PeopleController
      : ActionController!( before_filter!authenticate )
 {
      People[] people;

      void index ()
      {
          people = Person.where("age>  30").order("name DESC");

          void respond(Format format)
          {
              format.html;
              format.xml( render(people.toXml) );
          }

          doResponse(&respond );
      }
 }

 One thing to consider is that a certain class of errors in D is caught by
 the type system. Even when you don't see static typing as an advantage
 perse, you can't ignore the fact that you have to write unittests for all
 these cases in a dynamic language whereas with static typing you save this
 need.


Yes, that's an other way to translate the Ruby code but I tried to stay 
as close to the Ruby code as possible. If you want to overload render 
(as I'm guessing you do in that example) on different types, toXml needs 
to return some kind of structure and not a string as it's returned in Ruby.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
We already have a D block syntax!

=====

void myfun(void delegate() lol) {
        lol();
}

void main() {
        myfun = {
                assert(0, "lol");
        };
}

======

Totally compiles. :-P

It works with delegate arguments too!

========

void myfun(void delegate(string) lol) {
        lol("say it ");
}

void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
}
==========

Whoa.



(note that while I'm only a little serious here - that actually
looks fine to me - I don't think the language needs a change
here. }); doesn't bother me one bit.)
Dec 12 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ie2sv2$2thb$1 digitalmars.com...

 We already have a D block syntax!

 =====

 void myfun(void delegate() lol) {
        lol();
 }

 void main() {
        myfun = {
                assert(0, "lol");
        };
 }

 ======

 Totally compiles. :-P

 It works with delegate arguments too!

 ========

 void myfun(void delegate(string) lol) {
        lol("say it ");
 }

 void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
 }
 ==========

 Whoa.



 (note that while I'm only a little serious here - that actually
 looks fine to me - I don't think the language needs a change
 here. }); doesn't bother me one bit.)


I'm sure that's going to disappear when D's properties get implemented as 
intended.
Dec 12 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ie34p4$dgk$1 digitalmars.com...

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:ie2sv2$2thb$1 digitalmars.com...

 We already have a D block syntax!

 =====

 void myfun(void delegate() lol) {
        lol();
 }

 void main() {
        myfun = {
                assert(0, "lol");
        };
 }

 ======

 Totally compiles. :-P

 It works with delegate arguments too!

 ========

 void myfun(void delegate(string) lol) {
        lol("say it ");
 }

 void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
 }
 ==========

 Whoa.



 (note that while I'm only a little serious here - that actually
 looks fine to me - I don't think the language needs a change
 here. }); doesn't bother me one bit.)


 I'm sure that's going to disappear when D's properties get implemented as 
 intended.


And FWIW, it looks like operator-overload-abuse to me.
Dec 12 2010
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Nick Sabalausky wrote:

 And FWIW, it looks like operator-overload-abuse to me.


Probably because that's what it is :)
Dec 12 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-12 19:37, Nick Sabalausky wrote:

 "Nick Sabalausky"<a a.a>  wrote in message
 news:ie34p4$dgk$1 digitalmars.com...

 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:ie2sv2$2thb$1 digitalmars.com...

 We already have a D block syntax!

 =====

 void myfun(void delegate() lol) {
         lol();
 }

 void main() {
         myfun = {
                 assert(0, "lol");
         };
 }

 ======

 Totally compiles. :-P

 It works with delegate arguments too!

 ========

 void myfun(void delegate(string) lol) {
         lol("say it ");
 }

 void main() {
         myfun = (string what) {
                 assert(0, what ~ " lol");
         };
 }
 ==========

 Whoa.



 (note that while I'm only a little serious here - that actually
 looks fine to me - I don't think the language needs a change
 here. }); doesn't bother me one bit.)


 I'm sure that's going to disappear when D's properties get implemented as
 intended.


 And FWIW, it looks like operator-overload-abuse to me.


This is operator overload abuse:

myfun in (string what) {
     assert(0, what ~ " lol")
};

"myfun" would return a struct that has defined an opIn method.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/12/10 12:36 PM, Nick Sabalausky wrote:

 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:ie2sv2$2thb$1 digitalmars.com...

 We already have a D block syntax!

 =====

 void myfun(void delegate() lol) {
         lol();
 }

 void main() {
         myfun = {
                 assert(0, "lol");
         };
 }

 ======

 Totally compiles. :-P

 It works with delegate arguments too!

 ========

 void myfun(void delegate(string) lol) {
         lol("say it ");
 }

 void main() {
         myfun = (string what) {
                 assert(0, what ~ " lol");
         };
 }
 ==========

 Whoa.



 (note that while I'm only a little serious here - that actually
 looks fine to me - I don't think the language needs a change
 here. }); doesn't bother me one bit.)


 I'm sure that's going to disappear when D's properties get implemented as
 intended.


Handling control flow inside the delegate (break, continue, return) adds 
certain complications. Nothing impossible, but they do erode the 
simplicity of the rewrite.

Andrei
Dec 12 2010
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Nick Sabalausky <a a.a> wrote:


 void myfun(void delegate(string) lol) {
        lol("say it ");
 }

 void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
 }
 ========


 I'm sure that's going to disappear when D's properties get implemented as
 intended.


I'm not. Consider:

 property void myfun(void delegate(string) lol) {
        lol("say it ");
}

void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
}


-- 
Simen
Dec 12 2010
parent "Nick Sabalausky" <a a.a> writes:
"Simen kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.vnl77cjyvxi10f biotronic-pc.lan...

 Nick Sabalausky <a a.a> wrote:


 void myfun(void delegate(string) lol) {
        lol("say it ");
 }

 void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
 }
 ========


 I'm sure that's going to disappear when D's properties get implemented as
 intended.


 I'm not. Consider:

  property void myfun(void delegate(string) lol) {
        lol("say it ");
 }

 void main() {
        myfun = (string what) {
                assert(0, what ~ " lol");
        };
 }


Oh yea, a getter. Of course. I see now.
Dec 12 2010
prev sibling next sibling parent reply so <so so.do> writes:
 If we take a look at the very first code example from the talk it looks  
 like this:

 account.people.each do |person|
      puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
      writeln(person.name);


Am i alone thinking D one better here?


 If we have a look at the next code example from the talk there is no  
 clear and natural way to translate it into D, first the Ruby code:

 class PeopleController < ActionController::Base
      before_filter :authenticate

      def index
           people = Person.where("age > 30").order("name DESC")

          respond_to do |format|
              format.html
              format.xml { render :xml =>  people.to_xml }
          end
      end
 end

 And then the translated D code:

 class PeopleController : ActionController.Base
 {
      Person[] people;

      mixin before_filter!(authenticate);

      void index ()
      {
          people = Person.where("age > 30").order("name DESC");

          respond_to((Format format) {
              format.html;
              format.xml({
                  render(["xml" : people.to_xml]);
              });
          });
      }
 }

 class PeopleController : ActionController.Base
 {
      Person[] people;

      mixin before_filter!(authenticate);

      void index ()
      {
          people = Person.where("age > 30").order("name DESC");

          respond_to(format) {
              format.html;
              format.xml {
                  render(["xml" : people.to_xml]);
              }
          }
      }
 }


D here could use some help at respond_to, but overall i still prefer D way.
Maybe it is just me, i like flexibility of C like languages, and D  
examples here also adds beauty to it.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 12 2010
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
so wrote:

 Am i alone thinking D one better here?


No, I find foreach to be significantly better than the ruby
blocks too. I recently argued on the gentoo forums that
they are virtually equivalent too:


opApply is implemented with a delegate!
Dec 12 2010
next sibling parent reply foobar <foo bar.com> writes:
Adam D. Ruppe Wrote:


 so wrote:

 Am i alone thinking D one better here?


 
 No, I find foreach to be significantly better than the ruby
 blocks too. I recently argued on the gentoo forums that
 they are virtually equivalent too:

 
 opApply is implemented with a delegate!


Exactly. D basically re-writes foreach with opApply into the Ruby version which
is why Ruby is *BETTER*.
foreach to me is a redundant obfuscation.
Dec 12 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
foobar wrote:

 D basically re-writes foreach with opApply into the ruby version


which is why Ruby is *BETTER*

You missed the point: there is no "Ruby version". They are the
same thing.


 foreach to me is a redundant obfuscation


How can it be redundant? It's got the same elements the same
number of times.


rofl.copter.each |lol|
    spam
end


foreach(lol; rofl.copter)
    spam


Same elements, just reordered.


I don't know about the each() method itself. I've never written
one, but I suspect it is virtually identical to opApply too.
Dec 12 2010
next sibling parent reply foobar <foo bar.com> writes:
Adam D. Ruppe Wrote:


 foobar wrote:

 D basically re-writes foreach with opApply into the ruby version


 which is why Ruby is *BETTER*
 
 You missed the point: there is no "Ruby version". They are the
 same thing.
 


By "ruby version" I meant the syntax. I agreed already that they are
implemented the same. 


 foreach to me is a redundant obfuscation


 
 How can it be redundant? It's got the same elements the same
 number of times.
 


incorrect. The difference is that D adds "special" syntax for this whereas it's
just a plain method in Ruby. By calling opApply directly you get the direct
"ruby version" without the redundant use of a keyword + compiler
transformation. 


 
 rofl.copter.each |lol|
     spam
 end
 
 
 foreach(lol; rofl.copter)
     spam
 
 
 Same elements, just reordered.
 
 
 I don't know about the each() method itself. I've never written
 one, but I suspect it is virtually identical to opApply too.


opApply *is* the same thing as Ruby's each method.
Dec 12 2010
parent Stephan Soller <stephan.soller helionweb.de> writes:
On 12.12.2010 20:44, foobar wrote:

 Adam D. Ruppe Wrote:


 foobar wrote:

 D basically re-writes foreach with opApply into the ruby version


 which is why Ruby is *BETTER*

 You missed the point: there is no "Ruby version". They are the
 same thing.


 By "ruby version" I meant the syntax. I agreed already that they are
implemented the same.


 foreach to me is a redundant obfuscation


 How can it be redundant? It's got the same elements the same
 number of times.


 incorrect. The difference is that D adds "special" syntax for this whereas
it's just a plain method in Ruby. By calling opApply directly you get the
direct "ruby version" without the redundant use of a keyword + compiler
transformation.


 rofl.copter.each |lol|
      spam
 end


 foreach(lol; rofl.copter)
      spam


 Same elements, just reordered.


 I don't know about the each() method itself. I've never written
 one, but I suspect it is virtually identical to opApply too.


 opApply *is* the same thing as Ruby's each method.


Just for the sake of correctness: Ruby too has a for-like loop that gets 
rewritten to the block/delegate version.

	for lol in rofl.copter
		spam
	end

This gets rewritten to

	rofl.copter.each do |lol|
		spam
	end

As far as I know this is a construct for ease transition from C to Ruby 
but is not used very much. Blocks are used very often in Ruby so using a 
for-loop is kind of inconsistent style.

Happy programming
Stephan Soller
Dec 13 2010
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/12/2010 02:03 PM, Adam D. Ruppe wrote:

 foobar wrote:

 D basically re-writes foreach with opApply into the ruby version


 which is why Ruby is *BETTER*

 You missed the point: there is no "Ruby version". They are the
 same thing.


 foreach to me is a redundant obfuscation


 How can it be redundant? It's got the same elements the same
 number of times.


 rofl.copter.each |lol|
      spam
 end


 foreach(lol; rofl.copter)
      spam


 Same elements, just reordered.


 I don't know about the each() method itself. I've never written
 one, but I suspect it is virtually identical to opApply too.


Similar. In ruby you have the yield keyword. Here's the D example:

class Foo
{
     uint array[2];

     int opApply(int delegate(ref uint) dg)
     {   int result = 0;

	for (int i = 0; i < array.length; i++)
	{
	    result = dg(array[i]);
	    if (result)
		break;
	}
	return result;
     }
}

Here's the same code written in ruby

class Foo
   def each
     yield  array[0]
     yield  array[1]
   end
end

So pretty similar, right? :-P

D should provide a yield keyword that basically rewrites the body of the 
method into the first code. What's that "if (result) break;"? That's 
showing the implementation of foreach. Why do I have to rememebr the 
result of dg? What's that? What if I forget it? I just want to yield two 
elements :-(
Dec 12 2010
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Ary Borenszweig wrote:

 D should provide a yield keyword that basically
 rewrites the body of the method into the first code.


Don't need to change the language for that.

=========

string yield(string what) {
  return `if(auto result = dg(`~what~`)) return result;`;
}

class Foo
{
    uint array[2];

    int opApply(int delegate(ref uint) dg) {
         mixin(yield("array[0]"));
         mixin(yield("array[1]"));

	return 0;
    }
}
=========

Compiles and runs as expected, on today's D.
Dec 12 2010
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/13/2010 12:23 AM, Adam D. Ruppe wrote:

 Ary Borenszweig wrote:

 D should provide a yield keyword that basically
 rewrites the body of the method into the first code.


 Don't need to change the language for that.

 =========

 string yield(string what) {
    return `if(auto result = dg(`~what~`)) return result;`;
 }

 class Foo
 {
      uint array[2];

      int opApply(int delegate(ref uint) dg) {
           mixin(yield("array[0]"));
           mixin(yield("array[1]"));

 	return 0;
      }
 }
 =========

 Compiles and runs as expected, on today's D.


Cool!!

But it's kind of too much what you have to write. I like that you can do 
it without modifying the language, but sometimes it's better to have it 
directly in the language if it's you are going to use it often and it's 
useful. Remembering to put mixin() and enclosing the expression in a 
string is not very nice to the eyes.

I really like string mixins as they are inserted as is into the code, so 
there's no overhead in the call. It would be really cool if you could 
mark a function as being a string mixin, and then to do:

 mixin
string yield(string what) {
   return `if(auto result = dg(`~what~`)) return result;`;
}

class Foo
{
     uint array[2];

     int opApply(int delegate(ref uint) dg) {
          yield(array[0]);
          yield(array[1]);

	return 0;
     }
}

So that basically would work like this:

-  mixin tells the compiler it's a string mixin because the function 
returns a string.
- In the semantic analysis the compiler needs to invoke yield(array[0]). 
It can see that yield is marked as  mixin, so instead of applying 
semantic analysis to array[0] it just converts it back to a string (I 
remember there exists such thing in DMD's source code) and then passes 
it to yield.

No more strings for string mixins! You get nice colors in your editor. 
You get autocomplete in those that support it.

Ideas?
Dec 13 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:ie4ui8$174a$1 digitalmars.com...

 On 12/13/2010 12:23 AM, Adam D. Ruppe wrote:

 Ary Borenszweig wrote:

 D should provide a yield keyword that basically
 rewrites the body of the method into the first code.


 Don't need to change the language for that.

 =========

 string yield(string what) {
    return `if(auto result = dg(`~what~`)) return result;`;
 }

 class Foo
 {
      uint array[2];

      int opApply(int delegate(ref uint) dg) {
           mixin(yield("array[0]"));
           mixin(yield("array[1]"));

 return 0;
      }
 }
 =========

 Compiles and runs as expected, on today's D.


 Cool!!

 But it's kind of too much what you have to write. I like that you can do 
 it without modifying the language, but sometimes it's better to have it 
 directly in the language if it's you are going to use it often and it's 
 useful. Remembering to put mixin() and enclosing the expression in a 
 string is not very nice to the eyes.

 I really like string mixins as they are inserted as is into the code, so 
 there's no overhead in the call. It would be really cool if you could mark 
 a function as being a string mixin, and then to do:

  mixin
 string yield(string what) {
   return `if(auto result = dg(`~what~`)) return result;`;
 }

 class Foo
 {
     uint array[2];

     int opApply(int delegate(ref uint) dg) {
          yield(array[0]);
          yield(array[1]);

 return 0;
     }
 }

 So that basically would work like this:

 -  mixin tells the compiler it's a string mixin because the function 
 returns a string.


I've suggested that before, but it only got applied to template mixins which 
IMO isn't nearly as useful or desireable as doing the same for string 
mixins. I still really want to see it.


 - In the semantic analysis the compiler needs to invoke yield(array[0]). 
 It can see that yield is marked as  mixin, so instead of applying semantic 
 analysis to array[0] it just converts it back to a string (I remember 
 there exists such thing in DMD's source code) and then passes it to yield.


The ability the get a string representation of the argument passd by the 
caller would definitely be a great thing to have. Although I think it would 
be better placed in __traits or the proposed magic "meta" namespace, etc. 
That way any function,  mixin or not, can use it or not use it whenever it 
wants, and it wouldn't add any potentially confusing semantic complexity.
Dec 13 2010
parent spir <denis.spir gmail.com> writes:
On Mon, 13 Dec 2010 12:12:27 -0500
"Nick Sabalausky" <a a.a> wrote:


 The ability the get a string representation of the argument passd by the=


=20

 caller would definitely be a great thing to have. Although I think it wou=


ld=20

 be better placed in __traits or the proposed magic "meta" namespace, etc.=


=20

 That way any function,  mixin or not, can use it or not use it whenever i=


t=20

 wants, and it wouldn't add any potentially confusing semantic complexity.


I like this point of view very much. Esp. the 'meta' namespace that would c=
learly separate ordinary coding from sorcery.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 13 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-13 12:01, Ary Borenszweig wrote:

 On 12/13/2010 12:23 AM, Adam D. Ruppe wrote:

 Ary Borenszweig wrote:

 D should provide a yield keyword that basically
 rewrites the body of the method into the first code.


 Don't need to change the language for that.

 =========

 string yield(string what) {
 return `if(auto result = dg(`~what~`)) return result;`;
 }

 class Foo
 {
 uint array[2];

 int opApply(int delegate(ref uint) dg) {
 mixin(yield("array[0]"));
 mixin(yield("array[1]"));

 return 0;
 }
 }
 =========

 Compiles and runs as expected, on today's D.


 Cool!!

 But it's kind of too much what you have to write. I like that you can do
 it without modifying the language, but sometimes it's better to have it
 directly in the language if it's you are going to use it often and it's
 useful. Remembering to put mixin() and enclosing the expression in a
 string is not very nice to the eyes.

 I really like string mixins as they are inserted as is into the code, so
 there's no overhead in the call. It would be really cool if you could
 mark a function as being a string mixin, and then to do:

  mixin
 string yield(string what) {
 return `if(auto result = dg(`~what~`)) return result;`;
 }

 class Foo
 {
 uint array[2];

 int opApply(int delegate(ref uint) dg) {
 yield(array[0]);
 yield(array[1]);

 return 0;
 }
 }

 So that basically would work like this:

 -  mixin tells the compiler it's a string mixin because the function
 returns a string.
 - In the semantic analysis the compiler needs to invoke yield(array[0]).
 It can see that yield is marked as  mixin, so instead of applying
 semantic analysis to array[0] it just converts it back to a string (I
 remember there exists such thing in DMD's source code) and then passes
 it to yield.

 No more strings for string mixins! You get nice colors in your editor.
 You get autocomplete in those that support it.

 Ideas?


I actually have similar idea that will get rid of the string completely. 
I'll make a separate post about this.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-13 04:23, Adam D. Ruppe wrote:

 Ary Borenszweig wrote:

 D should provide a yield keyword that basically
 rewrites the body of the method into the first code.


 Don't need to change the language for that.

 =========

 string yield(string what) {
    return `if(auto result = dg(`~what~`)) return result;`;
 }

 class Foo
 {
      uint array[2];

      int opApply(int delegate(ref uint) dg) {
           mixin(yield("array[0]"));
           mixin(yield("array[1]"));

 	return 0;
      }
 }
 =========

 Compiles and runs as expected, on today's D.


This is just ugly.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-12 18:03, Adam D. Ruppe wrote:

 foobar wrote:

 D basically re-writes foreach with opApply into the ruby version


 which is why Ruby is *BETTER*

 You missed the point: there is no "Ruby version". They are the
 same thing.


 foreach to me is a redundant obfuscation


 How can it be redundant? It's got the same elements the same
 number of times.


 rofl.copter.each |lol|
      spam
 end


 foreach(lol; rofl.copter)
      spam


 Same elements, just reordered.


 I don't know about the each() method itself. I've never written
 one, but I suspect it is virtually identical to opApply too.


It's pretty similar. Say I reimplement the "each" method of the Array 
class then it could look like this:

class Array
     def each
         i = 0

         while i < length
             yield self[i]
             i += 1
         end
     end
end

"yield" will call the block that is passed to the method call.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Adam D.  Ruppe wrote:


 so wrote:

 Am i alone thinking D one better here?


 
 No, I find foreach to be significantly better than the ruby
 blocks too. I recently argued on the gentoo forums that
 they are virtually equivalent too:

 
 opApply is implemented with a delegate!


You can't compare foreach to code blocks. foreach is just one function that 
enjoys syntactic sugar, whereas code block syntax is available for every 
function in ruby.
Dec 12 2010
parent Adam D. Ruppe <destructionator gmail.com> writes:
Lutger Blijdestijn wrote:

 You can't compare freach to code blocks [..] whereas code block


syntax is available to every function in ruby.

Meh, foreach covers the majority of its use anyway, and
plain delegate syntax works just as well for the rest of it.
I can't get worked up over typing parenthesis.

...Or you could abuse the property syntax to get rid of
them too!
Dec 12 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Sun, 12 Dec 2010 16:29:29 +0000 (UTC)
"Adam D. Ruppe" <destructionator gmail.com> wrote:


 so wrote:

 Am i alone thinking D one better here?


=20
 No, I find foreach to be significantly better than the ruby
 blocks too. I recently argued on the gentoo forums that
 they are virtually equivalent too:

=20
 opApply is implemented with a delegate!


I agree as well. Foreach is superior (for a static language, at least). Rub=
y-like procs and blocks would bring about nothing to D and introduce a lot =
od syntactic (and mental ;-) mess.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 12 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-12 17:29, Adam D. Ruppe wrote:

 so wrote:

 Am i alone thinking D one better here?


 No, I find foreach to be significantly better than the ruby
 blocks too. I recently argued on the gentoo forums that
 they are virtually equivalent too:


 opApply is implemented with a delegate!


As I replied to so, there are other cases than iteration which could 
benefit for a better delegate syntax.

-- 
/Jacob Carlborg
Dec 13 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
so <so so.do> wrote:


 If we take a look at the very first code example from the talk it looks  
 like this:

 account.people.each do |person|
      puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
      writeln(person.name);


 Am i alone thinking D one better here?


Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
English. Had foreach used 'in' instead of the semicolon, only
punctuation and 'ln' would be off.

-- 
Simen
Dec 12 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Simen kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.vnl1katxvxi10f biotronic-pc.lan...

 so <so so.do> wrote:


 If we take a look at the very first code example from the talk it looks 
 like this:

 account.people.each do |person|
      puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
      writeln(person.name);


 Am i alone thinking D one better here?


 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


Unless I'm mistaken, I think I heard somewhere that the original creator of 
Ruby is Japanese. Japanese grammar puts prepositions at the end of 
prepositional phrases and verbs at the end of predicates, so I'm guessing 
that's why Ruby ended up that way. Although Ruby's function calls are still 
"function/verb first, then params/nouns", so I dunno.
Dec 12 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 12 Dec 2010 19:34:10 +0100, Nick Sabalausky <a a.a> wrote:


 "Simen kjaeraas" <simen.kjaras gmail.com> wrote in message
 news:op.vnl1katxvxi10f biotronic-pc.lan...

 so <so so.do> wrote:


 If we take a look at the very first code example from the talk it  =









 looks
 like this:

 account.people.each do |person|
      puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
      writeln(person.name);


 Am i alone thinking D one better here?


 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


 Unless I'm mistaken, I think I heard somewhere that the original creat=


or  =


 of
 Ruby is Japanese. Japanese grammar puts prepositions at the end of
 prepositional phrases and verbs at the end of predicates, so I'm guess=


ing

 that's why Ruby ended up that way. Although Ruby's function calls are =


 =


 still
 "function/verb first, then params/nouns", so I dunno.


Asking google translate ("for each (person) in (account.people) do  =

(writeln( person.name ))"):

person =E3=81=AE=E5=90=84 account.people =E3=81=AF=E3=80=81writeln( pers=
on.name ); =E3=82=92=E8=A1=8C=E3=81=86=E3=81=9F=E3=82=81=E3=81=AE

-- =

Simen
Dec 12 2010
prev sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 12.12.2010 18:01, Simen kjaeraas wrote:

 so <so so.do> wrote:


 If we take a look at the very first code example from the talk it
 looks like this:

 account.people.each do |person|
 puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
 writeln(person.name);


 Am i alone thinking D one better here?


 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


Unfortunately I have to disagree here. If you have well written Ruby 
code (like Ruby on Rails usually provides) it can usually be read like 
plain English. That's the reason why I dropped writing documentation 
comments for Ruby code: it's just redundant.

I'm not at home so I can't post a good example. However I once built a 
website in Ruby on Rails together with another person responsible for 
the content. This person had no programming experience what soever. 
Because I hadn't completed some backend stuff the development version of 
the website threw an exception and the code of the action was displayed. 
I was curious and asked here if she was able to understand what these 
lines do. She was actually able to exactly tell me what the code was 
doing... without ever learning about programming. I doubt this would 
have been possible with D code.

Happy programming
Stephan Soller
Dec 13 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Stephan Soller <stephan.soller helionweb.de> wrote:


 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


 Unfortunately I have to disagree here. If you have well written Ruby  
 code (like Ruby on Rails usually provides) it can usually be read like  
 plain English. That's the reason why I dropped writing documentation  
 comments for Ruby code: it's just redundant.


I'm only commenting on the above code, not Ruby in general.


-- 
Simen
Dec 13 2010
parent Stephan Soller <stephan.soller helionweb.de> writes:
On 13.12.2010 12:42, Simen kjaeraas wrote:

 Stephan Soller <stephan.soller helionweb.de> wrote:


 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


 Unfortunately I have to disagree here. If you have well written Ruby
 code (like Ruby on Rails usually provides) it can usually be read like
 plain English. That's the reason why I dropped writing documentation
 comments for Ruby code: it's just redundant.


 I'm only commenting on the above code, not Ruby in general.


Sorry, I got that wrong then.
Dec 13 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:ie4srq$138c$1 digitalmars.com...

 On 12.12.2010 18:01, Simen kjaeraas wrote:

 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


 Unfortunately I have to disagree here. If you have well written Ruby code 
 (like Ruby on Rails usually provides) it can usually be read like plain 
 English. That's the reason why I dropped writing documentation comments 
 for Ruby code: it's just redundant.


This common Ruby idiom is totally Yoda-speak to me:

    doSomething unless condition?

The order-of-execution is completely backwards. Plus the "unless" instead of 
"if" makes my mind pause to process an "inverted-context" because *now* 
seeing a "blah" really means "not", and a "!blah" no longer means "not".

Yea, "(action) unless (condition)" is fairly normal English, but code has 
different requirements than normal speech. And besides, it's also perfectly 
normal, easily-understandable English to say "unless (condition), (action)", 
or even a negated if: "if you don't have x, do y". In fact I'd argue the 
English "if you don't have X, do Y" is much easier to understand than "do B 
unless you have C".

With normal English, it's easy enough to hear "do this", and then 
appropriately modify it in your head when you hear it followed by "unless 
that". This is largely because instructions in normal English tend to be 
*much* simpler than instructions in code. With code, there's so many other 
instructions to consider that that extra little mental work of modifying 
something you already processed suddenly makes a difference. But if you see 
something start with the modifier (the condition, in this case) then your 
mind automatically knows it's still an incomplete thought and doesn't do a 
premature "commit". At least that's how my (twisted?) mind works.

Also, Ruby reading like English might be part of why I'm *not* quite won 
over by Ruby's syntax: I'm a native English speaker and I still think 
English makes no sense!
Dec 13 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/13/10 11:39 AM, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:ie4srq$138c$1 digitalmars.com...

 On 12.12.2010 18:01, Simen kjaeraas wrote:

 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


 Unfortunately I have to disagree here. If you have well written Ruby code
 (like Ruby on Rails usually provides) it can usually be read like plain
 English. That's the reason why I dropped writing documentation comments
 for Ruby code: it's just redundant.


 This common Ruby idiom is totally Yoda-speak to me:

      doSomething unless condition?

 The order-of-execution is completely backwards. Plus the "unless" instead of
 "if" makes my mind pause to process an "inverted-context" because *now*
 seeing a "blah" really means "not", and a "!blah" no longer means "not".


Perl has had a long time to experiment with this, and at least some of 
its dominant coding standards unrecommend use of trailing conditions.

Andrei
Dec 13 2010
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
It's not to be used everywhere, but in many cases it makes the code more
readable.
Compare

str = some_string
if (str.start_with?('foo')) str = str[3 .. -1]
str = str.downcase

with this:

str = some_string
str = str[3 .. -1] if (str.start_with?('foo'))
str = str.downcase

See? You can see the processing on the left and on the right the conditions on
which that processing is applied. Or sometimes you have

return if some_condition_is_met

And sometimes in English (or any other language) you think like that. "Ah, I
should remove this from the string if some condition is met".

It looked very strange and sometimes wrong to me at first...
Dec 13 2010
prev sibling parent Stephan Soller <stephan.soller helionweb.de> writes:
On 13.12.2010 18:39, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:ie4srq$138c$1 digitalmars.com...

 On 12.12.2010 18:01, Simen kjaeraas wrote:

 Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
 English. Had foreach used 'in' instead of the semicolon, only
 punctuation and 'ln' would be off.


 Unfortunately I have to disagree here. If you have well written Ruby code
 (like Ruby on Rails usually provides) it can usually be read like plain
 English. That's the reason why I dropped writing documentation comments
 for Ruby code: it's just redundant.


 This common Ruby idiom is totally Yoda-speak to me:

      doSomething unless condition?

 The order-of-execution is completely backwards. Plus the "unless" instead of
 "if" makes my mind pause to process an "inverted-context" because *now*
 seeing a "blah" really means "not", and a "!blah" no longer means "not".

 Yea, "(action) unless (condition)" is fairly normal English, but code has
 different requirements than normal speech. And besides, it's also perfectly
 normal, easily-understandable English to say "unless (condition), (action)",
 or even a negated if: "if you don't have x, do y". In fact I'd argue the
 English "if you don't have X, do Y" is much easier to understand than "do B
 unless you have C".

 With normal English, it's easy enough to hear "do this", and then
 appropriately modify it in your head when you hear it followed by "unless
 that". This is largely because instructions in normal English tend to be
 *much* simpler than instructions in code. With code, there's so many other
 instructions to consider that that extra little mental work of modifying
 something you already processed suddenly makes a difference. But if you see
 something start with the modifier (the condition, in this case) then your
 mind automatically knows it's still an incomplete thought and doesn't do a
 premature "commit". At least that's how my (twisted?) mind works.

 Also, Ruby reading like English might be part of why I'm *not* quite won
 over by Ruby's syntax: I'm a native English speaker and I still think
 English makes no sense!


I'm not a native English speaker so I can't really judge how much "like 
English" Ruby really is. However I prefer Rubys pseudo English over some 
nested function calls with templates or mixins or something like that. 
Not that code like this is not possible in Ruby but no one actually 
writes such code with it (or I just haven't seen it).

I avoided "unless" for about a year after learning Ruby. It gave me a 
headache translating it to "if not" and converting "or"s to "and"s. But 
over time I fund it useful to write down thoughts without translating 
them to "if". Maybe "(do something) unless (something)" it's only a 
common thought pattern in German, don't know how much it is used in 
English. "unless" is just a small detail and I wouldn't call it a 
revelation but Ruby has many small details that help you to keep your 
thoughts more in the problem domain and write code with less 
"translation" done by the brain. It _feels_ very pleasant over time, 
sometimes even fun. But I don't think this is something a talk or 
presentation can convey. One just has to use Ruby for well suited 
problems for some time.

Happy programming
Stephan Soller
Dec 14 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-12 17:22, so wrote:

 If we take a look at the very first code example from the talk it
 looks like this:

 account.people.each do |person|
 puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
 writeln(person.name);


 Am i alone thinking D one better here?


No, probably not. In this case I think the D syntax is just as good or 
better as the Ruby syntax but there are other cases than iteration that 
can use a better delegate syntax. Just look at Scala, one could use the 
delegate syntax to create, what it looks like, new control structures 
like "unless" (Ruby), "receive" (Scala), "loop" (Ruby, Scala) and so on.


 If we have a look at the next code example from the talk there is no
 clear and natural way to translate it into D, first the Ruby code:

 class PeopleController < ActionController::Base
 before_filter :authenticate

 def index
  people = Person.where("age > 30").order("name DESC")

 respond_to do |format|
 format.html
 format.xml { render :xml =>  people.to_xml }
 end
 end
 end

 And then the translated D code:

 class PeopleController : ActionController.Base
 {
 Person[] people;

 mixin before_filter!(authenticate);

 void index ()
 {
 people = Person.where("age > 30").order("name DESC");

 respond_to((Format format) {
 format.html;
 format.xml({
 render(["xml" : people.to_xml]);
 });
 });
 }
 }

 class PeopleController : ActionController.Base
 {
 Person[] people;

 mixin before_filter!(authenticate);

 void index ()
 {
 people = Person.where("age > 30").order("name DESC");

 respond_to(format) {
 format.html;
 format.xml {
 render(["xml" : people.to_xml]);
 }
 }
 }
 }


 D here could use some help at respond_to, but overall i still prefer D way.
 Maybe it is just me, i like flexibility of C like languages, and D
 examples here also adds beauty to it.



-- 
/Jacob Carlborg
Dec 13 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/12/10 6:44 AM, Jacob Carlborg wrote:
[snip]

 Conclusion:

 D needs a better and nicer looking syntax for passing delegates to
 functions.

 Suggestion:

 If a function takes a delegate as its last parameter allow the delegate
 literal to be passed outside the parameter list, after the function
 call, and allow to drop the semicolon. Also allow type inference of the
 delegate parameters. Looking like this:

 foo(bar) {
 // do something with bar
 }

 If the function takes other arguments before the delegate I have two
 suggestions, either just have two parameter lists, each in its own pair
 of parentheses:

 foo(3, 'a')(bar) {
 // do something with bar
 }

 Or have two parameter lists in one pair of parentheses seperated by a
 semicolon:

 foo(3, 'a' ; bar) {
 // do something with bar
 }

 I think that the syntax I've used in these examples has previously been
 proposed.


Yah, it's been discussed a couple of times in the past. Both Walter and 
myself are favorable to finding a good, simple lowering that improves 
syntax without adding burden to the person who learns the language.

By the way, lowerings are great. Defining features as lowerings is a 
huge win in language definition, ease of understanding, and correctness 
of implementation. Features that have been implemented through lowering 
have had very few bugs - e.g. scope() and the new operator overloading, 
which was only a week's work.

Getting back to finding a good lowering, consider:

foreach (a, b ; c) stmt

A Ruby syntactic equivalent that clarifies what belongs to the block and 
what belongs to the invoker of the block is:

c.each do |a, b|
   stmt
end

So a and b are passed to the block and each is a method of c (or more 
general, each is a function called taking c as an argument). Going now 
back to D, we can imagine the following lowering:

fun (a, b ; c) stmt

=>

fun(c, (a, b) { stmt })

This could and should be generalized for more parameters, which I'm sure 
is very useful:

fun (a, b ; c, d) stmt

=>

fun(c, d, (a, b) { stmt })

Of course "fun" could be actually "obj.method".

With this we have a compelling syntax that has semantics obtained via 
lowering.


Andrei
Dec 12 2010
next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:


 On 12/12/10 6:44 AM, Jacob Carlborg wrote:
 [snip]

 Conclusion:

 D needs a better and nicer looking syntax for passing delegates to
 functions.

 Suggestion:

 If a function takes a delegate as its last parameter allow the delegate
 literal to be passed outside the parameter list, after the function
 call, and allow to drop the semicolon. Also allow type inference of the
 delegate parameters. Looking like this:

 foo(bar) {
 // do something with bar
 }

 If the function takes other arguments before the delegate I have two
 suggestions, either just have two parameter lists, each in its own pair
 of parentheses:

 foo(3, 'a')(bar) {
 // do something with bar
 }

 Or have two parameter lists in one pair of parentheses seperated by a
 semicolon:

 foo(3, 'a' ; bar) {
 // do something with bar
 }

 I think that the syntax I've used in these examples has previously been
 proposed.


 
 Yah, it's been discussed a couple of times in the past. Both Walter and
 myself are favorable to finding a good, simple lowering that improves
 syntax without adding burden to the person who learns the language.
 
 By the way, lowerings are great. Defining features as lowerings is a
 huge win in language definition, ease of understanding, and correctness
 of implementation. Features that have been implemented through lowering
 have had very few bugs - e.g. scope() and the new operator overloading,
 which was only a week's work.
 
 Getting back to finding a good lowering, consider:
 
 foreach (a, b ; c) stmt
 
 A Ruby syntactic equivalent that clarifies what belongs to the block and
 what belongs to the invoker of the block is:
 
 c.each do |a, b|
    stmt
 end
 
 So a and b are passed to the block and each is a method of c (or more
 general, each is a function called taking c as an argument). Going now
 back to D, we can imagine the following lowering:
 
 fun (a, b ; c) stmt
 
 =>
 
 fun(c, (a, b) { stmt })
 
 This could and should be generalized for more parameters, which I'm sure
 is very useful:
 
 fun (a, b ; c, d) stmt
 
 =>
 
 fun(c, d, (a, b) { stmt })
 
 Of course "fun" could be actually "obj.method".
 
 With this we have a compelling syntax that has semantics obtained via
 lowering.
 
 
 Andrei


This would be so nice. You could even implement foreach as a library 
function this way.
Dec 12 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })

 This could and should be generalized for more parameters, which I'm sure  
 is very useful:

 fun (a, b ; c, d) stmt

 =>

 fun(c, d, (a, b) { stmt })

 Of course "fun" could be actually "obj.method".

 With this we have a compelling syntax that has semantics obtained via  
 lowering.


This is very nice. UP VOTES!!1


-- 
Simen
Dec 12 2010
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On Sun, 12 Dec 2010 12:23:03 -0600
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 Going now=20
 back to D, we can imagine the following lowering:
=20
 fun (a, b ; c) stmt
=20
 =3D> =20
=20
 fun(c, (a, b) { stmt })


It seems to me that lowering is analog to redefine "shallow" syntax (in fac=
t, syntactic sugar) into a deeper syntax mirroring that actual AST. The syn=
tax tree for foreach/iteration could be written as:

iteration:
	collection: c
	loopVarNames: ['a','b']
	block: stmt

And generalised into:

blockOperation:
	source: c
	loopVarNames: ['a','b']
	block: stmt
where your 'func' is a "block-wise operation". What do you think?

But I do not see in what Ruby-like syntax and point of view are clearer; ac=
tally, I find D far more readable.
And even less what this would bring to D. This is interesting in highly ref=
lexive languages; even more reflexive than Ruby in fact, where one could tw=
eak the block at runtime. But this is not the perspective of D, I guess.


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 12 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 12.12.2010 21:17, spir wrote:

 On Sun, 12 Dec 2010 12:23:03 -0600
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 Going now
 back to D, we can imagine the following lowering:

 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })


 It seems to me that lowering is analog to redefine "shallow" syntax (in fact,
syntactic sugar) into a deeper syntax mirroring that actual AST. The syntax
tree for foreach/iteration could be written as:

 iteration:
 	collection: c
 	loopVarNames: ['a','b']
 	block: stmt

 And generalised into:

 blockOperation:
 	source: c
 	loopVarNames: ['a','b']
 	block: stmt
 where your 'func' is a "block-wise operation". What do you think?

 But I do not see in what Ruby-like syntax and point of view are clearer;
actally, I find D far more readable.
 And even less what this would bring to D. This is interesting in highly
reflexive languages; even more reflexive than Ruby in fact, where one could
tweak the block at runtime. But this is not the perspective of D, I guess.


 Denis
 -- -- -- -- -- -- --
 vit esse estrany ☣

 spir.wikidot.com


I think it's a matter of consistency. In Ruby blocks are used all the 
time for pretty much everything. In D this isn't the case because 
usually templates are used for stuff where blocks are used in Ruby (e.g. 
map, group and find in std.algorithm).

I don't know if it's possible to unify the way to "pass code as an 
argument" in D but that's where Ruby really shines in my opinion: 
consistency in usage.

Happy programming
Stephan Soller
Dec 13 2010
next sibling parent spir <denis.spir gmail.com> writes:
On Mon, 13 Dec 2010 11:50:39 +0100
Stephan Soller <stephan.soller helionweb.de> wrote:


 But I do not see in what Ruby-like syntax and point of view are clearer=




; actally, I find D far more readable.

 And even less what this would bring to D. This is interesting in highly=




 reflexive languages; even more reflexive than Ruby in fact, where one coul=
d tweak the block at runtime. But this is not the perspective of D, I guess.

=20
 I think it's a matter of consistency. In Ruby blocks are used all the=20
 time for pretty much everything. In D this isn't the case because=20
 usually templates are used for stuff where blocks are used in Ruby (e.g.=


=20

 map, group and find in std.algorithm).
=20
 I don't know if it's possible to unify the way to "pass code as an=20
 argument" in D but that's where Ruby really shines in my opinion:=20
 consistency in usage.


Agreed (this fits Ruby, I guess, because it's a dynamic, consistent and ver=
y reflexive language -- and blocks/procs are objects).

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 13 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-13 11:50, Stephan Soller wrote:

 On 12.12.2010 21:17, spir wrote:

 On Sun, 12 Dec 2010 12:23:03 -0600
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:


 Going now
 back to D, we can imagine the following lowering:

 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })


 It seems to me that lowering is analog to redefine "shallow" syntax
 (in fact, syntactic sugar) into a deeper syntax mirroring that actual
 AST. The syntax tree for foreach/iteration could be written as:

 iteration:
 collection: c
 loopVarNames: ['a','b']
 block: stmt

 And generalised into:

 blockOperation:
 source: c
 loopVarNames: ['a','b']
 block: stmt
 where your 'func' is a "block-wise operation". What do you think?

 But I do not see in what Ruby-like syntax and point of view are
 clearer; actally, I find D far more readable.
 And even less what this would bring to D. This is interesting in
 highly reflexive languages; even more reflexive than Ruby in fact,
 where one could tweak the block at runtime. But this is not the
 perspective of D, I guess.


 Denis
 -- -- -- -- -- -- --
 vit esse estrany ☣

 spir.wikidot.com


 I think it's a matter of consistency. In Ruby blocks are used all the
 time for pretty much everything. In D this isn't the case because
 usually templates are used for stuff where blocks are used in Ruby (e.g.
 map, group and find in std.algorithm).


I think that the templates that take a string as a predicate is just an 
ugly hack because D has a too verbose delegate syntax.


 I don't know if it's possible to unify the way to "pass code as an
 argument" in D but that's where Ruby really shines in my opinion:
 consistency in usage.

 Happy programming
 Stephan Soller



-- 
/Jacob Carlborg
Dec 13 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
 I think it's a matter of consistency. In Ruby blocks are used all the
 time for pretty much everything. In D this isn't the case because
 usually templates are used for stuff where blocks are used in Ruby (e.g.
 map, group and find in std.algorithm).


 I think that the templates that take a string as a predicate is just an
 ugly hack because D has a too verbose delegate syntax.


I absolutely agree with that. However I don't have a better idea how to 
write it. Delegate syntax is already fairly compact in D.

For example code as this isn't very uncommon in Ruby:

	[1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}

Of course this is a simplified example. Usually the collection would 
contain some objects and the blocks would filter for a method call (like 
"e.even?"). However I built a small D1 struct that implements a select 
and collect function. With the unified function call synatax for array 
with code should actually work:

	[1, 2, 3, 4, 5].select((int e){ return e > 3; })
		.collect((int e){ return e*e; });

It's already fairly compact. The main overhead is the parameter type and 
the return statement. I don't believe this can be reduced any more 
without breaking consistency of the language.

Delegates are way more verbose in other languages like PHP and 
JavaScript (more or less the same syntax in both languages). Despite 
that it's no problem to use it and in case of jQuery it's used very 
often. I think the main reason why delegates are not used like that in D 
is performance. I'm really not sure about it but I suspect that 
delegates are less effective than code directly generated by a template 
like map!(). I don't know how efficient templates can integrate 
delegates so I just suspect that this is a performance problem.

Happy programming
Stephan Soller
Dec 14 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Stephan Soller <stephan.soller helionweb.de> wrote:


 	[1, 2, 3, 4, 5].select((int e){ return e > 3; })
 		.collect((int e){ return e*e; });

 It's already fairly compact. The main overhead is the parameter type and  
 the return statement. I don't believe this can be reduced any more  
 without breaking consistency of the language.


The delegates can be passed by alias parameter, and then be written
without the parameter type:

 property void bar(alias t)() {
     t(3);
}

void main() {
     bar!((e){writeln(e);});
}


-- 
Simen
Dec 14 2010
parent Stephan Soller <stephan.soller helionweb.de> writes:
On 14.12.2010 19:49, Simen kjaeraas wrote:

 Stephan Soller <stephan.soller helionweb.de> wrote:


 [1, 2, 3, 4, 5].select((int e){ return e > 3; })
 .collect((int e){ return e*e; });

 It's already fairly compact. The main overhead is the parameter type
 and the return statement. I don't believe this can be reduced any more
 without breaking consistency of the language.


 The delegates can be passed by alias parameter, and then be written
 without the parameter type:

  property void bar(alias t)() {
 t(3);
 }

 void main() {
 bar!((e){writeln(e);});
 }


Hm, nice trick, thanks Simen. Looks interesting and more general to use. 
Will try that for my next D project.

Happy programming
Stephan Soller
Dec 15 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-14 19:33, Stephan Soller wrote:

 I think it's a matter of consistency. In Ruby blocks are used all the
 time for pretty much everything. In D this isn't the case because
 usually templates are used for stuff where blocks are used in Ruby (e.g.
 map, group and find in std.algorithm).


 I think that the templates that take a string as a predicate is just an
 ugly hack because D has a too verbose delegate syntax.


 I absolutely agree with that. However I don't have a better idea how to
 write it. Delegate syntax is already fairly compact in D.

 For example code as this isn't very uncommon in Ruby:

 [1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}

 Of course this is a simplified example. Usually the collection would
 contain some objects and the blocks would filter for a method call (like
 "e.even?"). However I built a small D1 struct that implements a select
 and collect function. With the unified function call synatax for array
 with code should actually work:

 [1, 2, 3, 4, 5].select((int e){ return e > 3; })
 .collect((int e){ return e*e; });

 It's already fairly compact. The main overhead is the parameter type and
 the return statement. I don't believe this can be reduced any more
 without breaking consistency of the language.


Probably not, but, for example, Scala allows very compact delegate literals:

Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

Or more verbose:

Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

I'm not 100% sure I that the syntax is correct.


 Delegates are way more verbose in other languages like PHP and
 JavaScript (more or less the same syntax in both languages). Despite
 that it's no problem to use it and in case of jQuery it's used very
 often. I think the main reason why delegates are not used like that in D
 is performance. I'm really not sure about it but I suspect that
 delegates are less effective than code directly generated by a template
 like map!(). I don't know how efficient templates can integrate
 delegates so I just suspect that this is a performance problem.

 Happy programming
 Stephan Soller


PHP has a very verbose delegate syntax with explicit closures, one of 
the many reasons I don't use PHP. JavaScript has quite similar syntax as 
D but the "function" keyword is required, I try to use CoffeeScript 
(compiles to javascript),  which has a lot nicer delegate syntax, as 
often I can.

D(dmd) needs to be able to inline delegates.

-- 
/Jacob Carlborg
Dec 14 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:ie8f5f$o6e$1 digitalmars.com...

 Probably not, but, for example, Scala allows very compact delegate 
 literals:

 Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

 I'm not 100% sure I that the syntax is correct.


I'd be surprised if the first one is correct, because that "collect(_ * _)" 
would seem highly limited (how would you use the same value twice, or use 
just the second value, or use them in reverse order?).


solution to the question of what to do with all the noise of the extra curly 
braces, "return" keyword and trailing semicolon. And given that 1. The => 
isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already 
being used perfectly fine by the existing delegate literal syntax, I can't 
imagine there would be any ambiguity with it in D.

I'd be absolutely in favor of adding that to D. In fact, I'd love to see it 
happen. Just require that the part after "=>" is an expression, accept that 
the more complex delegates that need statements use the existing syntax 
(which should be fine since it's only the single-expression-and-nothing-else 
delegates that are seen as verbose in D), and call it a day.
Dec 14 2010
next sibling parent reply lurker <lurk lurk.net> writes:
Nick Sabalausky Wrote:


 "Jacob Carlborg" <doob me.com> wrote in message 
 news:ie8f5f$o6e$1 digitalmars.com...

 Probably not, but, for example, Scala allows very compact delegate 
 literals:

 Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

 I'm not 100% sure I that the syntax is correct.


 
 I'd be surprised if the first one is correct, because that "collect(_ * _)" 
 would seem highly limited (how would you use the same value twice, or use 
 just the second value, or use them in reverse order?).
 

 solution to the question of what to do with all the noise of the extra curly 
 braces, "return" keyword and trailing semicolon. And given that 1. The => 
 isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already 
 being used perfectly fine by the existing delegate literal syntax, I can't 
 imagine there would be any ambiguity with it in D.
 
 I'd be absolutely in favor of adding that to D. In fact, I'd love to see it 
 happen. Just require that the part after "=>" is an expression, accept that 
 the more complex delegates that need statements use the existing syntax 
 (which should be fine since it's only the single-expression-and-nothing-else 
 delegates that are seen as verbose in D), and call it a day.


=> would make D look like Perl or PHP or Ruby. Statements are more general than
expressions, the D's solution is more general. How much the short new syntax
matters if you need two syntaxes for it?! Would mean 2 function syntaxes, 2
delegate syntaxes. Two things was already complex for users.
Dec 14 2010
parent "Nick Sabalausky" <a a.a> writes:
"lurker" <lurk lurk.net> wrote in message 
news:ie8rji$283s$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "Jacob Carlborg" <doob me.com> wrote in message
 news:ie8f5f$o6e$1 digitalmars.com...

 Probably not, but, for example, Scala allows very compact delegate
 literals:

 Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

 I'm not 100% sure I that the syntax is correct.


 I'd be surprised if the first one is correct, because that "collect(_ * 
 _)"
 would seem highly limited (how would you use the same value twice, or use
 just the second value, or use them in reverse order?).


 solution to the question of what to do with all the noise of the extra 
 curly
 braces, "return" keyword and trailing semicolon. And given that 1. The =>
 isn't currently a valid D token anyway, and 2. The (x) and (x,y) are 
 already
 being used perfectly fine by the existing delegate literal syntax, I 
 can't
 imagine there would be any ambiguity with it in D.

 I'd be absolutely in favor of adding that to D. In fact, I'd love to see 
 it
 happen. Just require that the part after "=>" is an expression, accept 
 that
 the more complex delegates that need statements use the existing syntax
 (which should be fine since it's only the 
 single-expression-and-nothing-else
 delegates that are seen as verbose in D), and call it a day.


 => would make D look like Perl or PHP or Ruby.


If it's added to D, then it would be part of D, and would therefore look 
like D :)


 Statements are more general than expressions, the D's solution is more 
 general. How much the short new syntax matters if you need two syntaxes 
 for it?! Would mean 2 function syntaxes, 2 delegate syntaxes. Two things 
 was already complex for users.



Granted, I'm more in the "provide a variety of tools and let the user 
choose" camp than the "there is one true answer" one.
Dec 14 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-14 22:04, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:ie8f5f$o6e$1 digitalmars.com...

 Probably not, but, for example, Scala allows very compact delegate
 literals:

 Array(1, 2, 3, 4, 5).select(_>  3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) =>  x>  3).collect((x, y) =>  x * y)

 I'm not 100% sure I that the syntax is correct.


 I'd be surprised if the first one is correct, because that "collect(_ * _)"
 would seem highly limited (how would you use the same value twice, or use
 just the second value, or use them in reverse order?).


I guess for anything more complicated you would have to use the => 
syntax. BTW, I just verified that this works:

Array(1, 2, 3, 4, 5).sortWith(_ > _)

You can try it out for yourself at: http://www.simplyscala.com/



 solution to the question of what to do with all the noise of the extra curly
 braces, "return" keyword and trailing semicolon. And given that 1. The =>
 isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already
 being used perfectly fine by the existing delegate literal syntax, I can't
 imagine there would be any ambiguity with it in D.

 I'd be absolutely in favor of adding that to D. In fact, I'd love to see it
 happen. Just require that the part after "=>" is an expression, accept that
 the more complex delegates that need statements use the existing syntax
 (which should be fine since it's only the single-expression-and-nothing-else
 delegates that are seen as verbose in D), and call it a day.


I would also love to have that syntax. I also love the syntax I 
previously suggested in this thread, there are many to choose of.

-- 
/Jacob Carlborg
Dec 15 2010
parent reply retard <re tard.com.invalid> writes:
Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:


 On 2010-12-14 22:04, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:ie8f5f$o6e$1 digitalmars.com...

 Probably not, but, for example, Scala allows very compact delegate
 literals:

 Array(1, 2, 3, 4, 5).select(_>  3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) =>  x>  3).collect((x, y) =>  x * y)

 I'm not 100% sure I that the syntax is correct.


 I'd be surprised if the first one is correct, because that "collect(_ *
 _)" would seem highly limited (how would you use the same value twice,
 or use just the second value, or use them in reverse order?).


 
 I guess for anything more complicated you would have to use the =>
 syntax. BTW, I just verified that this works:
 
 Array(1, 2, 3, 4, 5).sortWith(_ > _)


The first instance of _ (from left to right) is replaced with the first 
element of the parameter tuple, the second with second element, etc.

This is actually very useful since many lambdas only use 1-2 parameters. 
It has its limitations. For example referring to the same parameter 
requires a named parameter or some other hack. Combined with Haskell 
style partial application this allows stuff like:

Array(1, 2, 3, 4, 5).foreach { println }

Array(1, 2, 3, 4, 5).filter(2 <)
Dec 15 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_>  _)


 The first instance of _ (from left to right) is replaced with the first
 element of the parameter tuple, the second with second element, etc.

 This is actually very useful since many lambdas only use 1-2 parameters.
 It has its limitations. For example referring to the same parameter
 requires a named parameter or some other hack. Combined with Haskell
 style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


For short lambdas I prefer Phobos' convention of using "a" and "b", e.g. 
"2 < a" or "a < b". Since it's a string, "_ < _" would have been usable 
with Phobos too but I wouldn't like such a change.

Andrei
Dec 15 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Wed, 15 Dec 2010 16:33:43 -0600, Andrei Alexandrescu wrote:


 On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_>  _)


 The first instance of _ (from left to right) is replaced with the first
 element of the parameter tuple, the second with second element, etc.

 This is actually very useful since many lambdas only use 1-2
 parameters. It has its limitations. For example referring to the same
 parameter requires a named parameter or some other hack. Combined with
 Haskell style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


 
 For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
 "2 < a" or "a < b". Since it's a string, "_ < _" would have been usable
 with Phobos too but I wouldn't like such a change.


I haven't have time to test this (still using D1 + Tango), but these 
magical 'a' and 'b' make me wonder whether there are any namespace 
issues. Can you refer to symbols defined in the current module or in the 
Phobos module the collection function is declared? Do the 'a' and 'b' 
shadow some other instances of 'a' and 'b'?
Dec 15 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/15/10 4:42 PM, retard wrote:

 Wed, 15 Dec 2010 16:33:43 -0600, Andrei Alexandrescu wrote:


 On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_>   _)


 The first instance of _ (from left to right) is replaced with the first
 element of the parameter tuple, the second with second element, etc.

 This is actually very useful since many lambdas only use 1-2
 parameters. It has its limitations. For example referring to the same
 parameter requires a named parameter or some other hack. Combined with
 Haskell style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


 For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
 "2<  a" or "a<  b". Since it's a string, "_<  _" would have been usable
 with Phobos too but I wouldn't like such a change.


 I haven't have time to test this (still using D1 + Tango), but these
 magical 'a' and 'b' make me wonder whether there are any namespace
 issues. Can you refer to symbols defined in the current module or in the
 Phobos module the collection function is declared? Do the 'a' and 'b'
 shadow some other instances of 'a' and 'b'?


There are no hygiene issues, but lookup is limited to the modules 
included in std.functional. That's goes well with the charter of short 
lambdas - I mean, they are short :o).

Andrei
Dec 15 2010
parent retard <re tard.com.invalid> writes:
Wed, 15 Dec 2010 16:47:01 -0600, Andrei Alexandrescu wrote:


 On 12/15/10 4:42 PM, retard wrote:

 Wed, 15 Dec 2010 16:33:43 -0600, Andrei Alexandrescu wrote:


 On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_>   _)


 The first instance of _ (from left to right) is replaced with the
 first element of the parameter tuple, the second with second element,
 etc.

 This is actually very useful since many lambdas only use 1-2
 parameters. It has its limitations. For example referring to the same
 parameter requires a named parameter or some other hack. Combined
 with Haskell style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


 For short lambdas I prefer Phobos' convention of using "a" and "b",
 e.g. "2<  a" or "a<  b". Since it's a string, "_<  _" would have been
 usable with Phobos too but I wouldn't like such a change.


 I haven't have time to test this (still using D1 + Tango), but these
 magical 'a' and 'b' make me wonder whether there are any namespace
 issues. Can you refer to symbols defined in the current module or in
 the Phobos module the collection function is declared? Do the 'a' and
 'b' shadow some other instances of 'a' and 'b'?


 
 There are no hygiene issues, but lookup is limited to the modules
 included in std.functional. That's goes well with the charter of short
 lambdas - I mean, they are short :o).


Ha, that's the thing I was after. Hopefully it's well documented. No need 
to answer, I can check it myself.
Dec 15 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-15 23:33, Andrei Alexandrescu wrote:

 On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_> _)


 The first instance of _ (from left to right) is replaced with the first
 element of the parameter tuple, the second with second element, etc.

 This is actually very useful since many lambdas only use 1-2 parameters.
 It has its limitations. For example referring to the same parameter
 requires a named parameter or some other hack. Combined with Haskell
 style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


 For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
 "2 < a" or "a < b". Since it's a string, "_ < _" would have been usable
 with Phobos too but I wouldn't like such a change.

 Andrei


The point here isn't that we want "a" and "b" to be replaced with "_" 
the point is that we want to get rid of the string and have a shorter 
and less verbose syntax for delegate literals.

-- 
/Jacob Carlborg
Dec 16 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 On 2010-12-15 23:33, Andrei Alexandrescu wrote:

 On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_> _)


 The first instance of _ (from left to right) is replaced with the first
 element of the parameter tuple, the second with second element, etc.

 This is actually very useful since many lambdas only use 1-2 parameters.
 It has its limitations. For example referring to the same parameter
 requires a named parameter or some other hack. Combined with Haskell
 style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


 For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
 "2 < a" or "a < b". Since it's a string, "_ < _" would have been usable
 with Phobos too but I wouldn't like such a change.

 Andrei


 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


I understand. Using strings is witnessing the fact that we couldn't find 
a shorter syntax that didn't have problems. That being said, it's very 
possible there are some great ones, we just couldn't find them.

Andrei
Dec 16 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:iedqos$787$1 digitalmars.com...

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find a 
 shorter syntax that didn't have problems. That being said, it's very 
 possible there are some great ones, we just couldn't find them.




(x, y) =>  x * y

// Lowered to:

(x, y) { return x * y; }

(Maybe that was rejected before due the the weird float operators that are 
now being ditched?)

It wouldn't be used for delegates that involve actual statements (it would 
be expression-only), but that fits with the whole point of a lambda 
expression.

Also, unlike the strings it doesn't suffer the problem of being evaluated in 
the wrong scope. For instance I think it's perfctly sensible to want a short 
lambda to be able to do something like this (pardon me if I have the syntax 
for map() wrong):

int foo(int x) { ... }
collection.map!"foo(a) + 3"();
// Or if you want proper syntax highlighting:
collection.map!q{ foo(a) + 3 }();

I think that totally fits the charter of short lambdas, but the strings just 
can't do it (at least not without turning map() into something that needs to 


int foo(int x) { ... }
collection.map!((a) => foo(a) + 3)();
// Lowered to the messier:
collection.map!((a) { return foo(a) + 3; })();
Dec 16 2010
next sibling parent reply loser <talk to.me> writes:
Nick Sabalausky Wrote:


 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:iedqos$787$1 digitalmars.com...

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find a 
 shorter syntax that didn't have problems. That being said, it's very 
 possible there are some great ones, we just couldn't find them.


 

 
 (x, y) =>  x * y
 
 // Lowered to:
 
 (x, y) { return x * y; }


The main reason might be that DMD used to suck at inlining these. Now that the

better choice. As you can see, the language authors prefer to stay quiet to
bury this discussion as efficiently as possible. It might even be the case that
Walter is too incompetent to implement this rewrite without introducing tons of
new bugs like he usually does. </loser-talk>
Dec 17 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
loser wrote:

 It might even be the case that Walter is too incompetent


Guilty as charged.
Dec 18 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-16 23:40, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:iedqos$787$1 digitalmars.com...

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find a
 shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.




 (x, y) =>   x * y

 // Lowered to:

 (x, y) { return x * y; }

 (Maybe that was rejected before due the the weird float operators that are
 now being ditched?)

 It wouldn't be used for delegates that involve actual statements (it would
 be expression-only), but that fits with the whole point of a lambda
 expression.

 Also, unlike the strings it doesn't suffer the problem of being evaluated in
 the wrong scope. For instance I think it's perfctly sensible to want a short
 lambda to be able to do something like this (pardon me if I have the syntax
 for map() wrong):

 int foo(int x) { ... }
 collection.map!"foo(a) + 3"();
 // Or if you want proper syntax highlighting:
 collection.map!q{ foo(a) + 3 }();

 I think that totally fits the charter of short lambdas, but the strings just
 can't do it (at least not without turning map() into something that needs to


 int foo(int x) { ... }
 collection.map!((a) =>  foo(a) + 3)();
 // Lowered to the messier:
 collection.map!((a) { return foo(a) + 3; })();



are also several other syntaxes available, one just have to look at 
other languages to get ideas. Here's a list of the syntax used by a 
couple of different language, some languages are list more than once 
because they support more than one syntax. I've listed the languages in 
order from, what I think, the least verbose to the most verbose 
lambda/delegate syntax (the number in front of the languages is the 
level of verbose, if two languages are at the same level I think they 
are equally verbose).

1 D: foo(writeln(3)); // lazy argument
1 Scala: foo(_ * _)

3 Scala: foo((x) => x * x)
4 Python: foo(lambda x: x * x)
5 Ruby: foo { |bar| x * x }
5 Ruby: foo do |x| x * x end
6 D: foo((int x) { return x * x; });
7 C++1x: foo([](int x){ return x * x; });
7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x * x; });
8 JavaScript: foo(function(x){ return x * x })
9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is 
used for explicitly telling what variables should be available when the 
scope is gone.

Note that I have not listed any functional languages here because I've 
never used one.

I would like a syntax that is a combination of D's lazy argument syntax 


If the lambda doesn't take have any parameters then you can just put the 
expression between then the parentheses in the function call:

foo(writeln(3));

If the lambda have one parameter then the following syntax is used:

foo(x => x * x);

If the lambda takes more then one parameter then you have to use 
parentheses around the lambda parameters like this:

foo((x, y) => x * y);

Actually if it would be possible to skip the parentheses when the lambda 
take more than one argument I would be more happy with that:

foo(x, y => x * y);

-- 
/Jacob Carlborg
Dec 18 2010
next sibling parent reply JRM <a b.com> writes:
On Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:
 

 I would like a syntax that is a combination of D's lazy argument syntax

 
 If the lambda doesn't take have any parameters then you can just put the
 expression between then the parentheses in the function call:
 
 foo(writeln(3));
 
 If the lambda have one parameter then the following syntax is used:
 
 foo(x => x * x);
 
 If the lambda takes more then one parameter then you have to use
 parentheses around the lambda parameters like this:
 
 foo((x, y) => x * y);
 
 Actually if it would be possible to skip the parentheses when the lambda
 take more than one argument I would be more happy with that:
 
 foo(x, y => x * y);


Why not define numbered placeholders to avoid the need for named 
arguments altogether.

foo( 1 *  2);

//lowers to

foo((arg1, arg2) { return arg1 * arg2; });

It would be a fairly simple extension to the lazy argument syntax, and 
cover most of the typical uses for short lambdas.
Dec 18 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-12-18 20:03, JRM wrote:

 On Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:


 I would like a syntax that is a combination of D's lazy argument syntax


 If the lambda doesn't take have any parameters then you can just put the
 expression between then the parentheses in the function call:

 foo(writeln(3));

 If the lambda have one parameter then the following syntax is used:

 foo(x =>  x * x);

 If the lambda takes more then one parameter then you have to use
 parentheses around the lambda parameters like this:

 foo((x, y) =>  x * y);

 Actually if it would be possible to skip the parentheses when the lambda
 take more than one argument I would be more happy with that:

 foo(x, y =>  x * y);


 Why not define numbered placeholders to avoid the need for named
 arguments altogether.


Well, I can't think of all the syntaxes there possible can be :)


 foo( 1 *  2);

 //lowers to

 foo((arg1, arg2) { return arg1 * arg2; });

 It would be a fairly simple extension to the lazy argument syntax, and
 cover most of the typical uses for short lambdas.


That doesn't look too bad, maybe somewhat confusing with numbers in the 
names? And it might also be could to have a way to name the arguments 
yourself.

-- 
/Jacob Carlborg
Dec 18 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 1 D: foo(writeln(3)); // lazy argument
 1 Scala: foo(_ * _)

 3 Scala: foo((x) => x * x)
 4 Python: foo(lambda x: x * x)
 5 Ruby: foo { |bar| x * x }
 5 Ruby: foo do |x| x * x end
 6 D: foo((int x) { return x * x; });
 7 C++1x: foo([](int x){ return x * x; });
 7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x * x; });
 8 JavaScript: foo(function(x){ return x * x })
 9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is 
 used for explicitly telling what variables should be available when the 
 scope is gone.


(In D there are template lambdas too). This topic was discussed some in past. I
like a syntax similar to:
foo({x,y => x * y})
foo({int x, int y => x * y})

Bye,
bearophile
Dec 18 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:


 Jacob Carlborg:


 1 D: foo(writeln(3)); // lazy argument
 1 Scala: foo(_ * _)

 3 Scala: foo((x) => x * x)
 4 Python: foo(lambda x: x * x)
 5 Ruby: foo { |bar| x * x }
 5 Ruby: foo do |x| x * x end
 6 D: foo((int x) { return x * x; });
 7 C++1x: foo([](int x){ return x * x; });
 7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x *  
 x; });
 8 JavaScript: foo(function(x){ return x * x })
 9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is
 used for explicitly telling what variables should be available when the
 scope is gone.


 (In D there are template lambdas too). This topic was discussed some in  
 past. I like a syntax similar to:
 foo({x,y => x * y})
 foo({int x, int y => x * y})


I really like this. The curly braces clearly show it to be a new scope,
and the syntax is concise and understandable.

-- 
Simen
Dec 18 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-12-18 21:48, Simen kjaeraas wrote:

 bearophile <bearophileHUGS lycos.com> wrote:


 Jacob Carlborg:


 1 D: foo(writeln(3)); // lazy argument
 1 Scala: foo(_ * _)

 3 Scala: foo((x) => x * x)
 4 Python: foo(lambda x: x * x)
 5 Ruby: foo { |bar| x * x }
 5 Ruby: foo do |x| x * x end
 6 D: foo((int x) { return x * x; });
 7 C++1x: foo([](int x){ return x * x; });
 7 Apple's (Objective)-C(++) block extension: foo(^(int x){ return x *
 x; });
 8 JavaScript: foo(function(x){ return x * x })
 9 PHP: foo(function ($x) use($fooBar) { return $x * $x; }); // "use" is
 used for explicitly telling what variables should be available when the
 scope is gone.


 (In D there are template lambdas too). This topic was discussed some
 in past. I like a syntax similar to:
 foo({x,y => x * y})
 foo({int x, int y => x * y})


 I really like this. The curly braces clearly show it to be a new scope,
 and the syntax is concise and understandable.


I don't like it, it's not enough improvement. Compared to this 
suggestion I think the current syntax is good enough.

-- 
/Jacob Carlborg
Dec 19 2010
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Sat, Dec 18, 2010 at 12:09 PM, Jacob Carlborg <doob me.com> wrote:

 Actually if it would be possible to skip the parentheses when the lambda
 take more than one argument I would be more happy with that:

 foo(x, y => x * y);


Pretty sure you'll need parenthesis. Should the above match:
func(int function(int, int))
or
func(int, int function(int))
Dec 18 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:



 are also several other syntaxes available, one just have to look at
 other languages to get ideas. Here's a list of the syntax used by a
 couple of different language, some languages are list more than once
 because they support more than one syntax. I've listed the languages in
 order from, what I think, the least verbose to the most verbose
 lambda/delegate syntax (the number in front of the languages is the
 level of verbose, if two languages are at the same level I think they
 are equally verbose).
 
 1 D: foo(writeln(3)); // lazy argument


That's not really equivalent to lambdas. It would be unfair to not 
mention Scala which also supports lazy arguments.


 1 Scala: foo(_ * _)


This isn't the same. _ * _ is equivalent to (a, b) => a * b

1 Scala: foo(x => x * x)



 3 Scala: foo((x) => x * x)


foo(x => x * x) also works in this case


 4 Python: foo(lambda x: x * x)
 5 Ruby: foo { |bar| x * x }


Maybe you meant

foo { |x| x * x }


 5 Ruby: foo do |x| x * x end
 6 D: foo((int x) { return x * x; });
 7 C++1x: foo([](int x){ return x * x; });
 7 Apple's (Objective)-C(++)
 block extension: foo(^(int x){ return x * x; });
 8 JavaScript:
 foo(function(x){ return x * x })
 9 PHP: foo(function ($x) use($fooBar) {
 return $x * $x; }); // "use" is used for explicitly telling what
 variables should be available when the scope is gone.
 
 Note that I have not listed any functional languages here because I've
 never used one.


For example:

Lambda calculus: λx.x*x
Haskell: \x -> x * x

As you can see, most of the verbosity comes from the fact that lambdas in 
D and C++ contain statements, not a single expression. It's like if-then-
else vs ternary ?:  -- In languages like Scala these are the same built-in 
feature.
Dec 18 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-18 22:50, retard wrote:

 Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:



 are also several other syntaxes available, one just have to look at
 other languages to get ideas. Here's a list of the syntax used by a
 couple of different language, some languages are list more than once
 because they support more than one syntax. I've listed the languages in
 order from, what I think, the least verbose to the most verbose
 lambda/delegate syntax (the number in front of the languages is the
 level of verbose, if two languages are at the same level I think they
 are equally verbose).

 1 D: foo(writeln(3)); // lazy argument


 That's not really equivalent to lambdas. It would be unfair to not
 mention Scala which also supports lazy arguments.


It depends on how you see it. It passes in a piece of code that can be 
executed in "foo". And when you see if like this I think the Scala 
syntax I mention below is the basically the same. (BTW, I mentioned it 
was lazy argument and not a delegate).


 1 Scala: foo(_ * _)


 This isn't the same. _ * _ is equivalent to (a, b) =>  a * b


I know that, but as far as I know I cannot do the same with D's lazy 
arguments.


 1 Scala: foo(x =>  x * x)



 3 Scala: foo((x) =>  x * x)


 foo(x =>  x * x) also works in this case


 4 Python: foo(lambda x: x * x)
 5 Ruby: foo { |bar| x * x }


 Maybe you meant

 foo { |x| x * x }


 5 Ruby: foo do |x| x * x end
 6 D: foo((int x) { return x * x; });
 7 C++1x: foo([](int x){ return x * x; });
 7 Apple's (Objective)-C(++)
 block extension: foo(^(int x){ return x * x; });
 8 JavaScript:
 foo(function(x){ return x * x })
 9 PHP: foo(function ($x) use($fooBar) {
 return $x * $x; }); // "use" is used for explicitly telling what
 variables should be available when the scope is gone.

 Note that I have not listed any functional languages here because I've
 never used one.


 For example:

 Lambda calculus: λx.x*x
 Haskell: \x ->  x * x

 As you can see, most of the verbosity comes from the fact that lambdas in
 D and C++ contain statements, not a single expression. It's like if-then-
 else vs ternary ?:  -- In languages like Scala these are the same built-in
 feature.


Yeah.

-- 
/Jacob Carlborg
Dec 19 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:iejab1$2t7$1 digitalmars.com...

 As you can see, most of the verbosity comes from the fact that lambdas in
 D and C++ contain statements, not a single expression. It's like if-then-
 else vs ternary ?:  -- In languages like Scala these are the same built-in
 feature.


FWIW, I've always found "if() else" and other such constructs to be a bit 
verbose to use inside an expression. So I've always liked ?:  (But I can 
certainly see the advantages of being able to use statements as 
expressions.)
Dec 19 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-12-19 20:33, Nick Sabalausky wrote:

 "retard"<re tard.com.invalid>  wrote in message
 news:iejab1$2t7$1 digitalmars.com...

 As you can see, most of the verbosity comes from the fact that lambdas in
 D and C++ contain statements, not a single expression. It's like if-then-
 else vs ternary ?:  -- In languages like Scala these are the same built-in
 feature.


 FWIW, I've always found "if() else" and other such constructs to be a bit
 verbose to use inside an expression. So I've always liked ?:  (But I can
 certainly see the advantages of being able to use statements as
 expressions.)


There are other places where they can be useful, like initializing 
variables:

auto y = if (x == 3)
             4;
          else
             5;

In this simple case the ternary operator would of course be better to use.

-- 
/Jacob Carlborg
Dec 19 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:

 foo(x, y => x * y);


The problem with all these is what is the difference between:

     { x * y }
     { x * y; }   <== note the ;
     { return x * y; }

The C++ lambda group had the same discussions.

It may not seem like much when the code is trivial, but when it gets more 
complex, having 2 or 3 different syntaxes for function bodies seems like a 
confusing disaster in the making.
Dec 18 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote:


 Jacob Carlborg wrote:

 foo(x, y => x * y);


 The problem with all these is what is the difference between:

      { x * y }
      { x * y; }   <== note the ;
      { return x * y; }


The problem of D's lambda syntax is it is optimized for longer
functions. Usually, the delegates I write are one line long. I cannot
see that this syntax collides with anything at the moment, but feel free
to enlighten me:

{ => 4; }
{ a => 2*a; }
{ a, b => a>b; }
{ =>   +  ; } // turns into { a, b => a + b; }

-- 
Simen
Dec 18 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel free
 to enlighten me:
 
 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }
 


If size and simplicity of typing are critical, are those really better than:

   "a>b"

?
Dec 18 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 If size and simplicity of typing are critical, are those really better than:
 
    "a>b"


Strings used for that purpose are a hack/kludge.

Bye,
bearophile
Dec 18 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ieji4j$10k5$1 digitalmars.com...

 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel free
 to enlighten me:

 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better 
 than:

   "a>b"

 ?


Yes, because in practice "a>b" must end up being evaluated in the wrong 
scope. I've used std.algorithm very little so far, and yet I've still found 
that limitation to be a problem.

There's also the minor quibble that "a>b" doesn't get highlighted right, but 
that's obviously solvable with q{a>b}.
Dec 18 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:iejimj$11qt$1 digitalmars.com...

 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:ieji4j$10k5$1 digitalmars.com...

 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel free
 to enlighten me:

 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better 
 than:

   "a>b"

 ?


 Yes, because in practice "a>b" must end up being evaluated in the wrong 
 scope. I've used std.algorithm very little so far, and yet I've still 
 found that limitation to be a problem.

 There's also the minor quibble that "a>b" doesn't get highlighted right, 
 but that's obviously solvable with q{a>b}.


One other issue with the string: You can't pass it to a function that 
expects an actual delegate. It may or may not be possible to make a 
conversion function, but even if so, you'd lose the simplicity/brevity which 
was the whole original point.

All in all, it's just platering over the problem.
Dec 18 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 Yes, because in practice "a>b" must end up being evaluated in the wrong 
 scope. I've used std.algorithm very little so far, and yet I've still found 
 that limitation to be a problem.


But it works fine for trivial lambdas, and if you're going beyond that, there's 
the fuller, complete syntax.
Dec 18 2010
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/19/10, Walter Bright <newshound2 digitalmars.com> wrote:

 Nick Sabalausky wrote:

 Yes, because in practice "a>b" must end up being evaluated in the wrong
 scope. I've used std.algorithm very little so far, and yet I've still
 found
 that limitation to be a problem.


 ..and if you're going beyond that,
 there's
 the fuller, complete syntax.


Exactly. Inventing a whole new syntax or borrowing some kind of
functional-language style syntax would only alienate those already
familiar with C syntax.
Dec 18 2010
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
imo, those  's (or monkeys, as we like to call them) are a sore pain
in the eye. And what if you need to do some simple arithmetic with the
numbered arguments?

someFunc!( 1+1> 2)(x);

Might be a silly example, but code like this could exist and will be confusing.

On 12/19/10, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 12/19/10, Walter Bright <newshound2 digitalmars.com> wrote:

 Nick Sabalausky wrote:

 Yes, because in practice "a>b" must end up being evaluated in the wrong
 scope. I've used std.algorithm very little so far, and yet I've still
 found
 that limitation to be a problem.


 ..and if you're going beyond that,
 there's
 the fuller, complete syntax.


 Exactly. Inventing a whole new syntax or borrowing some kind of
 functional-language style syntax would only alienate those already
 familiar with C syntax.
Dec 18 2010
next sibling parent JRM <a b.com> writes:
On Sun, 19 Dec 2010 02:35:16 +0100, Andrej Mitrovic wrote:


 imo, those  's (or monkeys, as we like to call them) are a sore pain in
 the eye. And what if you need to do some simple arithmetic with the
 numbered arguments?
 
 someFunc!( 1+1> 2)(x);
 
 Might be a silly example, but code like this could exist and will be
 confusing.
 


I agree that all the  's aren't too easy to read.  I might prefer _1, _2, 
etc.

I think someFunc!(_1 + 1 > _2)(x); is a little bit easier on the eyes.

But in general, the purpose of a short lambda syntax is to make it easier 
to read and write simple expressions.  If the expression becomes complex 
enough that they become too difficult to read, there is always the option 
of writing the full delegate syntax.

No matter what, I think some sort of placeholder syntax to shorten the 
common lambda's (whether it be  1, _1, _a, or something else) would be 
helpful.
Dec 18 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.17.1292722525.4748.digitalmars-d puremagic.com...

 imo, those  's (or monkeys, as we like to call them) are a sore pain
 in the eye. And what if you need to do some simple arithmetic with the
 numbered arguments?

 someFunc!( 1+1> 2)(x);

 Might be a silly example, but code like this could exist and will be 
 confusing.


I had always liked the idea of something like  1, 2,etc or _1,_2,etc, but I 
think this is a completely convincing counter-argument.
Dec 19 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:iejl6i$16f5$1 digitalmars.com...

 Nick Sabalausky wrote:

 Yes, because in practice "a>b" must end up being evaluated in the wrong 
 scope. I've used std.algorithm very little so far, and yet I've still 
 found that limitation to be a problem.


 But it works fine for trivial lambdas, and if you're going beyond that, 
 there's the fuller, complete syntax.


int foo(int x) { ... }
map!"foo(a) * 2" // Trivial lambda, but it fails

void bar(int delegate(int) dg) { ... }
bar("a+7") // Also fails

I don't think it's at all unreasonable to expect both of those to work with 
a short lambda syntax. That neither of them do I think is a clear sign that 
it's more of a clever hack than a real solution.
Dec 18 2010
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/19/10, Nick Sabalausky <a a.a> wrote:

 int foo(int x) { ... }
 map!"foo(a) * 2" // Trivial lambda, but it fails


Currently this will call unaryFunImpl, which tries to evaluate foo(a)
at compile-time, but foo isn't visible from std.functional, where
unaryFunImpl is defined.

I don't know, maybe Phobos could construct a closure out of the string
somehow if it detected that there's a function call in that string,
here's some pseudocode modified from std.functional:

template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
{
    static if (is(typeof(fun) : string))
    {
        // added: detect if there's a function call in that string
        static if (hasFunctionCalls(fun))
        {
            // if so construct a closure, and that should be it
            alias newclosure result;
        }
        else
        {
            // Otherwise do as usual in std.functional.unaryFunImpl
            template Body(ElementType)
            {
            }
            // old code...
        }
    }
    else
    {
        alias fun result;
    }
}
Dec 18 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Argh it started a new topic. Disregard this I'll reply to original thread.

On 12/19/10, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 12/19/10, Nick Sabalausky <a a.a> wrote:

 int foo(int x) { ... }
 map!"foo(a) * 2" // Trivial lambda, but it fails


 Currently this will call unaryFunImpl, which tries to evaluate foo(a)
 at compile-time, but foo isn't visible from std.functional, where
 unaryFunImpl is defined.

 I don't know, maybe Phobos could construct a closure out of the string
 somehow if it detected that there's a function call in that string,
 here's some pseudocode modified from std.functional:

 template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
 {
     static if (is(typeof(fun) : string))
     {
         // added: detect if there's a function call in that string
         static if (hasFunctionCalls(fun))
         {
             // if so construct a closure, and that should be it
             alias newclosure result;
         }
         else
         {
             // Otherwise do as usual in std.functional.unaryFunImpl
             template Body(ElementType)
             {
             }
             // old code...
         }
     }
     else
     {
         alias fun result;
     }
 }
Dec 18 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Currently this will call unaryFunImpl, which tries to evaluate foo(a)
at compile-time, but foo isn't visible from std.functional, where
unaryFunImpl is defined.

I don't know, maybe Phobos could construct a closure out of the string
somehow if it detected that there's a function call in that string,
here's some pseudocode modified from std.functional:

template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
{
   static if (is(typeof(fun) : string))
   {
       // added: detect if there's a function call in that string
       static if (hasFunctionCalls(fun))
       {
           // if so construct a closure, and that should be it
           alias newclosure result;
       }
       else
       {
           // Otherwise do as usual in std.functional.unaryFunImpl
           template Body(ElementType)
           {
           }
           // old code...
       }
   }
   else
   {
       alias fun result;
   }
}

On 12/19/10, Nick Sabalausky <a a.a> wrote:

 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:iejl6i$16f5$1 digitalmars.com...

 Nick Sabalausky wrote:

 Yes, because in practice "a>b" must end up being evaluated in the wrong
 scope. I've used std.algorithm very little so far, and yet I've still
 found that limitation to be a problem.


 But it works fine for trivial lambdas, and if you're going beyond that,
 there's the fuller, complete syntax.


 int foo(int x) { ... }
 map!"foo(a) * 2" // Trivial lambda, but it fails

 void bar(int delegate(int) dg) { ... }
 bar("a+7") // Also fails

 I don't think it's at all unreasonable to expect both of those to work with
 a short lambda syntax. That neither of them do I think is a clear sign that
 it's more of a clever hack than a real solution.
Dec 18 2010
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Oh my.. Gmail is giving me a headache. Sorry guys. :)
Dec 18 2010
prev sibling next sibling parent reply JRM <a b.com> writes:
On Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel
 free to enlighten me:
 
 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }
 
 


 If size and simplicity of typing are critical, are those really better
 than:
 
    "a>b"
 
 ?


I agree that those aren't really much better.
This entire discussion seems a little odd to me.  People are trying to 
find a way to more easily write lambda's, focusing in particular on 
single expression lambda's.  This happens to be the one case D already 
has a short syntax for.

In order to support lazy, D already allows an expression to be implicitly 
converted to a delegate returning either void or the type of the 
expression.  This covers the case of lambda's taking no arguments, and 
happens to be shorter than any of the proposed syntaxes.

The only issue with this is support for delegates taking arguments.  To 
do that, I suggest D define numbered placeholders, similar to those found 
in C++ (tr1 and 0x) and std.bind.  When found in an expression that is 
being implicitly cast to a delegate, the placeholders will represent the 
delegate's arguments.

In your "a>b" example, the expression  1> 2 would be converted to the 
delegate:

bool delegate(arg1, arg2) { return arg1>arg2; }

So in actual use, instead of writing:
sort!((a, b) { return a > b; })(x);
you could write:
sort!( 1> 2)(x);

This would make a single-expression lambda almost identical to the string-
based expressions currently being used.  It is similar to the Scala 
example mentioned earlier in this thread (i.e. _ > _), but it allows for 
arbitrary use of the arguments without resorting to named parameters.  
For instance, the Scala form doesn't allow you to use a single parameter 
more than once and it requires the arguments to be used in order.  With 
this syntax, we could easily do things like  1* 1 or  2- 1 without 
resorting to named parameters.

I think this idea (or something similar) is worth consideration.  It is 
simply a small extension to an already existing feature that would give D 
a terser syntax for lambda's than most of the other languages we've been 
discussing.
Dec 18 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
JRM wrote:

 you could write:
 sort!( 1> 2)(x);


[...]

 I think this idea (or something similar) is worth consideration.  It is 
 simply a small extension to an already existing feature that would give D 
 a terser syntax for lambda's than most of the other languages we've been 
 discussing.


but:

    sort!("a>b")(x);

is just as short! And it already works.
Dec 18 2010
next sibling parent reply spir <denis.spir gmail.com> writes:
On Sat, 18 Dec 2010 18:13:50 -0800
Walter Bright <newshound2 digitalmars.com> wrote:


 you could write: =20
 sort!( 1> 2)(x); =20


 [...]

 I think this idea (or something similar) is worth consideration.  It is=




=20

 simply a small extension to an already existing feature that would give=




 D=20

 a terser syntax for lambda's than most of the other languages we've bee=




n=20

 discussing. =20


=20
 but:
=20
     sort!("a>b")(x); =20
=20
 is just as short! And it already works.


Short, but wrong. I mean conceptually. In-code string representation of cod=
e is wrong. I cannot explain why, but something in me refuses that. Seems I=
'm not the only one.

What's the point? Dunno exactly, but I won't ever use this form. Reminds me=
 of magic Basic
	f =3D input("function? ")		eg: "2*x + 3"
	FOR x =3D 1 TO 1000
	    y =3D eval(f)
	    plot(x,y)
	ENDIF


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 18 2010
parent Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 12/19/10 01:29, spir wrote:

 On Sat, 18 Dec 2010 18:13:50 -0800
 Walter Bright <newshound2 digitalmars.com> wrote:
 

 you could write:  
 sort!( 1> 2)(x);  


 [...]

 I think this idea (or something similar) is worth consideration.  It is 
 simply a small extension to an already existing feature that would give D 
 a terser syntax for lambda's than most of the other languages we've been 
 discussing.  


 but:

     sort!("a>b")(x);  

 is just as short! And it already works.


 
 Short, but wrong. I mean conceptually. In-code string representation of code
is wrong. I cannot explain why, but something in me refuses that. Seems I'm not
the only one.


Maybe it's my history with embedded languages with eval() or eval-like
functions, like the BASIC one you referenced... or maybe it's because my
"D brain" likens this usage to the very thing that's going on behind the
scenes (string mixin), and which has proven to be a very handy feature...

I'm not sure what might be the reason, but: I find it suits me fine.
I'm not boasting or anything like that; I'm just pointing out that the
issues no doubt stem, at least in part, from a difference in individual
programmers' experience.  I'm used to making valuable use of things like
eval() -- which you evidently dislike, and not for invalid reasons.
Ultimately, though, I think this whole matter of D lambdas boils down to
just plain not liking the use of strings as anything other than
self-contained text data snips.

One of those weird languages I'm used to had two different kinds of
string literal... and the second one was actually a list of explicit
character codes, as integers.  You'd be surprised the uses one would
find for this thing -- such as easily writing escape code sequences.  My
point?  Different language, different environment.  When the new
environment is drastically different from what we're used to, even if
only in a few aspects, we shy from it.

At any rate, there's always the MiniD syntax to inspire those who must
seek another way.  This:
	func(\a, b -> a * b)
...is rewritten as:
	func(function(a, b) { return a*b; })

Obviously the backslash would be a potential problem.

--Chris N-S
Dec 19 2010
prev sibling next sibling parent reply foobar <foo bar.com> writes:
Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.  It is 
 simply a small extension to an already existing feature that would give D 
 a terser syntax for lambda's than most of the other languages we've been 
 discussing.


 
 but:
 
     sort!("a>b")(x);
 
 is just as short! And it already works.


I think that the issue here is not about syntax as much as it is about
semantics:
As others said, this is equivalent to dynamic language's eval() or to D's
string mixin and the this raises the question of hygiene which sadly has no
good solution in D. 

The main concern is this:
In what context are the symbols 'a' and 'b' evaluated? 

At the moment they cannot be correctly evaluated at the caller context and do
not allow:
sort!("a.foo() > b.bar()")(whatever);

The bikesheding of the syntax does not address this concern at all.
Dec 19 2010
next sibling parent retard <re tard.com.invalid> writes:
Sun, 19 Dec 2010 06:08:15 -0500, foobar wrote:


 Walter Bright Wrote:
 

 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.  It
 is simply a small extension to an already existing feature that would
 give D a terser syntax for lambda's than most of the other languages
 we've been discussing.


 
 but:
 
     sort!("a>b")(x);
 
 is just as short! And it already works.


 
 I think that the issue here is not about syntax as much as it is about
 semantics: As others said, this is equivalent to dynamic language's
 eval() or to D's string mixin and the this raises the question of
 hygiene which sadly has no good solution in D.
 
 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?
 
 At the moment they cannot be correctly evaluated at the caller context
 and do not allow: sort!("a.foo() > b.bar()")(whatever);
 
 The bikesheding of the syntax does not address this concern at all.


Two additional problems were also listed earlier in this thread:

 - template bloat (different strings generate new instances of the sort)
 - symbol visibility problems because of wrong scoping
Dec 19 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.  It is
 simply a small extension to an already existing feature that would give D
 a terser syntax for lambda's than most of the other languages we've been
 discussing.


 but:

      sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is about
semantics:
 As others said, this is equivalent to dynamic language's eval() or to D's
string mixin and the this raises the question of hygiene which sadly has no
good solution in D.


Please use the notion of syntactic hygiene correctly.

Andrei
Dec 19 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.  It is
 simply a small extension to an already existing feature that would give D
 a terser syntax for lambda's than most of the other languages we've been
 discussing.


 but:

      sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is about
semantics:
 As others said, this is equivalent to dynamic language's eval() or to D's
string mixin and the this raises the question of hygiene which sadly has no
good solution in D.

 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?

 At the moment they cannot be correctly evaluated at the caller context and do
not allow:
 sort!("a.foo()>  b.bar()")(whatever);


That does work. What doesn't work is calling nonmember functions looked 
up in the context of the caller.

Andrei
Dec 19 2010
parent reply foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:


 On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.  It is
 simply a small extension to an already existing feature that would give D
 a terser syntax for lambda's than most of the other languages we've been
 discussing.


 but:

      sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is about
semantics:
 As others said, this is equivalent to dynamic language's eval() or to D's
string mixin and the this raises the question of hygiene which sadly has no
good solution in D.

 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?

 At the moment they cannot be correctly evaluated at the caller context and do
not allow:
 sort!("a.foo()>  b.bar()")(whatever);


 
 That does work. What doesn't work is calling nonmember functions looked 
 up in the context of the caller.
 
 Andrei


Either way, I personally don't care that much for another syntax for delegates.
I personally just want to see this ugly hack removed from the standard library
and discouraged. This feature promotes a code smell. And for what, as you said
yourself, to save 4 characters?

D should be consistent with only ONE delegate syntax. This is why Ruby reads
like poetry to its followers and c++ is like carving letters in stone. 

I much prefer that the lowering you mentioned to be implemented so that
performance wise this UGLY hack will have no benefits. 

regarding hygiene - the term was correct. 
what happens in the following snippet?  

int a = 5;
sort!"a > b"(whatever);

I should be able to specify what is hygienic and what is not.
Dec 19 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 11:21 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.  It is
 simply a small extension to an already existing feature that would give D
 a terser syntax for lambda's than most of the other languages we've been
 discussing.


 but:

       sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is about
semantics:
 As others said, this is equivalent to dynamic language's eval() or to D's
string mixin and the this raises the question of hygiene which sadly has no
good solution in D.

 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?

 At the moment they cannot be correctly evaluated at the caller context and do
not allow:
 sort!("a.foo()>   b.bar()")(whatever);


 That does work. What doesn't work is calling nonmember functions looked
 up in the context of the caller.

 Andrei


 Either way, I personally don't care that much for another syntax for
delegates. I personally just want to see this ugly hack removed from the
standard library and discouraged. This feature promotes a code smell. And for
what, as you said yourself, to save 4 characters?


"a > b" vs. (a, b) { return a > b; }

Savings: 17 characters.


 D should be consistent with only ONE delegate syntax. This is why Ruby reads
like poetry to its followers and c++ is like carving letters in stone.


Also, Ruby is well slower than C++ and other languages. It's easy to 
design a beautiful language if that's the primary concern. It's 
difficult to design a language when you want to keep in harmony a larger 
list of desiderata.


 I much prefer that the lowering you mentioned to be implemented so that
performance wise this UGLY hack will have no benefits.


The lowering will unfortunately solve little. I don't see how

sort!"a > b"(array);

is horrible but

sort(a, b; array) { return a > b; }

is beautiful and clear. Besides, that return is bizarre - did you mean 
return from the comparison or the caller? Ruby chose the latter, which I 
think is very sensible, but in that case you have a more difficult time 
returning locally. Of course, inventing new syntax is always available :o).


 regarding hygiene - the term was correct.


No.


Andrei
Dec 19 2010
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/19/2010 02:28 PM, Andrei Alexandrescu wrote:

 On 12/19/10 11:21 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.
 It is
 simply a small extension to an already existing feature that would
 give D
 a terser syntax for lambda's than most of the other languages
 we've been
 discussing.


 but:

 sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is
 about semantics:
 As others said, this is equivalent to dynamic language's eval() or
 to D's string mixin and the this raises the question of hygiene
 which sadly has no good solution in D.

 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?

 At the moment they cannot be correctly evaluated at the caller
 context and do not allow:
 sort!("a.foo()> b.bar()")(whatever);


 That does work. What doesn't work is calling nonmember functions looked
 up in the context of the caller.

 Andrei


 Either way, I personally don't care that much for another syntax for
 delegates. I personally just want to see this ugly hack removed from
 the standard library and discouraged. This feature promotes a code
 smell. And for what, as you said yourself, to save 4 characters?


 "a > b" vs. (a, b) { return a > b; }

 Savings: 17 characters.


 D should be consistent with only ONE delegate syntax. This is why Ruby
 reads like poetry to its followers and c++ is like carving letters in
 stone.


 Also, Ruby is well slower than C++ and other languages. It's easy to
 design a beautiful language if that's the primary concern. It's
 difficult to design a language when you want to keep in harmony a larger
 list of desiderata.


 I much prefer that the lowering you mentioned to be implemented so
 that performance wise this UGLY hack will have no benefits.


 The lowering will unfortunately solve little. I don't see how

 sort!"a > b"(array);

 is horrible but

 sort(a, b; array) { return a > b; }

 is beautiful and clear. Besides, that return is bizarre - did you mean
 return from the comparison or the caller? Ruby chose the latter, which I
 think is very sensible, but in that case you have a more difficult time
 returning locally.


Not at all. The last executed statement is what gets returned. And that 
doesn't only apply to blocks, but to normal functions:

def foo
   1
end

Of course, inventing new syntax is always available :o).

 regarding hygiene - the term was correct.


 No.


 Andrei
Dec 19 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 11:31 AM, Ary Borenszweig wrote:

 On 12/19/2010 02:28 PM, Andrei Alexandrescu wrote:

 On 12/19/10 11:21 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.
 It is
 simply a small extension to an already existing feature that would
 give D
 a terser syntax for lambda's than most of the other languages
 we've been
 discussing.


 but:

 sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is
 about semantics:
 As others said, this is equivalent to dynamic language's eval() or
 to D's string mixin and the this raises the question of hygiene
 which sadly has no good solution in D.

 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?

 At the moment they cannot be correctly evaluated at the caller
 context and do not allow:
 sort!("a.foo()> b.bar()")(whatever);


 That does work. What doesn't work is calling nonmember functions looked
 up in the context of the caller.

 Andrei


 Either way, I personally don't care that much for another syntax for
 delegates. I personally just want to see this ugly hack removed from
 the standard library and discouraged. This feature promotes a code
 smell. And for what, as you said yourself, to save 4 characters?


 "a > b" vs. (a, b) { return a > b; }

 Savings: 17 characters.


 D should be consistent with only ONE delegate syntax. This is why Ruby
 reads like poetry to its followers and c++ is like carving letters in
 stone.


 Also, Ruby is well slower than C++ and other languages. It's easy to
 design a beautiful language if that's the primary concern. It's
 difficult to design a language when you want to keep in harmony a larger
 list of desiderata.


 I much prefer that the lowering you mentioned to be implemented so
 that performance wise this UGLY hack will have no benefits.


 The lowering will unfortunately solve little. I don't see how

 sort!"a > b"(array);

 is horrible but

 sort(a, b; array) { return a > b; }

 is beautiful and clear. Besides, that return is bizarre - did you mean
 return from the comparison or the caller? Ruby chose the latter, which I
 think is very sensible, but in that case you have a more difficult time
 returning locally.


 Not at all. The last executed statement is what gets returned. And that
 doesn't only apply to blocks, but to normal functions:

 def foo
 1
 end


That would work if and only if it were designed into the language from 
day one - now it's too late. I encourage you to work out through various 
cases (if/else, switch, loops, returning void vs. a value) to see this 
will have considerable difficulties in D.

Andrei
Dec 19 2010
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/19/2010 03:45 PM, Andrei Alexandrescu wrote:

 On 12/19/10 11:31 AM, Ary Borenszweig wrote:

 On 12/19/2010 02:28 PM, Andrei Alexandrescu wrote:

 On 12/19/10 11:21 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 On 12/19/10 5:08 AM, foobar wrote:

 Walter Bright Wrote:


 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration.
 It is
 simply a small extension to an already existing feature that would
 give D
 a terser syntax for lambda's than most of the other languages
 we've been
 discussing.


 but:

 sort!("a>b")(x);

 is just as short! And it already works.


 I think that the issue here is not about syntax as much as it is
 about semantics:
 As others said, this is equivalent to dynamic language's eval() or
 to D's string mixin and the this raises the question of hygiene
 which sadly has no good solution in D.

 The main concern is this:
 In what context are the symbols 'a' and 'b' evaluated?

 At the moment they cannot be correctly evaluated at the caller
 context and do not allow:
 sort!("a.foo()> b.bar()")(whatever);


 That does work. What doesn't work is calling nonmember functions
 looked
 up in the context of the caller.

 Andrei


 Either way, I personally don't care that much for another syntax for
 delegates. I personally just want to see this ugly hack removed from
 the standard library and discouraged. This feature promotes a code
 smell. And for what, as you said yourself, to save 4 characters?


 "a > b" vs. (a, b) { return a > b; }

 Savings: 17 characters.


 D should be consistent with only ONE delegate syntax. This is why Ruby
 reads like poetry to its followers and c++ is like carving letters in
 stone.


 Also, Ruby is well slower than C++ and other languages. It's easy to
 design a beautiful language if that's the primary concern. It's
 difficult to design a language when you want to keep in harmony a larger
 list of desiderata.


 I much prefer that the lowering you mentioned to be implemented so
 that performance wise this UGLY hack will have no benefits.


 The lowering will unfortunately solve little. I don't see how

 sort!"a > b"(array);

 is horrible but

 sort(a, b; array) { return a > b; }

 is beautiful and clear. Besides, that return is bizarre - did you mean
 return from the comparison or the caller? Ruby chose the latter, which I
 think is very sensible, but in that case you have a more difficult time
 returning locally.


 Not at all. The last executed statement is what gets returned. And that
 doesn't only apply to blocks, but to normal functions:

 def foo
 1
 end


 That would work if and only if it were designed into the language from
 day one - now it's too late. I encourage you to work out through various
 cases (if/else, switch, loops, returning void vs. a value) to see this
 will have considerable difficulties in D.

 Andrei


I was just pointing out that it works that way in Ruby, not that it 
should be implemented in D.
Dec 19 2010
prev sibling parent reply foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:


 Either way, I personally don't care that much for another syntax for
delegates. I personally just want to see this ugly hack removed from the
standard library and discouraged. This feature promotes a code smell. And for
what, as you said yourself, to save 4 characters?


 
 "a > b" vs. (a, b) { return a > b; }
 
 Savings: 17 characters.
 


I reserve the right to dislike it even if it was 20 characters. The fact that
it's a useful hack doesn't make it smell less.


 D should be consistent with only ONE delegate syntax. This is why Ruby reads
like poetry to its followers and c++ is like carving letters in stone.


 
 Also, Ruby is well slower than C++ and other languages. It's easy to 
 design a beautiful language if that's the primary concern. It's 
 difficult to design a language when you want to keep in harmony a larger 
 list of desiderata.
 

 I much prefer that the lowering you mentioned to be implemented so that
performance wise this UGLY hack will have no benefits.


 
 The lowering will unfortunately solve little. I don't see how
 
 sort!"a > b"(array);
 
 is horrible but
 
 sort(a, b; array) { return a > b; }


I wasn't referring to the above which still deals with the syntactic issue. 
I'm talking about making:

sort!"a >b"(whatever);
and
sort(whatever, (a, b) { return a>b; }); 

have the same performance. Thus obviating the need for the first form.
the best form IMO would be of course:

whatever.sort((a, b) { return a>b; });

This touches another topic - the universal function call feature.
Dec 19 2010
next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
foobar wrote:
...

 
 I wasn't referring to the above which still deals with the syntactic
 issue. I'm talking about making:
 
 sort!"a >b"(whatever);
 and
 sort(whatever, (a, b) { return a>b; });
 
 have the same performance. Thus obviating the need for the first form.
 the best form IMO would be of course:
 
 whatever.sort((a, b) { return a>b; });
 


Would be nice, but:
- is it even possible (performance-wise)?
- can you enforce this performance constraint? There is a big difference 
between inlining a lexical closure and creating a full one on the heap.
- with template alias parameters, its easy to compose more complex types at 
compile time, you will lose this ability.
Dec 19 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 11:54 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 Either way, I personally don't care that much for another syntax for
delegates. I personally just want to see this ugly hack removed from the
standard library and discouraged. This feature promotes a code smell. And for
what, as you said yourself, to save 4 characters?


 "a>  b" vs. (a, b) { return a>  b; }

 Savings: 17 characters.


 I reserve the right to dislike it even if it was 20 characters. The fact that
it's a useful hack doesn't make it smell less.


It doesn't smell. You believe it does only because you mistakenly 
believe it's not hygienic.


 D should be consistent with only ONE delegate syntax. This is why Ruby reads
like poetry to its followers and c++ is like carving letters in stone.


 Also, Ruby is well slower than C++ and other languages. It's easy to
 design a beautiful language if that's the primary concern. It's
 difficult to design a language when you want to keep in harmony a larger
 list of desiderata.


 I much prefer that the lowering you mentioned to be implemented so that
performance wise this UGLY hack will have no benefits.


 The lowering will unfortunately solve little. I don't see how

 sort!"a>  b"(array);

 is horrible but

 sort(a, b; array) { return a>  b; }


 I wasn't referring to the above which still deals with the syntactic issue.
 I'm talking about making:

 sort!"a>b"(whatever);
 and
 sort(whatever, (a, b) { return a>b; });

 have the same performance. Thus obviating the need for the first form.


I explained how this is much more difficult than it might seem at first 
sight.

Andrei
Dec 19 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/19/10, foobar <foo bar.com> wrote:

 This feature promotes a code smell.
 <snip>
 what happens in the following snippet?

 int a = 5;
 sort!"a > b"(whatever);


You've accurately described your snippet in advance. *That* is a code
smell. You should never use single-variable names in your code in the
first place.
Dec 19 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I meant single-letter variable names there.

On 12/19/10, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 12/19/10, foobar <foo bar.com> wrote:

 This feature promotes a code smell.
 <snip>
 what happens in the following snippet?

 int a = 5;
 sort!"a > b"(whatever);


 You've accurately described your snippet in advance. *That* is a code
 smell. You should never use single-variable names in your code in the
 first place.
Dec 19 2010
prev sibling parent so <so so.do> writes:
 what happens in the following snippet?

 int a = 5;
 sort!"a > b"(whatever);


int a = 5;
writeln("oh that a? this is what happens!");

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 19 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-19 03:13, Walter Bright wrote:

 JRM wrote:

 you could write:
 sort!( 1> 2)(x);


 [...]

 I think this idea (or something similar) is worth consideration. It is
 simply a small extension to an already existing feature that would
 give D a terser syntax for lambda's than most of the other languages
 we've been discussing.


 but:

 sort!("a>b")(x);

 is just as short! And it already works.


Apparently it has several flaws as other have mentioned in this thread.

-- 
/Jacob Carlborg
Dec 19 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Sun, 19 Dec 2010 01:24:43 +0000 (UTC)
JRM <a b.com> wrote:


 On Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:

 If size and simplicity of typing are critical, are those really better
 than:
=20
    "a>b"
=20
 ?


=20
 I agree that those aren't really much better.
 This entire discussion seems a little odd to me.  People are trying to=20
 find a way to more easily write lambda's, focusing in particular on=20
 single expression lambda's.  This happens to be the one case D already=20
 has a short syntax for.
=20
 In order to support lazy, D already allows an expression to be implicitly=


=20

 converted to a delegate returning either void or the type of the=20
 expression.  This covers the case of lambda's taking no arguments, and=20
 happens to be shorter than any of the proposed syntaxes.
=20
 The only issue with this is support for delegates taking arguments.  To=20
 do that, I suggest D define numbered placeholders, similar to those found=


=20

 in C++ (tr1 and 0x) and std.bind.  When found in an expression that is=20
 being implicitly cast to a delegate, the placeholders will represent the=


=20

 delegate's arguments.
=20
 In your "a>b" example, the expression  1> 2 would be converted to the=20
 delegate:
=20
 bool delegate(arg1, arg2) { return arg1>arg2; }
=20
 So in actual use, instead of writing:
 sort!((a, b) { return a > b; })(x);
 you could write:
 sort!( 1> 2)(x);
=20
 This would make a single-expression lambda almost identical to the string-
 based expressions currently being used.  It is similar to the Scala=20
 example mentioned earlier in this thread (i.e. _ > _), but it allows for=


=20

 arbitrary use of the arguments without resorting to named parameters. =20
 For instance, the Scala form doesn't allow you to use a single parameter=


=20

 more than once and it requires the arguments to be used in order.  With=20
 this syntax, we could easily do things like  1* 1 or  2- 1 without=20
 resorting to named parameters.
=20
 I think this idea (or something similar) is worth consideration.  It is=20
 simply a small extension to an already existing feature that would give D=


=20

 a terser syntax for lambda's than most of the other languages we've been=


=20

 discussing.


If this form, or a form close to it, is syntactically OK, I vote for it :-)
One thousand of "NO!" to any kind of string representation of code. (gut fe=
eling)


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 18 2010
prev sibling parent retard <re tard.com.invalid> writes:
Sun, 19 Dec 2010 01:24:43 +0000, JRM wrote:


 On Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:
 

 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel
 free to enlighten me:
 
 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }
 
 


 If size and simplicity of typing are critical, are those really better
 than:
 
    "a>b"
 
 ?


 
 I agree that those aren't really much better. This entire discussion
 seems a little odd to me.  People are trying to find a way to more
 easily write lambda's, focusing in particular on single expression
 lambda's.


Have you got any idea what a 'lambda' actually is? It originates from the 
lambda calculus. In lambda calculus the lambda abstraction is something 
that takes a single argument and returns an *expression*. You can argue 
that this is less general than D's delegates, but the fact is that many 
such functions such as sort, filter, map, reduce, ... return an 
expression. Of course the explicit return generates additional syntactic 
bloat.


 In order to support lazy, D already allows an expression to be
 implicitly converted to a delegate returning either void or the type of
 the expression.  This covers the case of lambda's taking no arguments,
 and happens to be shorter than any of the proposed syntaxes.


Sorry, don't remember how this works in D if you actually call the 
function with a delegate that isn't taking any arguments, but if the lazy 
generates another thunk, this doesn't work consistently.


 I think this idea (or something similar) is worth consideration.  It is
 simply a small extension to an already existing feature that would give
 D a terser syntax for lambda's than most of the other languages we've
 been discussing.


So in your opinion D's function literals should only be improved if you 
can somehow outwit existing languages, otherwise it just sounds like a 
stupid idea?
Dec 19 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel free
 to enlighten me:
  { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better  
 than:

    "a>b"

 ?


No. But often, you want to call a function in a lambda, in which case
the string version croaks. Also, it is not always possible to pass the
lambda by template alias parameter, in which case the string version is
right out the window.
As for functions taking a delegate, the {=> + ;} syntax will not work
with overloading or template functions (nor will the other syntaxen that
elides types). It could also be that functions taking delegates are or
should be rare, and thus not worth optimizing for.

-- 
Simen
Dec 19 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 5:01 AM, Simen kjaeraas wrote:

 Walter Bright <newshound2 digitalmars.com> wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel free
 to enlighten me:
 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better
 than:

 "a>b"

 ?


 No. But often, you want to call a function in a lambda, in which case
 the string version croaks.


I'm not sure about the "often" part. For me, string lambdas do often 
suffice. When it doesn't, I use a lambda. D's syntax for lambdas is not 
syntactically heavy at all:

(a, b) { return a + b; }

The proposed alternative gravitates around

(a, b) -> { a + b }

So this discussion concerns a niche between short lambdas that can be 
expressed as strings and lambdas for which the actual word "return" is 
too much to type. In fact we're looking at the difference between 
"return " + ";" and " -> ". Four characters.

If the new syntax would be executed to perfection, to what extent would 
that improve your use of D? To what extent would it make the language 
more powerful? To what extent does it allow to do things you otherwise 
wouldn't be able to?

Equally importantly, where is this four-characters saver on the radar 
compared to fixing const's issues, discussing tail const, completing and 
then improving 64-bit support, fixing important bugs, or even adding the 
lambda lowering that was discussed earlier in this thread to be promptly 
forgotten?


 Also, it is not always possible to pass the
 lambda by template alias parameter, in which case the string version is
 right out the window.


unaryFunc!"a + b"


 As for functions taking a delegate, the {=> + ;} syntax will not work
 with overloading or template functions (nor will the other syntaxen that
 elides types). It could also be that functions taking delegates are or
 should be rare, and thus not worth optimizing for.


I have no idea what {=> + ;} does - it looks like a wrong paste from an 
early dialect of Perl to me. I have difficulty picturing someone who 
finds "a+b" or q{a+b} ugly but some other syntaxes discussed here palatable.


Andrei
Dec 19 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-12-19 16:14, Andrei Alexandrescu wrote:

 On 12/19/10 5:01 AM, Simen kjaeraas wrote:

 Walter Bright <newshound2 digitalmars.com> wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel
 free
 to enlighten me:
 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better
 than:

 "a>b"

 ?


 No. But often, you want to call a function in a lambda, in which case
 the string version croaks.


 I'm not sure about the "often" part. For me, string lambdas do often
 suffice. When it doesn't, I use a lambda. D's syntax for lambdas is not
 syntactically heavy at all:

 (a, b) { return a + b; }

 The proposed alternative gravitates around

 (a, b) -> { a + b }


I never proposed that exact syntax, I don't think anyone else did 
either. I think just one person mentioned "->". This is the syntax I've 
proposed:

foo(3 * 4); // lazy argument/delegate
foo(a => a * 3);
foo(a, b => a * b); // or if not possible:
foo((a, b) => a * b);


 So this discussion concerns a niche between short lambdas that can be
 expressed as strings and lambdas for which the actual word "return" is
 too much to type. In fact we're looking at the difference between
 "return " + ";" and " -> ". Four characters.


No, you also added the {} characters.


 If the new syntax would be executed to perfection, to what extent would
 that improve your use of D? To what extent would it make the language
 more powerful? To what extent does it allow to do things you otherwise
 wouldn't be able to?


Nothing, but there are a lot of things you can say the same about. I've 
also got the impression that you are pushing for a more functional 
approach of coding and for that a short, good and working lambda syntax 
is necessary.


 Equally importantly, where is this four-characters saver on the radar
 compared to fixing const's issues, discussing tail const, completing and
 then improving 64-bit support, fixing important bugs, or even adding the
 lambda lowering that was discussed earlier in this thread to be promptly
 forgotten?


If this isn't a very quick implementation this would low on the priority 
list. I would like to have the lambda lowering as well :)


 Also, it is not always possible to pass the
 lambda by template alias parameter, in which case the string version is
 right out the window.


 unaryFunc!"a + b"


 As for functions taking a delegate, the {=> + ;} syntax will not work
 with overloading or template functions (nor will the other syntaxen that
 elides types). It could also be that functions taking delegates are or
 should be rare, and thus not worth optimizing for.


 I have no idea what {=> + ;} does - it looks like a wrong paste from an
 early dialect of Perl to me. I have difficulty picturing someone who
 finds "a+b" or q{a+b} ugly but some other syntaxes discussed here
 palatable.


 Andrei


That syntax is just ugly.

-- 
/Jacob Carlborg
Dec 19 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel
 free to enlighten me:
 
 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }
 
 


 If size and simplicity of typing are critical, are those really better
 than:
 
    "a>b"


In case you didn't see, two additional problems were also listed earlier 
in this thread:

 - template bloat (different strings generate new instances of the sort 
in the sorting example)
 - symbol visibility problems because of wrong scoping
Dec 19 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 6:26 AM, retard wrote:

 Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel
 free to enlighten me:

 { =>  4; }
 { a =>  2*a; }
 { a, b =>  a>b; }
 { =>    +  ; } // turns into { a, b =>  a + b; }


 If size and simplicity of typing are critical, are those really better
 than:

     "a>b"


 In case you didn't see, two additional problems were also listed earlier
 in this thread:

   - template bloat (different strings generate new instances of the sort
 in the sorting example)


This can be solved by using a canonicalizer before passing to unaryFun. 
I considered doing that, but delayed implementing it to when this would 
actually become a problem.


   - symbol visibility problems because of wrong scoping


Scoping is not wrong, it's just different :o). I agree that that can be 
an issue - in which case you take the enormous hit of writing (a, b) { 
stmts }, of which the proposals passionately discussed within save a 
grand total of around four characters.

Again: to what extent does this help on becoming able to do what you 
want to do in D, and where is implementing this ranked in comparison to 
the other work items?


Andrei
Dec 19 2010
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Imagine you don't have to write semicolons in D. If you have 1000 lines of code
you save 1000 keystrokes
and characters to read.

If you have about 50 delegates in your code you save 200 characters.

I don't think this is more important than the other problems you mention, but
adding bits of characters
here and there ends up saving a lot.
Dec 19 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/19/10 9:49 AM, Ary Borenszweig wrote:

 Imagine you don't have to write semicolons in D. If you have 1000 lines of
code you save 1000 keystrokes
 and characters to read.

 If you have about 50 delegates in your code you save 200 characters.


The way you measure to assess whether this is material is in proportion 
to the rest of the code. Semicolons are quite frequent, but 200 
characters in 1000 lines may be as infrequent as 0.2%.


 I don't think this is more important than the other problems you mention, but
adding bits of characters
 here and there ends up saving a lot.


I agree in principle, but not in this case.


Andrei
Dec 19 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Ary Borenszweig wrote:

 Imagine you don't have to write semicolons in D. If you have 1000 lines of
code you save 1000 keystrokes
 and characters to read.
 
 If you have about 50 delegates in your code you save 200 characters.
 
 I don't think this is more important than the other problems you mention, but
adding bits of characters
 here and there ends up saving a lot.


Saving keystrokes is, in my not so humble opinion, a totally bogus metric with 
which to judge a programming language.

What matters, in anything other than a language designed for one-liners, is how 
the code looks on the page.

For example, we don't just nail photo prints to the wall. We present them with
a 
matte, then mount in a complementary frame. Cooking is a lot about the 
presentation of the food, not just the taste.

I think that source code is a lot about the presentation of it. It should look 
good. The way it looks should be an aid to understanding what it does. Correct 
code should look right, wrong code should look wrong.

(I've had many experience programmers tell me they can just scan a page of code 
and the bugs stand out because they just look wrong. They don't have to
actually 
understand the code to find the bugs. A language that enhances this effect is a 
better language than one that does not.)

For example, it's hard to format code with goto's so it looks right. It's a lot 
easier with structured constructs.

There is value in brevity - extra syntactical noise can distract from what the 
code is doing. But it can also positively frame and present code. That's what 
should be the criteria.
Dec 19 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-19 16:23, Andrei Alexandrescu wrote:

 On 12/19/10 6:26 AM, retard wrote:

 Sat, 18 Dec 2010 16:01:37 -0800, Walter Bright wrote:


 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel
 free to enlighten me:

 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better
 than:

 "a>b"


 In case you didn't see, two additional problems were also listed earlier
 in this thread:

 - template bloat (different strings generate new instances of the sort
 in the sorting example)


 This can be solved by using a canonicalizer before passing to unaryFun.
 I considered doing that, but delayed implementing it to when this would
 actually become a problem.


I can clearly see that you haven't used an Objective-C/D bridge. The 
reason (or at least one of the reasons) for which Michel Fortin (as well 
as I) gave up the Objective-C/D bridge and started to modify DMD is 
template bloat. I'm not saying that using template strings as lambdas is 
going to bloat your executable/library as much as the bridge does but I 
always think twice before adding a template to my code.


 - symbol visibility problems because of wrong scoping


 Scoping is not wrong, it's just different :o). I agree that that can be
 an issue - in which case you take the enormous hit of writing (a, b) {
 stmts }, of which the proposals passionately discussed within save a
 grand total of around four characters.


I don't know why but you added the {} characters.


 Again: to what extent does this help on becoming able to do what you
 want to do in D, and where is implementing this ranked in comparison to
 the other work items?


 Andrei


-- 
/Jacob Carlborg
Dec 19 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-12-19 11:11:03 -0500, Jacob Carlborg <doob me.com> said:


 On 2010-12-19 16:23, Andrei Alexandrescu wrote:

 On 12/19/10 6:26 AM, retard wrote:

 In case you didn't see, two additional problems were also listed earlier
 in this thread:
 
 - template bloat (different strings generate new instances of the sort
 in the sorting example)


 
 This can be solved by using a canonicalizer before passing to unaryFun.
 I considered doing that, but delayed implementing it to when this would
 actually become a problem.


 
 I can clearly see that you haven't used an Objective-C/D bridge. The 
 reason (or at least one of the reasons) for which Michel Fortin (as 
 well as I) gave up the Objective-C/D bridge and started to modify DMD 
 is template bloat. I'm not saying that using template strings as 
 lambdas is going to bloat your executable/library as much as the bridge 
 does but I always think twice before adding a template to my code.


Has anyone checked which of delegates or strings cause more template bloat?

I'd suspect using strings will result in less bloat because the same 
string will often be reused (making the compiler reuse the same 
template instance) whereas the compiler will likely use the mangled 
name of the delegate when instantiating the template... and no two 
delegate literals have the same mangled name.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 19 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-19 19:29, Michel Fortin wrote:

 On 2010-12-19 11:11:03 -0500, Jacob Carlborg <doob me.com> said:


 On 2010-12-19 16:23, Andrei Alexandrescu wrote:

 On 12/19/10 6:26 AM, retard wrote:

 In case you didn't see, two additional problems were also listed
 earlier
 in this thread:

 - template bloat (different strings generate new instances of the sort
 in the sorting example)


 This can be solved by using a canonicalizer before passing to unaryFun.
 I considered doing that, but delayed implementing it to when this would
 actually become a problem.


 I can clearly see that you haven't used an Objective-C/D bridge. The
 reason (or at least one of the reasons) for which Michel Fortin (as
 well as I) gave up the Objective-C/D bridge and started to modify DMD
 is template bloat. I'm not saying that using template strings as
 lambdas is going to bloat your executable/library as much as the
 bridge does but I always think twice before adding a template to my code.


 Has anyone checked which of delegates or strings cause more template bloat?

 I'd suspect using strings will result in less bloat because the same
 string will often be reused (making the compiler reuse the same template
 instance) whereas the compiler will likely use the mangled name of the
 delegate when instantiating the template... and no two delegate literals
 have the same mangled name.


That would only be the case if the function takes the delegate as a 
template parameter?

-- 
/Jacob Carlborg
Dec 19 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-12-19 15:17:50 -0500, Jacob Carlborg <doob me.com> said:


 On 2010-12-19 19:29, Michel Fortin wrote:

 Has anyone checked which of delegates or strings cause more template bloat?
 
 I'd suspect using strings will result in less bloat because the same
 string will often be reused (making the compiler reuse the same template
 instance) whereas the compiler will likely use the mangled name of the
 delegate when instantiating the template... and no two delegate literals
 have the same mangled name.


 
 That would only be the case if the function takes the delegate as a 
 template parameter?


Indeed. Passing a delegate as a function argument won't create a new 
instance of that function.

This is also why it runs slower: the function doesn't know which 
delegate is called until runtime. If the function is short, it could be 
inlined, which would in turn allow the delegate to be inlined and run 
faster. But if you somehow could force the compiler to inline 'sort' 
all the time it's likely the code bloat will be even worse.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 19 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-12-19 11:11:03 -0500, Jacob Carlborg <doob me.com> said:


 I can clearly see that you haven't used an Objective-C/D bridge. The 
 reason (or at least one of the reasons) for which Michel Fortin (as 
 well as I) gave up the Objective-C/D bridge and started to modify DMD 
 is template bloat. I'm not saying that using template strings as 
 lambdas is going to bloat your executable/library as much as the bridge 
 does but I always think twice before adding a template to my code.


I also want to add that the code bloat in the D/Objective-C bridge was 
more because the bridge needed to create two stubs for each method in 
all Cocoa classes, and those stubs contained code to translate 
exceptions from one model to the other. Using templates and mixins made 
the creation of those stubs easy, but I don't think another method of 
generating these stubs would have faired better.

So the bloat came from the approach (generating stubs for everything) 
much more than the implementation choice (templates). The new approach 
is to avoid having to generate stubs by exposing directly the 
Objective-C objects rather than wrappers around them. Less wrapping, 
less bloat.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 19 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-19 22:02, Michel Fortin wrote:

 On 2010-12-19 11:11:03 -0500, Jacob Carlborg <doob me.com> said:


 I can clearly see that you haven't used an Objective-C/D bridge. The
 reason (or at least one of the reasons) for which Michel Fortin (as
 well as I) gave up the Objective-C/D bridge and started to modify DMD
 is template bloat. I'm not saying that using template strings as
 lambdas is going to bloat your executable/library as much as the
 bridge does but I always think twice before adding a template to my code.


 I also want to add that the code bloat in the D/Objective-C bridge was
 more because the bridge needed to create two stubs for each method in
 all Cocoa classes, and those stubs contained code to translate
 exceptions from one model to the other. Using templates and mixins made
 the creation of those stubs easy, but I don't think another method of
 generating these stubs would have faired better.


I was thinking about having the tool that creates the bindings 
generating all the necessary code inline and skip all the templates, 
just to see if there would be a difference in the speed of the 
compilation and the size of the generated binaries.


 So the bloat came from the approach (generating stubs for everything)
 much more than the implementation choice (templates). The new approach
 is to avoid having to generate stubs by exposing directly the
 Objective-C objects rather than wrappers around them. Less wrapping,
 less bloat.


-- 
/Jacob Carlborg
Dec 20 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-12-20 12:50:47 -0500, Jacob Carlborg <doob me.com> said:


 On 2010-12-19 22:02, Michel Fortin wrote:

 On 2010-12-19 11:11:03 -0500, Jacob Carlborg <doob me.com> said:
 

 I can clearly see that you haven't used an Objective-C/D bridge. The
 reason (or at least one of the reasons) for which Michel Fortin (as
 well as I) gave up the Objective-C/D bridge and started to modify DMD
 is template bloat. I'm not saying that using template strings as
 lambdas is going to bloat your executable/library as much as the
 bridge does but I always think twice before adding a template to my code.


 
 I also want to add that the code bloat in the D/Objective-C bridge was
 more because the bridge needed to create two stubs for each method in
 all Cocoa classes, and those stubs contained code to translate
 exceptions from one model to the other. Using templates and mixins made
 the creation of those stubs easy, but I don't think another method of
 generating these stubs would have faired better.


 
 I was thinking about having the tool that creates the bindings 
 generating all the necessary code inline and skip all the templates, 
 just to see if there would be a difference in the speed of the 
 compilation and the size of the generated binaries.


That'd certainly make an interesting comparison.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 20 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-19 01:01, Walter Bright wrote:

 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel free
 to enlighten me:

 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better
 than:

 "a>b"

 ?


No, that syntax is not better.

-- 
/Jacob Carlborg
Dec 19 2010
parent reply so <so so.do> writes:
On Sun, 19 Dec 2010 17:51:34 +0200, Jacob Carlborg <doob me.com> wrote:


 On 2010-12-19 01:01, Walter Bright wrote:

 Simen kjaeraas wrote:

 The problem of D's lambda syntax is it is optimized for longer
 functions. Usually, the delegates I write are one line long. I cannot
 see that this syntax collides with anything at the moment, but feel  
 free
 to enlighten me:

 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }


 If size and simplicity of typing are critical, are those really better
 than:

 "a>b"

 ?


 No, that syntax is not better.


Ignoring technical limitations:


 "a>b"




is to me, looks million times better than these 4 or other absurd syntaxes  
proposed on this thread.


 { => 4; }
 { a => 2*a; }
 { a, b => a>b; }
 { =>   +  ; } // turns into { a, b => a + b; }




You might call this a hack, fine!

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 19 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
int[] a = [ 1, 2, 3 ];
string[] b = [ "a", "b", "c" ];
sort!("a[0] > b[0]")(zip(a, b));

or

int[] a = [ 1, 2, 3 ];
string[] b = [ "a", "b", "c" ];
sort!( [0] >  [0])(zip(a, b));

--

auto var = sequence!("a[1] + n-1 + a[0]")(1, 2);

or

auto var = sequence!( 1[1] + n-1 +  1[0])(1, 2);
Dec 19 2010
parent reply so <so so.do> writes:
On Mon, 20 Dec 2010 01:18:20 +0200, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 int[] a = [ 1, 2, 3 ];
 string[] b = [ "a", "b", "c" ];
 sort!("a[0] > b[0]")(zip(a, b));

 or

 int[] a = [ 1, 2, 3 ];
 string[] b = [ "a", "b", "c" ];
 sort!( [0] >  [0])(zip(a, b));

 --

 auto var = sequence!("a[1] + n-1 + a[0]")(1, 2);

 or

 auto var = sequence!( 1[1] + n-1 +  1[0])(1, 2);


That syntax can't even differ "a > b" from "b > a", and   is ugly to be  
used frequently.
On the other hand strings open many doors probably limited by only our  
imagination.
And it is there in the language spec, enabled by tiny template feature,  
passing strings as arguments.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 19 2010
parent so <so so.do> writes:
 That syntax can't even differ "a > b" from "b > a", and   is ugly to be  
 used frequently.
 On the other hand strings open many doors probably limited by only our  
 imagination.
 And it is there in the language spec, enabled by tiny template feature,  
 passing strings as arguments.


I was wrong saying it can't differ. Didn't see the number after  .
Still you are limited comparing to string version and requires a language  
feature. (which is unnecessarily, well for me!)

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 19 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-18 23:41, Walter Bright wrote:

 Jacob Carlborg wrote:

 foo(x, y => x * y);


 The problem with all these is what is the difference between:

 { x * y }
 { x * y; } <== note the ;
 { return x * y; }


I would say there is no difference. The delegeate would be inferred to 
have the same type as the function requires.

Take this for example, "foo" is declared like this:

void foo (int delegate (int x, int y) dg);

And called like this:

foo(x, y => x * y);

Then the delegate would be inferred to be:

int delegate (int, int)

If you add a semicolon or a return in the lambda body it would be 
inferred to the same type.


 The C++ lambda group had the same discussions.

 It may not seem like much when the code is trivial, but when it gets
 more complex, having 2 or 3 different syntaxes for function bodies seems
 like a confusing disaster in the making.


The point is to only use the syntax when the code is trivial, like in 
the above example.

-- 
/Jacob Carlborg
Dec 19 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:


 
 (x, y) =>  x * y
 
 // Lowered to:
 
 (x, y) { return x * y; }
 
 (Maybe that was rejected before due the the weird float operators that are 
 now being ditched?)


The problem with the (x,y) parameter lists, where x and y are the parameters,
is 
that it is ambiguous with the existing syntax of (x,y) where x and y are types 
and the parameters are omitted.

For example:

void foo(int);
Dec 18 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:iejejo$pfr$1 digitalmars.com...

 Nick Sabalausky wrote:



 (x, y) =>  x * y

 // Lowered to:

 (x, y) { return x * y; }

 (Maybe that was rejected before due the the weird float operators that 
 are now being ditched?)


 The problem with the (x,y) parameter lists, where x and y are the 
 parameters, is that it is ambiguous with the existing syntax of (x,y) 
 where x and y are types and the parameters are omitted.

 For example:

 void foo(int);


But we already have:

    (x, y) { return x * y; }

So either there aren't any problems with it after all, or D's existing 
delegate syntax is already broken.

To be clear, with what I'm trying to suggest, the *only* thing that would be 
different from the current delegate literal syntax is that part *after* the 
parameter list. Ie:

    PARAM_LIST_HERE { return x * y; }
    // -->
    PARAM_LIST_HERE => x * y

Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or 
whatever. I'm not suggesting the param list be different in any way fromhow 
t is now. (Although proposals from other people might differ.)
Dec 18 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ieji3n$10ou$1 digitalmars.com...

 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:iejejo$pfr$1 digitalmars.com...

 Nick Sabalausky wrote:



 (x, y) =>  x * y

 // Lowered to:

 (x, y) { return x * y; }

 (Maybe that was rejected before due the the weird float operators that 
 are now being ditched?)


 The problem with the (x,y) parameter lists, where x and y are the 
 parameters, is that it is ambiguous with the existing syntax of (x,y) 
 where x and y are types and the parameters are omitted.

 For example:

 void foo(int);


 But we already have:

    (x, y) { return x * y; }

 So either there aren't any problems with it after all, or D's existing 
 delegate syntax is already broken.

 To be clear, with what I'm trying to suggest, the *only* thing that would 
 be different from the current delegate literal syntax is that part *after* 
 the parameter list. Ie:

    PARAM_LIST_HERE { return x * y; }
    // -->
    PARAM_LIST_HERE => x * y

 Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or 
 whatever. I'm not suggesting the param list be different in any way 
 fromhow t is now. (Although proposals from other people might differ.)


Slight correction: There is *one* other difference from the current delegate 
literal syntax: The part after => must be an expression rather than a 
statement or a block.

But again, I'm not suggesting any change to param list - except *maybe* to 
make the param's parens omittable for zero-param or one-param delegates, but 
*only* if there isn't a problem with that. I'm ok with keeping them if they 
really still need to be there in those cases.
Dec 18 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-19 01:01, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:iejejo$pfr$1 digitalmars.com...

 Nick Sabalausky wrote:



 (x, y) =>   x * y

 // Lowered to:

 (x, y) { return x * y; }

 (Maybe that was rejected before due the the weird float operators that
 are now being ditched?)


 The problem with the (x,y) parameter lists, where x and y are the
 parameters, is that it is ambiguous with the existing syntax of (x,y)
 where x and y are types and the parameters are omitted.

 For example:

 void foo(int);


 But we already have:

      (x, y) { return x * y; }

 So either there aren't any problems with it after all, or D's existing
 delegate syntax is already broken.

 To be clear, with what I'm trying to suggest, the *only* thing that would be
 different from the current delegate literal syntax is that part *after* the
 parameter list. Ie:

      PARAM_LIST_HERE { return x * y; }
      // -->
      PARAM_LIST_HERE =>  x * y

 Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or
 whatever. I'm not suggesting the param list be different in any way fromhow
 t is now. (Although proposals from other people might differ.)


^^ Exactly. I would also like to have type inference for the parameter 
list, do we have that already in D2?

-- 
/Jacob Carlborg
Dec 19 2010
parent "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:iel9p5$1goa$2 digitalmars.com...

 On 2010-12-19 01:01, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:iejejo$pfr$1 digitalmars.com...

 Nick Sabalausky wrote:



 (x, y) =>   x * y

 // Lowered to:

 (x, y) { return x * y; }

 (Maybe that was rejected before due the the weird float operators that
 are now being ditched?)


 The problem with the (x,y) parameter lists, where x and y are the
 parameters, is that it is ambiguous with the existing syntax of (x,y)
 where x and y are types and the parameters are omitted.

 For example:

 void foo(int);


 But we already have:

      (x, y) { return x * y; }

 So either there aren't any problems with it after all, or D's existing
 delegate syntax is already broken.

 To be clear, with what I'm trying to suggest, the *only* thing that would 
 be
 different from the current delegate literal syntax is that part *after* 
 the
 parameter list. Ie:

      PARAM_LIST_HERE { return x * y; }
      // -->
      PARAM_LIST_HERE =>  x * y

 Or if there's a problem with =>, then ->, or -->, or ::>, or :>, or
 whatever. I'm not suggesting the param list be different in any way 
 fromhow
 t is now. (Although proposals from other people might differ.)


 ^^ Exactly. I would also like to have type inference for the parameter 
 list, do we have that already in D2?


I know you can use "auto". I had thought you could also omit the type in a 
delegate literal's param list, but Walter's response above makes me think I 
might be mistaken. Even if so, as I was trying to say above, if delegate 
literals are indeed required to be (auto x, auto y) { return x * y; }, then 
I would be perfectly happy with lambdas that were the same: (auto x, auto y) 
=> x * y  I do think that's still far easier to read than the full delegate 
literal syntax.
Dec 19 2010
prev sibling parent reply Justin Johansson <noreply jj.com> writes:
On 17/12/10 06:52, Andrei Alexandrescu wrote:

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find
 a shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.

 Andrei


"we just couldn't find them"

Is that the royal "we" as in singular?
If plural, may one politely inquire as to whom "we" are?

Justin
Dec 17 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/17/10 10:23 AM, Justin Johansson wrote:

 On 17/12/10 06:52, Andrei Alexandrescu wrote:

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find
 a shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.

 Andrei


 "we just couldn't find them"

 Is that the royal "we" as in singular?
 If plural, may one politely inquire as to whom "we" are?


Walter, Bartosz Milewski, Eric Niebler, David Held and myself have 
discussed the issue a number of times. It has also been often discussed 
on this newsgroup.

Andrei
Dec 17 2010
next sibling parent reply loser <talk to.me> writes:
Andrei Alexandrescu Wrote:


 On 12/17/10 10:23 AM, Justin Johansson wrote:

 On 17/12/10 06:52, Andrei Alexandrescu wrote:

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find
 a shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.

 Andrei


 "we just couldn't find them"

 Is that the royal "we" as in singular?
 If plural, may one politely inquire as to whom "we" are?


 
 Walter, Bartosz Milewski, Eric Niebler, David Held and myself have 
 discussed the issue a number of times. It has also been often discussed 
 on this newsgroup.


I find few things odd. First, Eric and David are your C++ buddies. Why are you
having this secret society instead of openly discussing D features in the D
mailing lists? Invite them here, please. We are the community, we also have an
opinion of this language. The C++ users' opinions are often very conservative
and hostile towards ideas that don't resemble C++ syntax or aren't performance
oriented. Evidently the D community in general wants a better lambda syntax,
and the recently proposed feature is actually better than the currently used
string hack, given a properly optimizing compiler.

This has been discussed several times and every time your secret society tells
that nothing could be found. We never hear what's the real reason blocking
this. Why can't you spend that two minutes writing down your conclusions. It
feels like you're not doing your job. Only two things come to my mind: 1) the
proposed feature goes too far from C++ syntactically or semantically, 2) Walter
cannot implement it probably because of some conflicting legacy C syntax or it
requires too much changes in the compiler (== is not a low-hanging fruit =>
doesn't motivate him), 3) D 2.0 is already set in stone and you don't want to
admit that further improvements are still needed in the near future (this would
make your template/string lambda idiom and the D 2.0 feature set an embarrasing
short sighted hack). Admit it Andrei, it has some problems. The different
string parameters generate bloat in object code and the lookup issues are also
bad. With a properly optimizing compiler the real lambda can be optimized to
generate equal object code without any of these problems.

Not finding the solution is quite surprising considering that almost all other
modern languages are finding more or less the same solution and every time a
community member here suggests a solution, it's more or less the same. What are
the problem you're having?
Dec 17 2010
next sibling parent reply Don <nospam nospam.com> writes:
loser wrote:

 Andrei Alexandrescu Wrote:
 

 On 12/17/10 10:23 AM, Justin Johansson wrote:

 On 17/12/10 06:52, Andrei Alexandrescu wrote:

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find
 a shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.

 Andrei


 "we just couldn't find them"

 Is that the royal "we" as in singular?
 If plural, may one politely inquire as to whom "we" are?


 Walter, Bartosz Milewski, Eric Niebler, David Held and myself have 
 discussed the issue a number of times. It has also been often discussed 
 on this newsgroup.


 
 I find few things odd. 


First, Eric and David are your C++ buddies. Why are you having this 
secret society instead of openly discussing D features in the D mailing 
lists?

[snip]

It WAS discussed on the newsgroup, and that => syntax was discussed as well.
(I didn't get involved in it, but it was quite public).
Dec 17 2010
parent "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:iegf5n$imd$2 digitalmars.com...

 It WAS discussed on the newsgroup, and that => syntax was discussed as 
 well.
 (I didn't get involved in it, but it was quite public).


I don't suppose you have a link to the => discussion?
Dec 18 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-17 18:36, loser wrote:

 Andrei Alexandrescu Wrote:


 On 12/17/10 10:23 AM, Justin Johansson wrote:

 On 17/12/10 06:52, Andrei Alexandrescu wrote:

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find
 a shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.

 Andrei


 "we just couldn't find them"

 Is that the royal "we" as in singular?
 If plural, may one politely inquire as to whom "we" are?


 Walter, Bartosz Milewski, Eric Niebler, David Held and myself have
 discussed the issue a number of times. It has also been often discussed
 on this newsgroup.


 I find few things odd. First, Eric and David are your C++ buddies. Why are you
having this secret society instead of openly discussing D features in the D
mailing lists? Invite them here, please. We are the community, we also have an
opinion of this language. The C++ users' opinions are often very conservative
and hostile towards ideas that don't resemble C++ syntax or aren't performance
oriented. Evidently the D community in general wants a better lambda syntax,
and the recently proposed feature is actually better than the currently used
string hack, given a properly optimizing compiler.

 This has been discussed several times and every time your secret society tells
that nothing could be found. We never hear what's the real reason blocking
this. Why can't you spend that two minutes writing down your conclusions. It
feels like you're not doing your job. Only two things come to my mind: 1) the
proposed feature goes too far from C++ syntactically or semantically, 2) Walter
cannot implement it probably because of some conflicting legacy C syntax or it
requires too much changes in the compiler (== is not a low-hanging fruit => 
doesn't motivate him), 3) D 2.0 is already set in stone and you don't want to
admit that further improvements are still needed in the near future (this would
make your template/string lambda idiom and the D 2.0 feature set an embarrasing
short sighted hack). Admit it Andrei, it has some problems. The different
string parameters generate bloat in object code and the lookup issues are also
bad. With a properly optimizing compiler the real la


mbda can be optimized to generate equal object code without any of these
problems.

 Not finding the solution is quite surprising considering that almost all other
modern languages are finding more or less the same solution and every time a
community member here suggests a solution, it's more or less the same. What are
the problem you're having?


I have to agree with this post. I've also got the feeling more than once 
that the community is excluded sometimes. The community often receives 
messages like "It's been discussed and the conclusion was we couldn't 
solve it/we couldn't find a better way/syntax..." with no review of the 
discussion and no elaboration of the conclusion or why you came to the 
conclusion you did.

-- 
/Jacob Carlborg
Dec 18 2010
parent so <so so.do> writes:
 with no review of the discussion and no elaboration of the conclusion or  
 why you came to the conclusion you did.


I agree with this part.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-17 17:47, Andrei Alexandrescu wrote:

 On 12/17/10 10:23 AM, Justin Johansson wrote:

 On 17/12/10 06:52, Andrei Alexandrescu wrote:

 On 12/16/10 1:30 PM, Jacob Carlborg wrote:

 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


 I understand. Using strings is witnessing the fact that we couldn't find
 a shorter syntax that didn't have problems. That being said, it's very
 possible there are some great ones, we just couldn't find them.

 Andrei


 "we just couldn't find them"

 Is that the royal "we" as in singular?
 If plural, may one politely inquire as to whom "we" are?


 Walter, Bartosz Milewski, Eric Niebler, David Held and myself have
 discussed the issue a number of times. It has also been often discussed
 on this newsgroup.

 Andrei


And what was the conclusion, more than just "we just couldn't find them" ?

-- 
/Jacob Carlborg
Dec 18 2010
prev sibling parent Justin Johansson <noreply jj.com> writes:
On 17/12/10 06:30, Jacob Carlborg wrote:

 On 2010-12-15 23:33, Andrei Alexandrescu wrote:

 On 12/15/10 4:18 PM, retard wrote:

 Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:

 Array(1, 2, 3, 4, 5).sortWith(_> _)


 The first instance of _ (from left to right) is replaced with the first
 element of the parameter tuple, the second with second element, etc.

 This is actually very useful since many lambdas only use 1-2 parameters.
 It has its limitations. For example referring to the same parameter
 requires a named parameter or some other hack. Combined with Haskell
 style partial application this allows stuff like:

 Array(1, 2, 3, 4, 5).foreach { println }

 Array(1, 2, 3, 4, 5).filter(2<)


 For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
 "2 < a" or "a < b". Since it's a string, "_ < _" would have been usable
 with Phobos too but I wouldn't like such a change.

 Andrei


 The point here isn't that we want "a" and "b" to be replaced with "_"
 the point is that we want to get rid of the string and have a shorter
 and less verbose syntax for delegate literals.


The point you point out is a good point. :-)  3 points

Using strings for the delegate literals is just so JavaScript-ish and 
less than ideal.  What escape mechanism must one use when strings are 
argued rather than the simple arithmetic/numeric examples usually 
demonstrated for this type of construct?

Cheers
Justin
Dec 17 2010
prev sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 14.12.2010 20:03, Jacob Carlborg wrote:

 On 2010-12-14 19:33, Stephan Soller wrote:

 I think it's a matter of consistency. In Ruby blocks are used all the
 time for pretty much everything. In D this isn't the case because
 usually templates are used for stuff where blocks are used in Ruby
 (e.g.
 map, group and find in std.algorithm).


 I think that the templates that take a string as a predicate is just an
 ugly hack because D has a too verbose delegate syntax.


 I absolutely agree with that. However I don't have a better idea how to
 write it. Delegate syntax is already fairly compact in D.

 For example code as this isn't very uncommon in Ruby:

 [1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}

 Of course this is a simplified example. Usually the collection would
 contain some objects and the blocks would filter for a method call (like
 "e.even?"). However I built a small D1 struct that implements a select
 and collect function. With the unified function call synatax for array
 with code should actually work:

 [1, 2, 3, 4, 5].select((int e){ return e > 3; })
 .collect((int e){ return e*e; });

 It's already fairly compact. The main overhead is the parameter type and
 the return statement. I don't believe this can be reduced any more
 without breaking consistency of the language.


 Probably not, but, for example, Scala allows very compact delegate
 literals:

 Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

 I'm not 100% sure I that the syntax is correct.


 Delegates are way more verbose in other languages like PHP and
 JavaScript (more or less the same syntax in both languages). Despite
 that it's no problem to use it and in case of jQuery it's used very
 often. I think the main reason why delegates are not used like that in D
 is performance. I'm really not sure about it but I suspect that
 delegates are less effective than code directly generated by a template
 like map!(). I don't know how efficient templates can integrate
 delegates so I just suspect that this is a performance problem.

 Happy programming
 Stephan Soller


 PHP has a very verbose delegate syntax with explicit closures, one of
 the many reasons I don't use PHP. JavaScript has quite similar syntax as
 D but the "function" keyword is required, I try to use CoffeeScript
 (compiles to javascript), which has a lot nicer delegate syntax, as
 often I can.

 D(dmd) needs to be able to inline delegates.


I'm not so much concerned about verbose delegate syntax. Personally I 
don't mind using the current delegate syntax with templates like map!. 
However I'm concerned about performance and parameter order. Does 
someone know how delegates within templates are handled? I looked at the 
source of std.algorithm and std.functional but I'm still not sure what 
actually happens if you call something like

	auto ary = [1, 2, 3];
	map!((e){ return e*e; })(ary);

I can't test this code right now since I don't have a D2 compiler 
installed at this computer but the std.algorithm source contains unit 
tests with delegates.

If that now works with uniform function call syntax it could be written 
like that:

	auto ary = [1, 2, 3];
	ary.map!((e){ return e*e; });

I don't know if chaining of such calls is possible but the above syntax 
is already pretty good. Sure, it's not perfect and the "return" still is 
some overhead, but I don't think it needs work. What's more important 
(at least for me) is the chaining ability and how performant such 
delegates actually are. From what I understood from std.functional it 
wraps string expressions in delegates anyway so using

	ary.map!("a*a");

is not more efficient. Please correct me if I'm wrong! The 
std.functional code is definitely above my understanding.


So, _if_ we can figure out a way to do some nice chaining of such calls 
we can get:

	[1, 2, 3, 4, 5].filter!((e){ return e > 3; })
		.map!((e){ return e*e; });

Or if you don't like delegates and don't mind obvious compile time black 
magic:

	[1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");

I think if chaining would work like that D would already be pretty close 
to the expressive power of Ruby. It's just that this kind of programming 
is very dependent on the ability of built in collections and libraries 
that allow such a programming style.

Happy programming
Stephan Soller
Dec 15 2010
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/15/10, Stephan Soller <stephan.soller helionweb.de> wrote:

 So, _if_ we can figure out a way to do some nice chaining of such calls
 we can get:

 	[1, 2, 3, 4, 5].filter!((e){ return e > 3; })
 		.map!((e){ return e*e; });

 Or if you don't like delegates and don't mind obvious compile time black
 magic:

 	[1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");


You might use pipe! as an alternative:

import std.algorithm;
import std.functional;
import std.stdio;

void main()
{
    int[] arr = [1, 2, 3, 4, 5];
    auto result = pipe!( filter!("a>3"), map!("a * a") )(arr);
    writeln(result);
}

But I can't seem to do the same with delegates:

import std.algorithm;
import std.functional;
import std.stdio;

void main()
{
    int[] arr = [1, 2, 3, 4, 5];
    pipe!( filter!( (e){ return e > 3; } ),
             map!( (e){ return e*e; } ) )(arr);
}

chain.d(9): Error: expression template filter(Range) is not a valid
template value argument
chain.d(9): Error: expression template map(Range) is not a valid template
value argument
Dec 15 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 15.12.2010 17:37, Andrej Mitrovic wrote:

 On 12/15/10, Stephan Soller<stephan.soller helionweb.de>  wrote:

 So, _if_ we can figure out a way to do some nice chaining of such calls
 we can get:

 	[1, 2, 3, 4, 5].filter!((e){ return e>  3; })
 		.map!((e){ return e*e; });

 Or if you don't like delegates and don't mind obvious compile time black
 magic:

 	[1, 2, 3, 4, 5].filter!("a>  3").map!("a * a");


 You might use pipe! as an alternative:

 import std.algorithm;
 import std.functional;
 import std.stdio;

 void main()
 {
      int[] arr = [1, 2, 3, 4, 5];
      auto result = pipe!( filter!("a>3"), map!("a * a") )(arr);
      writeln(result);
 }

 But I can't seem to do the same with delegates:

 import std.algorithm;
 import std.functional;
 import std.stdio;

 void main()
 {
      int[] arr = [1, 2, 3, 4, 5];
      pipe!( filter!( (e){ return e>  3; } ),
               map!( (e){ return e*e; } ) )(arr);
 }

 chain.d(9): Error: expression template filter(Range) is not a valid
 template value argument
 chain.d(9): Error: expression template map(Range) is not a valid template
 value argument


Thanks for testing this out. :)

I noticed compose! and pipe! but these break my "thought flow". It's 
hard to describe since I only experienced such a way of writing code in 
Ruby. You can more or less write your thoughts down without much 
translation or the need to go back and forth in the line. As you think 
you can type… I don't need a "thought buffer" so to speak.

Having to think about if I want to call multiple collection operations 
or just one right at the start breaks this flow. That the data at hand 
is pushed to the end of the line (poor visibility) also don't really 
help. I don't know if this is a matter preference but while deciding on 
such collection operations I usually think about the data first. Only if 
I know how the data is structured I start to apply operations on it.

This code

	[1, 2, 3, 4, 5].filter!("a>  3").map!("a * a");

matches the that flow of thoughts. With pipe! I have to jump 2 times 
within a buffer of 3 thoughts.

All that may sound very… unprofessional or "not like a real programmer". 
However that kind of "mental friction" adds up and you notice that if 
it's no longer there. I really agree with Matz (the creator of Ruby) 
that the way you formulate your thoughts changes your thought patterns 
in turn. Ruby is carefully crafted to keep the resulting thought 
patterns close to the natural ones. To experienced programmers this 
might be irritating at first since languages like C++, Java and even D 
require some mental acrobatics to formulate what you want. It takes some 
time to just think strait again if you're used to these acrobatics. Ruby 
is a very interesting subject if you're interested in what programmers 
think while programming.

Please note that this stuff is IMHO limited to application programming. 
That is to solve hight level problems where low level work only adds 
friction and is not that important (like with usual Websites). With 
systems level programming this is different. When working with low-level 
APIs and very machine specific problems the thought patterns are 
different than the ones of application programming. The problems are 
often not defined by real world needs and therefore the experience from 
the real world can not help there.

This is the reason why I think D should not spend to much time with 
this. It's not a design goal of D and probably would collide with other 
design goals (e.g. efficient compiler implementation). If someone really 
wants this kind of programming in D it's not that difficult to do, but 
will cost efficiency (e.g. using real functions instead of templates). D 
should not mimic Ruby nor is Ruby as bad as some might think. It's one 
of the few languages that really accept that programmers are humans and 
not machines. D does this too but by far not to the same extend (thats 
why I still like D1 more than D2 actually).

Ruby has its applications and D has its applications. The right tool for 
the right job only works if the different tools have a distinct purpose 
and not try to do everything at the expense of being good at one thing.

Happy programming
Stephan Soller
Dec 16 2010
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/16/10, Stephan Soller <stephan.soller helionweb.de> wrote:

 snip


The cool thing about D is that with a little bit of string magic you
can make your own DSL's. Here's a rather hardcoded and superficial
example, but for this simple case it works:

http://pastebin.com/Xkghv1ky

Of course you'd need to build your own little DSL string parsing
functions and use regex instead of hardcoding it like that. But all
kinds of syntaxes are possible.
Dec 16 2010
parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote:

 The cool thing about D is that with a little bit of string magic you
 can make your own DSL's. Here's a rather hardcoded and superficial
 example, but for this simple case it works:

 http://pastebin.com/Xkghv1ky

 Of course you'd need to build your own little DSL string parsing
 functions and use regex instead of hardcoding it like that. But all
 kinds of syntaxes are possible.


You are right. I tried making one. It parses things like sum !(q{  i=0:10; 
i * sum!(q{   j=0:10, j!=i;    i*j   })  })
http://pastebin.com/mQaKXaYY -
But it doesn't work because not being CTFE friendly, and also syntax parser 
is ugly because I am not strong at syntax parsing.
Note that creating good syntax parser in CTFE is rather hard, especially for 
complex syntaxes like of D expressions.
Oh, if CTFE could:
 1) run external process
 2) do file i/o
 3) use dynamic libraries
This would be much much simpler, but I guess it will not.
This features also has safety issues, but D is system language, not browser 
one.
Dec 16 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 16.12.2010 23:33, Alex_Dovhal wrote:

 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote:

 The cool thing about D is that with a little bit of string magic you
 can make your own DSL's. Here's a rather hardcoded and superficial
 example, but for this simple case it works:

 http://pastebin.com/Xkghv1ky

 Of course you'd need to build your own little DSL string parsing
 functions and use regex instead of hardcoding it like that. But all
 kinds of syntaxes are possible.


 You are right. I tried making one. It parses things like sum !(q{  i=0:10;
 i * sum!(q{   j=0:10, j!=i;    i*j   })  })
 http://pastebin.com/mQaKXaYY -
 But it doesn't work because not being CTFE friendly, and also syntax parser
 is ugly because I am not strong at syntax parsing.
 Note that creating good syntax parser in CTFE is rather hard, especially for
 complex syntaxes like of D expressions.
 Oh, if CTFE could:
   1) run external process
   2) do file i/o
   3) use dynamic libraries
 This would be much much simpler, but I guess it will not.
 This features also has safety issues, but D is system language, not browser
 one.


I don't think that the syntax improvement of chaining is worth such an 
effort. It adds tons of complexity for only a very limited gain. I'm not 
sure if I could write such self-parsed code without thinking about that 
pipeline.
Dec 17 2010
parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote:

 I don't think that the syntax improvement of chaining is worth such an 
 effort. It adds tons of complexity for only a very limited gain. I'm not 
 sure if I could write such self-parsed code without thinking about that 
 pipeline.


I think I don't fully understand what you mean by syntax improvement for 
chaining. This my code is almost possible to run but needs some time and 
work (to get round CTFE limitations, enhance parser). But syntax parser 
behind it is rather primitive, if to use external tools one can make much 
better syntax parsers with much less efford.
Dec 19 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 19.12.2010 14:22, Alex_Dovhal wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote:

 I don't think that the syntax improvement of chaining is worth such an
 effort. It adds tons of complexity for only a very limited gain. I'm not
 sure if I could write such self-parsed code without thinking about that
 pipeline.


 I think I don't fully understand what you mean by syntax improvement for
 chaining. This my code is almost possible to run but needs some time and
 work (to get round CTFE limitations, enhance parser). But syntax parser
 behind it is rather primitive, if to use external tools one can make much
 better syntax parsers with much less efford.


I read your post in the context of method chaining with templates like 
filter! and map!. Looks like I missed the point. :)

I think your idea is pretty impressive. Maybe useful for some high-level 
stuff like mathematical formulas.
Dec 20 2010
parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote

 I read your post in the context of method chaining with templates like 
 filter! and map!. Looks like I missed the point. :)

 I think your idea is pretty impressive. Maybe useful for some high-level 
 stuff like mathematical formulas.


Yes, I borrowed the idea and syntax (changed a little) from Maxima CAS 
(computer algebra system - system for symbolically manipulating algerbraic 
formulaes) - there they have functions like makelist(i*i, i, 1, 10), 
sum(i*i, i, 1, 10), prod... etc. which appealed me so much. That expression 
in Maxima is converted to LISP and then calculated and send back to CAS. 
Here string is parsed to AST and then form new string to be mixed in D code.
Dec 20 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-12-15 17:06, Stephan Soller wrote:

 On 14.12.2010 20:03, Jacob Carlborg wrote:

 On 2010-12-14 19:33, Stephan Soller wrote:

 I think it's a matter of consistency. In Ruby blocks are used all the
 time for pretty much everything. In D this isn't the case because
 usually templates are used for stuff where blocks are used in Ruby
 (e.g.
 map, group and find in std.algorithm).


 I think that the templates that take a string as a predicate is just an
 ugly hack because D has a too verbose delegate syntax.


 I absolutely agree with that. However I don't have a better idea how to
 write it. Delegate syntax is already fairly compact in D.

 For example code as this isn't very uncommon in Ruby:

 [1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}

 Of course this is a simplified example. Usually the collection would
 contain some objects and the blocks would filter for a method call (like
 "e.even?"). However I built a small D1 struct that implements a select
 and collect function. With the unified function call synatax for array
 with code should actually work:

 [1, 2, 3, 4, 5].select((int e){ return e > 3; })
 .collect((int e){ return e*e; });

 It's already fairly compact. The main overhead is the parameter type and
 the return statement. I don't believe this can be reduced any more
 without breaking consistency of the language.


 Probably not, but, for example, Scala allows very compact delegate
 literals:

 Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)

 Or more verbose:

 Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)

 I'm not 100% sure I that the syntax is correct.


 Delegates are way more verbose in other languages like PHP and
 JavaScript (more or less the same syntax in both languages). Despite
 that it's no problem to use it and in case of jQuery it's used very
 often. I think the main reason why delegates are not used like that in D
 is performance. I'm really not sure about it but I suspect that
 delegates are less effective than code directly generated by a template
 like map!(). I don't know how efficient templates can integrate
 delegates so I just suspect that this is a performance problem.

 Happy programming
 Stephan Soller


 PHP has a very verbose delegate syntax with explicit closures, one of
 the many reasons I don't use PHP. JavaScript has quite similar syntax as
 D but the "function" keyword is required, I try to use CoffeeScript
 (compiles to javascript), which has a lot nicer delegate syntax, as
 often I can.

 D(dmd) needs to be able to inline delegates.


 I'm not so much concerned about verbose delegate syntax. Personally I
 don't mind using the current delegate syntax with templates like map!.
 However I'm concerned about performance and parameter order. Does
 someone know how delegates within templates are handled? I looked at the
 source of std.algorithm and std.functional but I'm still not sure what
 actually happens if you call something like

 auto ary = [1, 2, 3];
 map!((e){ return e*e; })(ary);

 I can't test this code right now since I don't have a D2 compiler
 installed at this computer but the std.algorithm source contains unit
 tests with delegates.

 If that now works with uniform function call syntax it could be written
 like that:

 auto ary = [1, 2, 3];
 ary.map!((e){ return e*e; });

 I don't know if chaining of such calls is possible but the above syntax
 is already pretty good. Sure, it's not perfect and the "return" still is
 some overhead, but I don't think it needs work. What's more important
 (at least for me) is the chaining ability and how performant such
 delegates actually are. From what I understood from std.functional it
 wraps string expressions in delegates anyway so using

 ary.map!("a*a");

 is not more efficient. Please correct me if I'm wrong! The
 std.functional code is definitely above my understanding.


I would though it just mixed in the string with some other code to make 
a complete expression.


 So, _if_ we can figure out a way to do some nice chaining of such calls
 we can get:

 [1, 2, 3, 4, 5].filter!((e){ return e > 3; })
 .map!((e){ return e*e; });

 Or if you don't like delegates and don't mind obvious compile time black
 magic:

 [1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");

 I think if chaining would work like that D would already be pretty close
 to the expressive power of Ruby. It's just that this kind of programming
 is very dependent on the ability of built in collections and libraries
 that allow such a programming style.

 Happy programming
 Stephan Soller


-- 
/Jacob Carlborg
Dec 16 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 16.12.2010 20:01, Jacob Carlborg wrote:

 On 2010-12-15 17:06, Stephan Soller wrote:

 On 14.12.2010 20:03, Jacob Carlborg wrote:
 …

What's more important
 (at least for me) is the chaining ability and how performant such
 delegates actually are. From what I understood from std.functional it
 wraps string expressions in delegates anyway so using

 ary.map!("a*a");

 is not more efficient. Please correct me if I'm wrong! The
 std.functional code is definitely above my understanding.


 I would though it just mixed in the string with some other code to make
 a complete expression.


It does that (would there be another way?). The question is if it 
creates an delegate with the expression or does it not built a delegate? 
The code in question starts at line 78 of std/functional.d[1] (that is 
the code related to unaryFun!()).

I'm really not sure what this code does…

[1]: 
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/functional.d#L78

Happy programming
Stephan Soller
Dec 17 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:ieg4c3$2o4q$1 digitalmars.com...

 On 16.12.2010 20:01, Jacob Carlborg wrote:

 On 2010-12-15 17:06, Stephan Soller wrote:

 On 14.12.2010 20:03, Jacob Carlborg wrote:
 .

What's more important
 (at least for me) is the chaining ability and how performant such
 delegates actually are. From what I understood from std.functional it
 wraps string expressions in delegates anyway so using

 ary.map!("a*a");

 is not more efficient. Please correct me if I'm wrong! The
 std.functional code is definitely above my understanding.


 I would though it just mixed in the string with some other code to make
 a complete expression.


 It does that (would there be another way?). The question is if it creates 
 an delegate with the expression or does it not built a delegate? The code 
 in question starts at line 78 of std/functional.d[1] (that is the code 
 related to unaryFun!()).

 I'm really not sure what this code does.

 [1]: 
 http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/functional.d#L78


I checked into this. The short answer is: It seems to generate an ordinary 
free-standing function (that gets passed around as various aliases), but not 
a delegate.

Overview:

1. In std.functional: The string gets mixed into a function named "result" 
that's inside the "unaryFunImpl" template, ie the code gets mixed into the 
free-standing function "unaryFunImpl.result()".

2. Then, "unaryFun" is an alias to "unaryFunImpl.result()".

3. In std.algorithm: "map()" is a function that simply calls the ctor of the 
"Map" struct, passing in the "unaryFunImpl.result" function as a template 
alias param that "Map" calls "fun".

4. Inside the "Map" struct, "fun" gets aliased to "_fun" for some reason, 
and then gets called at various points.

Some Details:

I took DMD 2.050, modified std/functional.d by changing this:

        static if (byRef)
        {
            Body!(ElementType).ReturnType result(ElementType)(ref 
ElementType a)
            {
                mixin(Body!(ElementType).code);
            }
        }
        else
        {
            Body!(ElementType).ReturnType result(ElementType)(ElementType 
__a)
            {
                mixin("alias __a "~parmName~";");
                mixin(Body!(ElementType).code);
            }
            // string mixme = "Body!(ElementType).ReturnType"
            //     " result(ElementType)(ElementType a)
            // { " ~ Body!(ElementType).code ~ " }";
            // mixin(mixme);
        }

...To this:

        static if (byRef)
        {
            Body!(ElementType).ReturnType result(ElementType)(ref 
ElementType a)
            {
                pragma(msg, "generated inside unaryFunImpl:");
                pragma(msg, Body!(ElementType).code);

                mixin(Body!(ElementType).code);
            }
        }
        else
        {
            Body!(ElementType).ReturnType result(ElementType)(ElementType 
__a)
            {
                pragma(msg, "generated inside unaryFunImpl:");
                pragma(msg, "alias __a "~parmName~";");
                pragma(msg, Body!(ElementType).code);

                mixin("alias __a "~parmName~";");
                mixin(Body!(ElementType).code);
            }
            // string mixme = "Body!(ElementType).ReturnType"
            //     " result(ElementType)(ElementType a)
            // { " ~ Body!(ElementType).code ~ " }";
            // mixin(mixme);
        }

All I changed was added the pragmas. Then I used it to compile this:

import std.algorithm;

void main()
{
    auto x = map!"a + 10"([1, 2, 3, 4]);
}

And the compiler's output was:

generated inside unaryFunImpl:
alias __a a;
return (a + 10);


So the result() function inside the unaryFunImpl template ends up looking 
like this:

Body!(ElementType).ReturnType result(ElementType)(ElementType __a)
{

    alias __a a;
    return (a + 10);
}


And then, as I described above, that function gets passed around via various 
aliases and then called directly.
Dec 17 2010
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
This is very serious. Walter and the rest always complain that C++ is very hard
to
understand, has a very long and verbose syntax and only "a few" can really
master
it. And look at that code. It's impossible to understand. One has to jump from
one
place to another, back and forth, wondering "Why that alias?" and so on. The
nested depth of curly braces go beyond four and five sometimes. Oh, wait. But I
can do "scope(exit) ..." and then I save myself one level.

So imagine if it takes all that effort to understand what it is written, how
hard
it should have been to write it. Probably it's the result of "this doesn't work,
let's try this as a hack" and everything ends up being a huge hack.

Please, please, please, look back at what you've done and think hard if it is
really the right way to go. Everything seems overly complex by now.

</just trying to help>
Dec 17 2010
next sibling parent reply so <so so.do> writes:
 Please, please, please, look back at what you've done and think hard if  
 it is
 really the right way to go. Everything seems overly complex by now.

 </just trying to help>


Can you name a single language as powerful and as expressive as D and  
doesn't have complexity?
Just name one, Walter and Andrei would be the first one to migrate that  
language i am sure.
Everyone on this thread must read the D overview on the main page.

People use this word "complexity" quite often. I don't think i get what  
they mean with that really.
Go write a big software using one of those so called "not so complex"  
languages and lets talk about this word complexity again.

Thank you.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 17 2010
parent reply Caligo <iteronvexor gmail.com> writes:
People have indeed designed and implemented very big software systems using
"one of those so called not so complex languages".
What people have not done is write anything meaningful of any size in D.
The main reason for that is that, after so many years, there is still no
decent D compiler, nothing near GCC quality, to be found.  For such a
complex language as D, there are sure too many compilers and "standard"
libraries, none of which are stable, up-to-date, or usable enough.  GCC is
the gold standard (for openness, quality, and user-base), and it seems D
won't make it in till 2012.  So, we're still years away from the "big D
software".  According to Ohloh, there is currently a total of 16 million
lines of code written in D.  Compare that to 70 million for Ruby, and 160
million for Python.  And that's only for open source projects that Ohloh
keeps track of.  The count is in billions for C/C++.

What I don't understand is this: how is it that Walter was able to implement
C++ all on his own from scratch, and yet D is having so many issues?  How
complex is D really?

2010/12/17 so <so so.do>


 Please, please, please, look back at what you've done and think hard if it

 is
 really the right way to go. Everything seems overly complex by now.

 </just trying to help>


 Can you name a single language as powerful and as expressive as D and
 doesn't have complexity?
 Just name one, Walter and Andrei would be the first one to migrate that
 language i am sure.
 Everyone on this thread must read the D overview on the main page.

 People use this word "complexity" quite often. I don't think i get what
 they mean with that really.
 Go write a big software using one of those so called "not so complex"
 languages and lets talk about this word complexity again.

 Thank you.

 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 17 2010
parent reply so <so so.do> writes:
On Sat, 18 Dec 2010 02:51:28 +0200, Caligo <iteronvexor gmail.com> wrote:


 People have indeed designed and implemented very big software systems  
 using
 "one of those so called not so complex languages".


Why don't you name one?
I obviously wasn't clear enough with "big software".
I don't know of any serious OS, game, <insert anything but text  
processing> written in anything except C/C++ (both complex languages).


 What people have not done is write anything meaningful of any size in D.
 The main reason for that is that, after so many years, there is still no
 decent D compiler, nothing near GCC quality, to be found.  For such a
 complex language as D, there are sure too many compilers and "standard"
 libraries, none of which are stable, up-to-date, or usable enough.  GCC  
 is
 the gold standard (for openness, quality, and user-base), and it seems D
 won't make it in till 2012.  So, we're still years away from the "big D
 software".  According to Ohloh, there is currently a total of 16 million
 lines of code written in D.  Compare that to 70 million for Ruby, and 160
 million for Python.  And that's only for open source projects that Ohloh
 keeps track of.  The count is in billions for C/C++.

 What I don't understand is this: how is it that Walter was able to  
 implement
 C++ all on his own from scratch, and yet D is having so many issues?  How
 complex is D really?


I completely agree with you, Walter is a superman.
But i guess he is not super enough, he couldn't even singlehandedly solve  
every programming issue known to man for last 50 years.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 17 2010
parent reply Caligo <iteronvexor gmail.com> writes:
Obviously you're not going to find an OS kernel that's written in Python or
Ruby, and just because it's an OS kernel doesn't necessarly mean it's that
big.  The Linux kernel is about 8 million, and about half of it is the
drivers.  The core is actually rather small (about 2 million).  Qt, on the
other hand, is well over 14 million lines of C/C++.  Things are very
different for an actual operating system, however.  Gentoo Linux is a great
example, and I've been using it for almost 10 years.  Portage, its package
management system, is over 1 million lines of bash; that's a lot for bash,
and portage is a very important part of the Gentoo OS (i.e., it's big).

"Big" doesn't necessarily have to be lines-of-code, and keep in mind that 5
lines of, say, Ruby code could easily translate into 50 lines of C++.  If a
software program plays an important role in people's lives, then I think it
could be considered big.  SCons is a medium-size project (100k of Python),
but it sure beats Make when it come to ease of use.  Interesting enough, the
Qt team is working on a new build tool to replace qmake, and JavaScript is
their primary choice for a programming language to do the job.

Another example is Emacs.  It's well over 1 million lines of Lisp.  Not to
start a religious war, but Emacs is by far one of the best, if not the best,
text editor out there.  It's much more than that.  I feel sorry for
developers who are constantly begging for IDEs for every new programming
language that comes out when all they need is Emacs.  You said to text
processing, so I'll stop.

IMO there is no honor in game development as it contributes nothing to
society.  I've rarely played any, so I won't be able to name too many, but I
do know about EVE Online.  Its core is in C++ as far as I know, but majority
of it is in Python.  In fact, I remember reading how CPP temporarily hired
Guido Rossum to help out because they were pushing Python to its limits.

Another example is Autodesk Maya.  The core is probably C/C++, but Maya
Embeded Language (MEL) plays a very big role.  In fact, at start-up, the
entire GUI is created by MEL scripts.  Maya by itself is probably one of the
most complex software programs out there, and in the early days a single
license used to cost close to 15k dollars (probably because of a niche
market and all the secrecy in the computer graphics industry).  Today it's
about half I think.  They've also recently added Python to it.  Maya has
been used in pretty much every motion picture in the last ten years or so,
and I don't see how special effects artists could have written all those
lines of code in C/C++ instead of MEL or Python.  The Foundry Nuke and Apple
Shake are other some examples.

So, I guess it's fair to say that sometimes large software programs are
written in multiple programming languages.  The core might be C/C++ because
of performance and efficiency, but everything else is some form of scripting
language.  I guess that goes to show that there is a right tool for any job,
and the guy in the Ruby video is wrong by implying that Ruby could be used
for anything.

BTW, I'm not trying to bash D in any way.  In fact I'm very excited about
it, and I want to see it succeed.  I'm a university student and C++ is my
main programming language.  I tried D1 about two years ago for the first
time, and that was with GDC (the old one).  Since then I haven't been able
to experience all the cool features in D2 because there are no stable D2
compilers available for my system.  I've tried compiling GDC from source
several times with different versions of GCC, but it always failed with an
error.  Spending a long time waiting for a compile to finish, and finally
failing is a big turnoff when you want to try something new.  I remember
when Go was announced, and it took me less than 5 minutes to clone the repo
and compile.  I was coding in Go in no time.  I still prefer D, but it's
little things like this that dictate whether or not a new programming
language gains traction quicker.  I think the day that I'm able to do 'git
clone git github.com:walter/d.git' or 'emerge gdc' is the day that D will be
ready :-)

I think I'm digressing.  I'll shut up now.

P.S.
I agree, C++ is a very complex language and I speak from experience.  But I
wouldn't say the same about C.  C is surely low-level, but not complex.
Based on my observation, the size of Python and C grammar are in the same
range, whereas Ruby is much more complex (someone graphed these, and I don't
know how accurate they are).  At first I was drawn to Ruby because of its
one-liners, but I soon realized that it kept reminding me of C++'s
complexity.  I don't like the idea of "more than one way to do the same
thing" in a programming language.  I think a natural language suffers from
this, and that is why, no matter how formal, your writings are almost always
open for interpretation.  Interesting enough, if you notice when you are
talking to someone you're not actually talking to them, but, rather, at
them.  That's probably why scientists use mathematics to communicate.  I
haven't touched Ruby in over a year now, and I've been learning Python in my
free time.

Peace!



2010/12/17 so <so so.do>


 On Sat, 18 Dec 2010 02:51:28 +0200, Caligo <iteronvexor gmail.com> wrote:

  People have indeed designed and implemented very big software systems

 using
 "one of those so called not so complex languages".


 Why don't you name one?
 I obviously wasn't clear enough with "big software".
 I don't know of any serious OS, game, <insert anything but text processing>
 written in anything except C/C++ (both complex languages).


  What people have not done is write anything meaningful of any size in D.

 The main reason for that is that, after so many years, there is still no
 decent D compiler, nothing near GCC quality, to be found.  For such a
 complex language as D, there are sure too many compilers and "standard"
 libraries, none of which are stable, up-to-date, or usable enough.  GCC is
 the gold standard (for openness, quality, and user-base), and it seems D
 won't make it in till 2012.  So, we're still years away from the "big D
 software".  According to Ohloh, there is currently a total of 16 million
 lines of code written in D.  Compare that to 70 million for Ruby, and 160
 million for Python.  And that's only for open source projects that Ohloh
 keeps track of.  The count is in billions for C/C++.

 What I don't understand is this: how is it that Walter was able to
 implement
 C++ all on his own from scratch, and yet D is having so many issues?  How
 complex is D really?


 I completely agree with you, Walter is a superman.
 But i guess he is not super enough, he couldn't even singlehandedly solve
 every programming issue known to man for last 50 years.


 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 17 2010
next sibling parent so <so so.do> writes:
 Peace!


I just got tired of some marketing nonsense and had to address my  
frustration!

Recently someone linked a blog post, guy was talking about i guess Python.
He was working on a large, high performance software which uses C++ for  
its highperf tasks.
This was going on for pages and guy was saying what a relief it has been.

He could have just said "We scripted our large, high performance software"  
and save the time for himself and his readers.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


I gotta jump on this as being a giant load of pretentous bullshit. First of 
all, there's the patently obvious "how in the world would you know?" 
considering the "I've rarely played any".

But more importantly, games make life suck less - I can't even imagine any 
more significant contribution to society than that. Even all of the endevors 
generally considered to be the biggest contributions to society are *only* 
significant contributions *because* that's exactly what they do: they make 
life suck less, and are therefore well-regarded.

Seriously, what up with all those presumptuous assholes out there (mostly 
baby boomer dinos and their even more anachronistic parents, interestingly 
enough) who have barely ever touched a videogame and yet figure they 
actually have reason to believe such absurd pretentous crap? Fuck, they all 
remind me of that pompous Roger Ebert douchebag. (Speaking of ways to 
benefit society, when's he finally gonna keel over? Isn't it about time by 
now? And speaking of "contributions to society" what the fuck's he ever 
done? Collect a salary just to spout off opinions? Fucking useless wanker.)
Dec 18 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:iej46p$424$1 digitalmars.com...

 "Caligo" <iteronvexor gmail.com> wrote in message 
 news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


 I gotta jump on this as being a giant load of pretentious bullshit. First 
 of all, there's the patently obvious "how in the world would you know?" 
 considering the "I've rarely played any".

 But more importantly, games make life suck less - I can't even imagine any 
 more significant contribution to society than that. Even all of the 
 endeavors generally considered to be the biggest contributions to society 
 are *only* significant contributions *because* that's exactly what they 
 do: they make life suck less, and are therefore well-regarded.

 Seriously, what up with all those presumptuous assholes out there (mostly 
 baby boomer dinos and their even more anachronistic parents, interestingly 
 enough) who have barely ever touched a videogame and yet figure they 
 actually have reason to believe such absurd pretentious crap? Fuck, they 
 all remind me of that pompous Roger Ebert douchebag. (Speaking of ways to 
 benefit society, when's he finally gonna keel over? Isn't it about time by 
 now? And speaking of "contributions to society" what the fuck's he ever 
 done? Collect a salary just to spout off opinions? Fucking useless 
 wanker.)


Since it apparently isn't obvious to some people: things don't have to be 
dull to qualify as a significant a contribution.
Dec 18 2010
parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 12/18/10 14:12, Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:iej46p$424$1 digitalmars.com...

 "Caligo" <iteronvexor gmail.com> wrote in message 
 news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


 I gotta jump on this as being a giant load of pretentious bullshit. First 
 of all, there's the patently obvious "how in the world would you know?" 
 considering the "I've rarely played any".

 But more importantly, games make life suck less - I can't even imagine any 
 more significant contribution to society than that. Even all of the 
 endeavors generally considered to be the biggest contributions to society 
 are *only* significant contributions *because* that's exactly what they 
 do: they make life suck less, and are therefore well-regarded.

 Seriously, what up with all those presumptuous assholes out there (mostly 
 baby boomer dinos and their even more anachronistic parents, interestingly 
 enough) who have barely ever touched a videogame and yet figure they 
 actually have reason to believe such absurd pretentious crap? Fuck, they 
 all remind me of that pompous Roger Ebert douchebag. (Speaking of ways to 
 benefit society, when's he finally gonna keel over? Isn't it about time by 
 now? And speaking of "contributions to society" what the fuck's he ever 
 done? Collect a salary just to spout off opinions? Fucking useless 
 wanker.)


 
 Since it apparently isn't obvious to some people: things don't have to be 
 dull to qualify as a significant a contribution.
 
 
 


There's also the classic example: a game was instrumental in the
development of UNIX.

http://en.wikipedia.org/wiki/Space_Travel_(video_game)

This wasn't arbitrary either; it was something Thompson wanted to do,
and he needed a better OS to do it in... so his toy got new polish.
Some of this polish became things we now take for granted and hardly
know how to live without (like a hierarchial filesystem).

Do I mean to say that without the game there would be no UNIX?  No; but
I do mean to say that games have *always* been a valuable tool for
finding the limits of systems, and for inspiring innovative ways to
expand those limits.

The same research and development that provided pixel shaders to game
developers, also provided them to medical imaging developers.  The same
that provided CPU technologies such as SSE to enable more complex
simulations in games, also provide for more complex simulations in
supercomputers.  And many of these sort of technologies were original
conceived just to make games more awesome.  Amazing.

So no, games in and of themselves don't contribute anything -- if you
don't count fun, and honestly, I do count it -- but they have been a
driving force behind a lot of innovation.

</rant>
-- Chris N-S
Dec 19 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Nicholson-Sauls:


 So no, games in and of themselves don't contribute anything -- if you
 don't count fun, and honestly, I do count it -- but they have been a
 driving force behind a lot of innovation.


Yet I hope Walter will not waste 6 hours every day *playing* World of warcraft
:-)

Bye,
bearophile
Dec 19 2010
next sibling parent Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 12/19/10 04:19, bearophile wrote:

 Christopher Nicholson-Sauls:
 

 So no, games in and of themselves don't contribute anything -- if you
 don't count fun, and honestly, I do count it -- but they have been a
 driving force behind a lot of innovation.


 
 Yet I hope Walter will not waste 6 hours every day *playing* World of warcraft
:-)
 
 Bye,
 bearophile



prev sibling  parent  spir <denis.spir gmail.com>  writes:


On Sun, 19 Dec 2010 05:19:50 -0500
bearophile <bearophileHUGS lycos.com> wrote:


 Yet I hope Walter will not waste 6 hours every day *playing* World of war=


craft :-)

rather The Battle for Wesnoth ;-)

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com



 Dec 19 2010



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Christopher Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
news:iekles$79e$1 digitalmars.com...

 On 12/18/10 14:12, Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:iej46p$424$1 digitalmars.com...

 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


 I gotta jump on this as being a giant load of pretentious bullshit. 
 First
 of all, there's the patently obvious "how in the world would you know?"
 considering the "I've rarely played any".

 But more importantly, games make life suck less - I can't even imagine 
 any
 more significant contribution to society than that. Even all of the
 endeavors generally considered to be the biggest contributions to 
 society
 are *only* significant contributions *because* that's exactly what they
 do: they make life suck less, and are therefore well-regarded.

 Seriously, what up with all those presumptuous assholes out there 
 (mostly
 baby boomer dinos and their even more anachronistic parents, 
 interestingly
 enough) who have barely ever touched a videogame and yet figure they
 actually have reason to believe such absurd pretentious crap? Fuck, they
 all remind me of that pompous Roger Ebert douchebag. (Speaking of ways 
 to
 benefit society, when's he finally gonna keel over? Isn't it about time 
 by
 now? And speaking of "contributions to society" what the fuck's he ever
 done? Collect a salary just to spout off opinions? Fucking useless
 wanker.)


 Since it apparently isn't obvious to some people: things don't have to be
 dull to qualify as a significant a contribution.


 There's also the classic example: a game was instrumental in the
 development of UNIX.

 http://en.wikipedia.org/wiki/Space_Travel_(video_game)

 This wasn't arbitrary either; it was something Thompson wanted to do,
 and he needed a better OS to do it in... so his toy got new polish.
 Some of this polish became things we now take for granted and hardly
 know how to live without (like a hierarchial filesystem).

 Do I mean to say that without the game there would be no UNIX?  No; but
 I do mean to say that games have *always* been a valuable tool for
 finding the limits of systems, and for inspiring innovative ways to
 expand those limits.

 The same research and development that provided pixel shaders to game
 developers, also provided them to medical imaging developers.  The same
 that provided CPU technologies such as SSE to enable more complex
 simulations in games, also provide for more complex simulations in
 supercomputers.  And many of these sort of technologies were original
 conceived just to make games more awesome.  Amazing.

 So no, games in and of themselves don't contribute anything -- if you
 don't count fun, and honestly, I do count it -- but they have been a
 driving force behind a lot of innovation.


Yea, and another thing is the matter of art in general: If you're an 
ultra-utilitarian like Christopher seems to be (and even most programmers 
aren't ultra-utilitarian), then art can be seen as lacking significant 
contribution to society. But if you do believe in the value of art and still 
cherry-pick videogames as dishonorable or lacking significant contribution, 
then you're just simply being a dumbfuck and an elitist (like Roger Ebert).



 Dec 19 2010



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


On 12/18/2010 10:03 PM, Nick Sabalausky wrote:

 "Caligo"<iteronvexor gmail.com>  wrote in message
 news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


 I gotta jump on this as being a giant load of pretentous bullshit. First of
 all, there's the patently obvious "how in the world would you know?"
 considering the "I've rarely played any".

 But more importantly, games make life suck less - I can't even imagine any
 more significant contribution to society than that. Even all of the endevors
 generally considered to be the biggest contributions to society are *only*
 significant contributions *because* that's exactly what they do: they make
 life suck less, and are therefore well-regarded.


I hear you! People please legalize drugs. They make my life suck so much 
less.


 Seriously, what up with all those presumptuous assholes out there (mostly
 baby boomer dinos and their even more anachronistic parents, interestingly
 enough) who have barely ever touched a videogame and yet figure they
 actually have reason to believe such absurd pretentous crap? Fuck, they all
 remind me of that pompous Roger Ebert douchebag. (Speaking of ways to
 benefit society, when's he finally gonna keel over? Isn't it about time by
 now? And speaking of "contributions to society" what the fuck's he ever
 done? Collect a salary just to spout off opinions? Fucking useless wanker.)


Countless hours of my life have gone to waste while I've been killing 
zergs and protos. Still, my life sucks so much less because of that 
gorgeous feeling the unpunished killing gives me. The only thing I keep 
regretting (at the rare moments when I am not high) is I could have 
created something useful instead. Maybe, yet another programming 
language, in which more cool games could have been written.



 Dec 19 2010



 next sibling parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


Seeing the enemy being literally eaten by hundreds of upgraded
zerglings has no comparison. :-)



 Dec 19 2010



  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 19/12/2010 14:21, Ary Borenszweig wrote:

 Seeing the enemy being literally eaten by hundreds of upgraded
 zerglings has no comparison. :-)


I'm more of a Protoss guy myself... Reaver drop FTW!
(I'll need to re-evaluate things with Starcraft II)


BTW, its funny to try to make some parallels between the races and 
languages:

Protoss == Java. Very powerful, teleports ready made structures from 
other dimensions (= all the libraries, middleware, app stack that is 
readily available). But still needs some setup (pylons). And very 
expensive in resources (slow), and very dependent on energy (GC-activity 
/ having enough free memory).

Humans == C++: also quite powerful, but dirty, smelly, crude, oily, 
smoke filled, patchy. Breaks often and needs constant repairs (SCV 
repairs, otherwise blows up in flames). Non elegant. Can mount a good 
defense/offense anywhere on the map (siege tanks, bunker forward build 
attacks). But not as agile.


Ruby == Zerg. Utter chaos. Units can evolve into other units (dynamic 
typing). Very good for rushes and early game attacks (= rapid 
application deploying, kekekeke Rails Rush, gg). Very fast, very agile 
(=agile). Nydus Canals = Monkey Patching (likes to break abstractions).

-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Max Samukha" <spambox d-coding.com> wrote in message 
news:iekuac$qrq$1 digitalmars.com...

 On 12/18/2010 10:03 PM, Nick Sabalausky wrote:

 "Caligo"<iteronvexor gmail.com>  wrote in message
 news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


 I gotta jump on this as being a giant load of pretentous bullshit. First 
 of
 all, there's the patently obvious "how in the world would you know?"
 considering the "I've rarely played any".

 But more importantly, games make life suck less - I can't even imagine 
 any
 more significant contribution to society than that. Even all of the 
 endevors
 generally considered to be the biggest contributions to society are 
 *only*
 significant contributions *because* that's exactly what they do: they 
 make
 life suck less, and are therefore well-regarded.


 I hear you! People please legalize drugs. They make my life suck so much 
 less.


Assuming you meant that as a sarcastic counter-example: There may be ways in 
which they make life suck less, but *overall*, they're generally considered 
to make life suck *more*. So the "make life suck less" rule still holds.

Although, if you meant it seriously then nevermind: The whole 
drug-legalization issue is one of the few debates I actively avoid :)



 Dec 19 2010



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


On 12/19/2010 09:48 PM, Nick Sabalausky wrote:



 Assuming you meant that as a sarcastic counter-example: There may be ways in
 which they make life suck less, but *overall*, they're generally considered
 to make life suck *more*. So the "make life suck less" rule still holds.

 Although, if you meant it seriously then nevermind: The whole
 drug-legalization issue is one of the few debates I actively avoid :)


I have no clear opinion about games, though I do believe they carry some 
similarity with drugs in the way they make a person neglect stuff 
important for his survival in the reality he was born into.



 Dec 20 2010



  parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com>  writes:


On 12/20/10 04:25, Max Samukha wrote:

 On 12/19/2010 09:48 PM, Nick Sabalausky wrote:
 


 Assuming you meant that as a sarcastic counter-example: There may be
 ways in
 which they make life suck less, but *overall*, they're generally
 considered
 to make life suck *more*. So the "make life suck less" rule still holds.

 Although, if you meant it seriously then nevermind: The whole
 drug-legalization issue is one of the few debates I actively avoid :)


 
 I have no clear opinion about games, though I do believe they carry some
 similarity with drugs in the way they make a person neglect stuff
 important for his survival in the reality he was born into.


That's a (sadly common) problem with people, though; not with games.
The same can be validly stated for television (which I usually avoid,
anyhow), sports, over-reliance on restaurants (a personal pet peeve),
and checking the D newsgroups... oh shi-

-- Chris N-S



 Dec 20 2010



  parent  Kagamin <spam here.lot>  writes:


Christopher Nicholson-Sauls Wrote:


 That's a (sadly common) problem with people, though; not with games.
 The same can be validly stated for television (which I usually avoid,
 anyhow), sports, over-reliance on restaurants (a personal pet peeve),
 and checking the D newsgroups... oh shi-


I hope Walter won't spend 6 hours per day checking the D newsgroups... :3



 Dec 20 2010



prev sibling next sibling parent reply Patrick Down <pat codemoon.com>  writes:


bearophile Wrote:

 Yet I hope Walter will not waste 6 hours every day *playing* World of warcraft
:-)


He does however write games sometimes: http://www.classicempire.com/



 Dec 19 2010



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Patrick Down wrote:

 bearophile Wrote:

 Yet I hope Walter will not waste 6 hours every day *playing* World of warcraft
:-)





 He does however write games sometimes: http://www.classicempire.com/


I've never played WoW, but I have played Empire, and let me tell you,
it wastes a lot more than 6 hours a day!

I've been hesitant to play another round after last time, when
I spent almost a full week just conquering the world. Got way
behind on my work.


I personally like the DOS version best. It reminds me so much
of some of my early games. Same beautiful graphics and easy
controls.



 Dec 19 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Adam D. Ruppe wrote:

 Patrick Down wrote:

 bearophile Wrote:

 Yet I hope Walter will not waste 6 hours every day *playing* World of warcraft
:-)




 

 He does however write games sometimes: http://www.classicempire.com/


 
 I've never played WoW, but I have played Empire, and let me tell you,
 it wastes a lot more than 6 hours a day!


Yes, Empire has been blamed for many students flunking out of university, and
at 
least one divorce!



 Dec 19 2010



prev sibling  parent  so <so so.do>  writes:


Games as worthless as movies and music or any kind of art.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Dec 19 2010



prev sibling next sibling parent reply Caligo <iteronvexor gmail.com>  writes:


You are absolutely right; life sucks for many people, and that's why some of
them choose to play video games.  It gives them a chance to escape reality,
and game companies exploit this to make money.  Game companies use all kinds
of psychology in their games to keep you playing as long as possible.  That
is why to me there is no honor in game development.  Also, I never said it's
worthless; they make tons of money, and that's almost always at the expense
of people like you.

If it helps any, I'm not one of those baby boomers.  I'm actually in my
early twenties.  So if you are going to insult me at least do it properly.

You sound way too angry and unhappy.  Instead of playing video games, you
should definitely pick up Ruby if you haven't already.  I hear it's
"designed to make programmers happy."



On Sat, Dec 18, 2010 at 2:03 PM, Nick Sabalausky <a a.a> wrote:


 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...

 IMO there is no honor in game development as it contributes nothing to
 society.  I've rarely played any,


 I gotta jump on this as being a giant load of pretentous bullshit. First of
 all, there's the patently obvious "how in the world would you know?"
 considering the "I've rarely played any".

 But more importantly, games make life suck less - I can't even imagine any
 more significant contribution to society than that. Even all of the
 endevors
 generally considered to be the biggest contributions to society are *only*
 significant contributions *because* that's exactly what they do: they make
 life suck less, and are therefore well-regarded.

 Seriously, what up with all those presumptuous assholes out there (mostly
 baby boomer dinos and their even more anachronistic parents, interestingly
 enough) who have barely ever touched a videogame and yet figure they
 actually have reason to believe such absurd pretentous crap? Fuck, they all
 remind me of that pompous Roger Ebert douchebag. (Speaking of ways to
 benefit society, when's he finally gonna keel over? Isn't it about time by
 now? And speaking of "contributions to society" what the fuck's he ever
 done? Collect a salary just to spout off opinions? Fucking useless wanker.)





 Dec 19 2010



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


Caligo:


 Game companies use all kinds
 of psychology in their games to keep you playing as long as possible.  That
 is why to me there is no honor in game development.  Also, I never said it's
 worthless; they make tons of money, and that's almost always at the expense
 of people like you.


Many games are like drugs. That's very bad. But people need to play too, and
there are instructive games too, for example games that develop your intuition
about how dynamic systems work (SimCity and its followers), there are some
smart games too. This is a game, but it's not so terrible for the mind of
people, it's not a bad drug:
http://armorgames.com/play/2205/light-bot

Bye,
bearophile



 Dec 19 2010



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


bearophile wrote:

 Many games are like drugs.


Not for me. I get bored with games. You don't get bored with drugs.



 Dec 19 2010



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


On 12/20/2010 08:43 AM, Walter Bright wrote:

 bearophile wrote:

 Many games are like drugs.


 Not for me. I get bored with games. You don't get bored with drugs.


You didn't play StarCraft when you were a teenager.



 Dec 20 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


"Max Samukha" <spambox d-coding.com> wrote in message 
news:ien42a$26q5$1 digitalmars.com...

 On 12/20/2010 08:43 AM, Walter Bright wrote:

 bearophile wrote:

 Many games are like drugs.


 Not for me. I get bored with games. You don't get bored with drugs.


 You didn't play StarCraft when you were a teenager.


I always got bored pretty quickly with RTSes. Pikmin's the only RTS that's 
held my attention for long, and it's very non-standard as far as RTSes go. 
I've always been more 2D platformer, 1990's single-player FPS, shmup, puzzle 
(not so much falling block though), action RPG, and adventure.



 Dec 20 2010



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.30.1292776925.4748.digitalmars-d puremagic.com...

 You are absolutely right; life sucks for many people, and that's why some 
 of
 them choose to play video games.  It gives them a chance to escape 
 reality,
 and game companies exploit this to make money.  Game companies use all 
 kinds
 of psychology in their games to keep you playing as long as possible. 
 That
 is why to me there is no honor in game development.  Also, I never said 
 it's
 worthless; they make tons of money, and that's almost always at the 
 expense
 of people like you.


The old "games as drugs" argument.

First of all, anyone who's a slave to psychological tricks is an idiot 
anyway. Casinos use many psychological tricks to induce addiction and yet 
most people are perfectly able to control themselves.

Secondly, if you see movies, music, comics and novels as the same 
"dishonorable escapism", then I'll grant that your reasoning is at least 
logically sound, even though you're in an extremely tiny minority on that 
viewpoint. If not, however, then you're whole argument crumbles into a giant 
pile of blatant bullshit, and clearly far too much of an imbicile to even 
continue discussing this with.


 If it helps any, I'm not one of those baby boomers.  I'm actually in my
 early twenties.  So if you are going to insult me at least do it properly.


Fine, but that does make you the exception.


 You sound way too angry and unhappy.


I just have no tolerance for such obvious lies and idiocy.


 Instead of playing video games, you
 should definitely pick up Ruby if you haven't already.  I hear it's
 "designed to make programmers happy."


I realize you mean that in jest, but I actually have been using Ruby (Rake) 
as the build system for a big web project. It gets the job done, but I'm not 
exactly impressed with it.



 Dec 19 2010



  parent  Christopher Nicholson-Sauls <ibisbasenji gmail.com>  writes:


On 12/19/10 14:00, Nick Sabalausky wrote:

 "Caligo" <iteronvexor gmail.com> wrote in message 
 news:mailman.30.1292776925.4748.digitalmars-d puremagic.com...

 You are absolutely right; life sucks for many people, and that's why some 
 of
 them choose to play video games.  It gives them a chance to escape 
 reality,
 and game companies exploit this to make money.  Game companies use all 
 kinds
 of psychology in their games to keep you playing as long as possible. 
 That
 is why to me there is no honor in game development.  Also, I never said 
 it's
 worthless; they make tons of money, and that's almost always at the 
 expense
 of people like you.


 
 The old "games as drugs" argument.
 
 First of all, anyone who's a slave to psychological tricks is an idiot 
 anyway. Casinos use many psychological tricks to induce addiction and yet 
 most people are perfectly able to control themselves.
 
 Secondly, if you see movies, music, comics and novels as the same 
 "dishonorable escapism", then I'll grant that your reasoning is at least 
 logically sound, even though you're in an extremely tiny minority on that 
 viewpoint. If not, however, then you're whole argument crumbles into a giant 
 pile of blatant bullshit, and clearly far too much of an imbicile to even 
 continue discussing this with.
 

 If it helps any, I'm not one of those baby boomers.  I'm actually in my
 early twenties.  So if you are going to insult me at least do it properly.


 
 Fine, but that does make you the exception.
 

 You sound way too angry and unhappy.


 
 I just have no tolerance for such obvious lies and idiocy.
 

 Instead of playing video games, you
 should definitely pick up Ruby if you haven't already.  I hear it's
 "designed to make programmers happy."


 
 I realize you mean that in jest, but I actually have been using Ruby (Rake) 
 as the build system for a big web project. It gets the job done, but I'm not 
 exactly impressed with it.
 


Take a look at Thor sometime.  It's a replacement for Rake, and for some
jobs can be better.  Rails/3.x is apparently adopting it (or has adopted
it... I haven't made the jump to 3 yet).

https://github.com/wycats/thor

-- Chris N-S



 Dec 20 2010



prev sibling next sibling parent  so <so so.do>  writes:


 You are absolutely right; life sucks for many people, and that's why  
 some of
 them choose to play video games.  It gives them a chance to escape  
 reality,
 and game companies exploit this to make money.  Game companies use all  
 kinds
 of psychology in their games to keep you playing as long as possible.   
 That
 is why to me there is no honor in game development.  Also, I never said  
 it's
 worthless; they make tons of money, and that's almost always at the  
 expense
 of people like you.


You are right saying games suck, since the new generation "games" are not  
games, they are just garbage "simulators".

But you should understand, for this kind of things there is always good  
and a bad practice.
Popularity favors bad practices better than good.
Can you say movies suck? or music in general? This is exactly same.

You guys gave an example to a very bad practice, a corporation, by  
definition(?) nothing but profit.
Now i am going to tell you about a good practice.

Outcast - Probably most of you never heard of it.

For me, it had everything that define a game.



 Dec 19 2010



prev sibling next sibling parent  Kagamin <spam here.lot>  writes:


Caligo Wrote:


 You are absolutely right; life sucks for many people, and that's why some of
 them choose to play video games.  It gives them a chance to escape reality,
 and game companies exploit this to make money.  Game companies use all kinds
 of psychology in their games to keep you playing as long as possible.  That
 is why to me there is no honor in game development.  Also, I never said it's
 worthless; they make tons of money, and that's almost always at the expense
 of people like you.


The fact is all humans build their own reality - yes - because they're not fond
of the raw nature. What you try to say is actually "Hey, they live different
lives! HATEHATEHATE!!!"



 Dec 20 2010



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


On 19/12/10 4:41 PM, Caligo wrote:

 You are absolutely right; life sucks for many people, and that's why
 some of them choose to play video games.  It gives them a chance to
 escape reality, and game companies exploit this to make money.  Game
 companies use all kinds of psychology in their games to keep you playing
 as long as possible.  That is why to me there is no honor in game
 development.


Some game developers do that. The vast majority do not. I don't think 
it's fair to insult developers in general based on the actions of a few. 
You might as well say there's no honor in software development because 
some people write viruses and other malware.



 Dec 21 2010



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


On Sun, Dec 19, 2010 at 5:41 PM, Caligo <iteronvexor gmail.com> wrote:

 You are absolutely right; life sucks for many people, and that's why some=


 of

 them choose to play video games.=A0 It gives them a chance to escape real=


ity,

 and game companies exploit this to make money.=A0 Game companies use all =


kinds

 of psychology in their games to keep you playing as long as possible.=A0 =


That

 is why to me there is no honor in game development.


This is bullshit.
Of course there are games with that goal (WoW, ...), but this doesn't make =
game
development in general "unhonorable". There are many games that are
not like this,
for example most single player only games.. you play them until the end or =
until
you can't get any further and that's it.. maybe you play them again in
the future, but
it's not like a constant addiction. (I'm not saying that multi player
games are generally
more "dangerous" or anything, single player games are just an example every=
body
should be able to comprehend)
There are also game developers who openly label games like WoW "unethical",
e.g. http://en.wikipedia.org/wiki/Jonathan_Blow



 Dec 19 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:mailman.37.1292790264.4748.digitalmars-d puremagic.com...

On Sun, Dec 19, 2010 at 5:41 PM, Caligo <iteronvexor gmail.com> wrote:

 You are absolutely right; life sucks for many people, and that's why some 
 of
 them choose to play video games. It gives them a chance to escape 
 reality,
 and game companies exploit this to make money. Game companies use all 
 kinds
 of psychology in their games to keep you playing as long as possible. 
 That
 is why to me there is no honor in game development.


This is bullshit.
Of course there are games with that goal (WoW, ...), but this doesn't make 
game
development in general "unhonorable". There are many games that are
not like this,
for example most single player only games.. you play them until the end or 
until
you can't get any further and that's it.. maybe you play them again in
the future, but
it's not like a constant addiction. (I'm not saying that multi player
games are generally
more "dangerous" or anything, single player games are just an example 
everybody
should be able to comprehend)
There are also game developers who openly label games like WoW "unethical",
e.g. http://en.wikipedia.org/wiki/Jonathan_Blow


Interesting. I don't think I would go so far as to claim that WoW was 
unethical...just "uninteresting" ;) But that's just me. This is at least one 
thing the videogame world does that I do consider unethical: 
Proprietary/Closed platforms. But that's not just a videogame thing, of 
course. I consider proprietary/closed platforms in general to be unethical. 
(Oh crap, I think I can feel myself turning into Stallman!)



 Dec 19 2010



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:ielrdu$2p8f$1 digitalmars.com...

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:mailman.37.1292790264.4748.digitalmars-d puremagic.com...

On Sun, Dec 19, 2010 at 5:41 PM, Caligo <iteronvexor gmail.com> wrote:

 You are absolutely right; life sucks for many people, and that's why 
 some of
 them choose to play video games. It gives them a chance to escape 
 reality,
 and game companies exploit this to make money. Game companies use all 
 kinds
 of psychology in their games to keep you playing as long as possible. 
 That
 is why to me there is no honor in game development.


This is bullshit.
Of course there are games with that goal (WoW, ...), but this doesn't make 
game
development in general "unhonorable". There are many games that are
not like this,
for example most single player only games.. you play them until the end or 
until
you can't get any further and that's it.. maybe you play them again in
the future, but
it's not like a constant addiction. (I'm not saying that multi player
games are generally
more "dangerous" or anything, single player games are just an example 
everybody
should be able to comprehend)
There are also game developers who openly label games like WoW 
"unethical",
e.g. http://en.wikipedia.org/wiki/Jonathan_Blow


 Interesting. I don't think I would go so far as to claim that WoW was 
 unethical...just "uninteresting" ;) But that's just me. This is at least 
 one thing the videogame world does that I do consider unethical: 
 Proprietary/Closed platforms. But that's not just a videogame thing, of 
 course. I consider proprietary/closed platforms in general to be 
 unethical. (Oh crap, I think I can feel myself turning into Stallman!)


s/This is at least one/There is at least one/



 Dec 19 2010



prev sibling  parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com>  writes:


On 12/19/10 14:52, Nick Sabalausky wrote:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:mailman.37.1292790264.4748.digitalmars-d puremagic.com...

 On Sun, Dec 19, 2010 at 5:41 PM, Caligo <iteronvexor gmail.com> wrote:

 You are absolutely right; life sucks for many people, and that's why some 
 of
 them choose to play video games. It gives them a chance to escape 
 reality,
 and game companies exploit this to make money. Game companies use all 
 kinds
 of psychology in their games to keep you playing as long as possible. 
 That
 is why to me there is no honor in game development.


 This is bullshit.
 Of course there are games with that goal (WoW, ...), but this doesn't make 
 game
 development in general "unhonorable". There are many games that are
 not like this,
 for example most single player only games.. you play them until the end or 
 until
 you can't get any further and that's it.. maybe you play them again in
 the future, but
 it's not like a constant addiction. (I'm not saying that multi player
 games are generally
 more "dangerous" or anything, single player games are just an example 
 everybody
 should be able to comprehend)
 There are also game developers who openly label games like WoW "unethical",
 e.g. http://en.wikipedia.org/wiki/Jonathan_Blow


 
 Interesting. I don't think I would go so far as to claim that WoW was 
 unethical...just "uninteresting" ;) But that's just me. This is at least one 
 thing the videogame world does that I do consider unethical: 
 Proprietary/Closed platforms. But that's not just a videogame thing, of 
 course. I consider proprietary/closed platforms in general to be unethical. 
 (Oh crap, I think I can feel myself turning into Stallman!)
 


(On the upside, that means you get to grow an epic beard.)



 Dec 20 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


"Christopher Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
news:ienfgr$2st6$1 digitalmars.com...

 On 12/19/10 14:52, Nick Sabalausky wrote:

 Interesting. I don't think I would go so far as to claim that WoW was
 unethical...just "uninteresting" ;) But that's just me. This is at least 
 one
 thing the videogame world does that I do consider unethical:
 Proprietary/Closed platforms. But that's not just a videogame thing, of
 course. I consider proprietary/closed platforms in general to be 
 unethical.
 (Oh crap, I think I can feel myself turning into Stallman!)


 (On the upside, that means you get to grow an epic beard.)


Heh, I actually do have a beard. Although it's not quite Stallman-level.



 Dec 20 2010



prev sibling  parent  Kagamin <spam here.lot>  writes:


Nick Sabalausky Wrote:


 Yea, and another thing is the matter of art in general: If you're an 
 ultra-utilitarian like Christopher seems to be (and even most programmers 
 aren't ultra-utilitarian), then art can be seen as lacking significant 
 contribution to society.


I think, the effect of art is quite tangible, so I see no reason to not call it
utilitarian.



 Dec 20 2010



prev sibling  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 18/12/2010 05:54, Caligo wrote:

 IMO there is no honor in game development as it contributes nothing to
 society.


You don't think entertainment contributes to society?


-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



prev sibling next sibling parent reply Don <nospam nospam.com>  writes:


Ary Borenszweig wrote:

 This is very serious. Walter and the rest always complain that C++ is very
hard to
 understand, has a very long and verbose syntax and only "a few" can really
master
 it. And look at that code. It's impossible to understand. One has to jump from
one
 place to another, back and forth, wondering "Why that alias?" and so on. The
 nested depth of curly braces go beyond four and five sometimes. Oh, wait. But I
 can do "scope(exit) ..." and then I save myself one level.
 
 So imagine if it takes all that effort to understand what it is written, how
hard
 it should have been to write it. Probably it's the result of "this doesn't
work,
 let's try this as a hack" and everything ends up being a huge hack.
 
 Please, please, please, look back at what you've done and think hard if it is
 really the right way to go. Everything seems overly complex by now.
 
 </just trying to help>


Completely agree, although note that a large fraction of the complexity 
of Phobos comes from workarounds for compiler bugs.
The language right now is IMHO *far* too complicated --  especially as 
regards to parameter passing (maybe everything else is OK, not sure).



 Dec 17 2010



  parent reply so <so so.do>  writes:


 Completely agree, although note that a large fraction of the complexity  
 of Phobos comes from workarounds for compiler bugs.
 The language right now is IMHO *far* too complicated --  especially as  
 regards to parameter passing (maybe everything else is OK, not sure).


Parameter passing is an important problem but D at least tries to provide  
a solution.
Until someone come with a better one, current solution will be the best.

Would you like that D ignore the situation like many(all?) others just to  
be called "not so complex" language? I believe not.

On the other hand i would like to see the same treatment for inlining.
Like adding a keyword (maybe "inline"), but unlike C++ hint this would be  
a forceinline which outputs an error if it is not possible.
I believe this would solve many problems.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Dec 17 2010



  parent  so <so so.do>  writes:


 On the other hand i would like to see the same treatment for inlining.
 Like adding a keyword (maybe "inline"), but unlike C++ hint this would  
 be a forceinline which outputs an error if it is not possible.
 I believe this would solve many problems.


Much better solution would be improving mixin.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/



 Dec 17 2010



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:iegfii$jub$1 digitalmars.com...

 This is very serious. Walter and the rest always complain that C++ is very 
 hard to
 understand, has a very long and verbose syntax and only "a few" can really 
 master
 it. And look at that code. It's impossible to understand. One has to jump 
 from one
 place to another, back and forth, wondering "Why that alias?" and so on. 
 The
 nested depth of curly braces go beyond four and five sometimes. Oh, wait. 
 But I
 can do "scope(exit) ..." and then I save myself one level.

 So imagine if it takes all that effort to understand what it is written, 
 how hard
 it should have been to write it. Probably it's the result of "this doesn't 
 work,
 let's try this as a hack" and everything ends up being a huge hack.

 Please, please, please, look back at what you've done and think hard if it 
 is
 really the right way to go. Everything seems overly complex by now.

 </just trying to help>


FWIW, I understood it fairly easily, only took a few minutes, and I wasn't 
already familiar with the code for those modules before. But any C++ with 
anything like templates or STL just leaves me completely lost, and I 
practically grew up on C/C++. Not saying there couldn't be improvements of 
course, but I think it's still a far cry from C++-level.



 Dec 18 2010



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ie341e$bru$1 digitalmars.com...

 On 12/12/10 6:44 AM, Jacob Carlborg wrote:
 [snip]

 Conclusion:

 D needs a better and nicer looking syntax for passing delegates to
 functions.

 Suggestion:

 If a function takes a delegate as its last parameter allow the delegate
 literal to be passed outside the parameter list, after the function
 call, and allow to drop the semicolon. Also allow type inference of the
 delegate parameters. Looking like this:

 foo(bar) {
 // do something with bar
 }

 If the function takes other arguments before the delegate I have two
 suggestions, either just have two parameter lists, each in its own pair
 of parentheses:

 foo(3, 'a')(bar) {
 // do something with bar
 }

 Or have two parameter lists in one pair of parentheses seperated by a
 semicolon:

 foo(3, 'a' ; bar) {
 // do something with bar
 }

 I think that the syntax I've used in these examples has previously been
 proposed.


 Yah, it's been discussed a couple of times in the past. Both Walter and 
 myself are favorable to finding a good, simple lowering that improves 
 syntax without adding burden to the person who learns the language.

 By the way, lowerings are great. Defining features as lowerings is a huge 
 win in language definition, ease of understanding, and correctness of 
 implementation. Features that have been implemented through lowering have 
 had very few bugs - e.g. scope() and the new operator overloading, which 
 was only a week's work.

 Getting back to finding a good lowering, consider:

 foreach (a, b ; c) stmt

 A Ruby syntactic equivalent that clarifies what belongs to the block and 
 what belongs to the invoker of the block is:

 c.each do |a, b|
   stmt
 end

 So a and b are passed to the block and each is a method of c (or more 
 general, each is a function called taking c as an argument). Going now 
 back to D, we can imagine the following lowering:

 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })

 This could and should be generalized for more parameters, which I'm sure 
 is very useful:

 fun (a, b ; c, d) stmt

 =>

 fun(c, d, (a, b) { stmt })

 Of course "fun" could be actually "obj.method".

 With this we have a compelling syntax that has semantics obtained via 
 lowering.


I'm still concerned about this inconsistency:

void foo1()
{
    foreach(a, b; c) {
        return; // Return from foo1
    }
}

void foo2()
{
    fun(a, b; c) {
        return; // Effectively a "continue;" even though the syntax suggests 
otherwise.
    }
}

And one consequence of that is that contrary to what has been said, this 
would *not* allow foreach to be implemented as a library function.

I can appreciate the difficulty of getting the delegate's flow control to be 
handled as expected, but I think going ahead with this sugar without 
addressing that in some way would be a mistake.



 Dec 12 2010



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


On 12/12/10 2:50 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:ie341e$bru$1 digitalmars.com...

 On 12/12/10 6:44 AM, Jacob Carlborg wrote:
 [snip]

 Conclusion:

 D needs a better and nicer looking syntax for passing delegates to
 functions.

 Suggestion:

 If a function takes a delegate as its last parameter allow the delegate
 literal to be passed outside the parameter list, after the function
 call, and allow to drop the semicolon. Also allow type inference of the
 delegate parameters. Looking like this:

 foo(bar) {
 // do something with bar
 }

 If the function takes other arguments before the delegate I have two
 suggestions, either just have two parameter lists, each in its own pair
 of parentheses:

 foo(3, 'a')(bar) {
 // do something with bar
 }

 Or have two parameter lists in one pair of parentheses seperated by a
 semicolon:

 foo(3, 'a' ; bar) {
 // do something with bar
 }

 I think that the syntax I've used in these examples has previously been
 proposed.


 Yah, it's been discussed a couple of times in the past. Both Walter and
 myself are favorable to finding a good, simple lowering that improves
 syntax without adding burden to the person who learns the language.

 By the way, lowerings are great. Defining features as lowerings is a huge
 win in language definition, ease of understanding, and correctness of
 implementation. Features that have been implemented through lowering have
 had very few bugs - e.g. scope() and the new operator overloading, which
 was only a week's work.

 Getting back to finding a good lowering, consider:

 foreach (a, b ; c) stmt

 A Ruby syntactic equivalent that clarifies what belongs to the block and
 what belongs to the invoker of the block is:

 c.each do |a, b|
    stmt
 end

 So a and b are passed to the block and each is a method of c (or more
 general, each is a function called taking c as an argument). Going now
 back to D, we can imagine the following lowering:

 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })

 This could and should be generalized for more parameters, which I'm sure
 is very useful:

 fun (a, b ; c, d) stmt

 =>

 fun(c, d, (a, b) { stmt })

 Of course "fun" could be actually "obj.method".

 With this we have a compelling syntax that has semantics obtained via
 lowering.


 I'm still concerned about this inconsistency:

 void foo1()
 {
      foreach(a, b; c) {
          return; // Return from foo1
      }
 }

 void foo2()
 {
      fun(a, b; c) {
          return; // Effectively a "continue;" even though the syntax suggests
 otherwise.
      }
 }

 And one consequence of that is that contrary to what has been said, this
 would *not* allow foreach to be implemented as a library function.

 I can appreciate the difficulty of getting the delegate's flow control to be
 handled as expected, but I think going ahead with this sugar without
 addressing that in some way would be a mistake.


Control flow inside the delegate can be addressed through a slightly 
more complicated lowering (the kind foreach already does). Probably 
break and continue should not be accepted because generally you can't 
expect all user-defined constructs to do iteration. Early returns should 
be easy to handle.

Andrei



 Dec 12 2010



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


Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 And one consequence of that is that contrary to what has been said, this
 would *not* allow foreach to be implemented as a library function.

 I can appreciate the difficulty of getting the delegate's flow control  
 to be
 handled as expected, but I think going ahead with this sugar without
 addressing that in some way would be a mistake.


 Control flow inside the delegate can be addressed through a slightly  
 more complicated lowering (the kind foreach already does). Probably  
 break and continue should not be accepted because generally you can't  
 expect all user-defined constructs to do iteration. Early returns should  
 be easy to handle.


void foo( string delegate( int ) );

string bar( ) {
     foo( 3; ) {
         return "a"; // Does this return "a" to foo, or from bar?
     }
}

-- 
Simen



 Dec 12 2010



prev sibling  parent  foobar <foo bar.com>  writes:


Andrei Alexandrescu Wrote:

[snip]


 Control flow inside the delegate can be addressed through a slightly 
 more complicated lowering (the kind foreach already does). Probably 
 break and continue should not be accepted because generally you can't 
 expect all user-defined constructs to do iteration. Early returns should 
 be easy to handle.
 
 Andrei


http://yehudakatz.com/2010/02/07/the-building-blocks-of-ruby/

This talks about the semantics of Ruby's blocks and shows that Ruby can
implement many language features such as "synchronized" by regular functions.
This can be done partly because returning from a block also returns from it's
enclosing function call. 



 Dec 12 2010



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2010-12-12 21:50, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:ie341e$bru$1 digitalmars.com...

 On 12/12/10 6:44 AM, Jacob Carlborg wrote:
 [snip]

 Conclusion:

 D needs a better and nicer looking syntax for passing delegates to
 functions.

 Suggestion:

 If a function takes a delegate as its last parameter allow the delegate
 literal to be passed outside the parameter list, after the function
 call, and allow to drop the semicolon. Also allow type inference of the
 delegate parameters. Looking like this:

 foo(bar) {
 // do something with bar
 }

 If the function takes other arguments before the delegate I have two
 suggestions, either just have two parameter lists, each in its own pair
 of parentheses:

 foo(3, 'a')(bar) {
 // do something with bar
 }

 Or have two parameter lists in one pair of parentheses seperated by a
 semicolon:

 foo(3, 'a' ; bar) {
 // do something with bar
 }

 I think that the syntax I've used in these examples has previously been
 proposed.


 Yah, it's been discussed a couple of times in the past. Both Walter and
 myself are favorable to finding a good, simple lowering that improves
 syntax without adding burden to the person who learns the language.

 By the way, lowerings are great. Defining features as lowerings is a huge
 win in language definition, ease of understanding, and correctness of
 implementation. Features that have been implemented through lowering have
 had very few bugs - e.g. scope() and the new operator overloading, which
 was only a week's work.

 Getting back to finding a good lowering, consider:

 foreach (a, b ; c) stmt

 A Ruby syntactic equivalent that clarifies what belongs to the block and
 what belongs to the invoker of the block is:

 c.each do |a, b|
    stmt
 end

 So a and b are passed to the block and each is a method of c (or more
 general, each is a function called taking c as an argument). Going now
 back to D, we can imagine the following lowering:

 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })

 This could and should be generalized for more parameters, which I'm sure
 is very useful:

 fun (a, b ; c, d) stmt

 =>

 fun(c, d, (a, b) { stmt })

 Of course "fun" could be actually "obj.method".

 With this we have a compelling syntax that has semantics obtained via
 lowering.


 I'm still concerned about this inconsistency:

 void foo1()
 {
      foreach(a, b; c) {
          return; // Return from foo1
      }
 }

 void foo2()
 {
      fun(a, b; c) {
          return; // Effectively a "continue;" even though the syntax suggests
 otherwise.
      }
 }

 And one consequence of that is that contrary to what has been said, this
 would *not* allow foreach to be implemented as a library function.

 I can appreciate the difficulty of getting the delegate's flow control to be
 handled as expected, but I think going ahead with this sugar without
 addressing that in some way would be a mistake.


This would need to be addressed. Perhaps a new keyword "yield"?

-- 
/Jacob Carlborg



 Dec 13 2010



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2010-12-12 19:23, Andrei Alexandrescu wrote:

 On 12/12/10 6:44 AM, Jacob Carlborg wrote:
 [snip]

 Conclusion:

 D needs a better and nicer looking syntax for passing delegates to
 functions.

 Suggestion:

 If a function takes a delegate as its last parameter allow the delegate
 literal to be passed outside the parameter list, after the function
 call, and allow to drop the semicolon. Also allow type inference of the
 delegate parameters. Looking like this:

 foo(bar) {
 // do something with bar
 }

 If the function takes other arguments before the delegate I have two
 suggestions, either just have two parameter lists, each in its own pair
 of parentheses:

 foo(3, 'a')(bar) {
 // do something with bar
 }

 Or have two parameter lists in one pair of parentheses seperated by a
 semicolon:

 foo(3, 'a' ; bar) {
 // do something with bar
 }

 I think that the syntax I've used in these examples has previously been
 proposed.


 Yah, it's been discussed a couple of times in the past. Both Walter and
 myself are favorable to finding a good, simple lowering that improves
 syntax without adding burden to the person who learns the language.

 By the way, lowerings are great. Defining features as lowerings is a
 huge win in language definition, ease of understanding, and correctness
 of implementation. Features that have been implemented through lowering
 have had very few bugs - e.g. scope() and the new operator overloading,
 which was only a week's work.

 Getting back to finding a good lowering, consider:

 foreach (a, b ; c) stmt

 A Ruby syntactic equivalent that clarifies what belongs to the block and
 what belongs to the invoker of the block is:

 c.each do |a, b|
 stmt
 end

 So a and b are passed to the block and each is a method of c (or more
 general, each is a function called taking c as an argument). Going now
 back to D, we can imagine the following lowering:


Actually in Ruby "each" would be a method of "c", everything in Ruby is 
an object (well almost).


 fun (a, b ; c) stmt

 =>

 fun(c, (a, b) { stmt })

 This could and should be generalized for more parameters, which I'm sure
 is very useful:

 fun (a, b ; c, d) stmt

 =>

 fun(c, d, (a, b) { stmt })

 Of course "fun" could be actually "obj.method".

 With this we have a compelling syntax that has semantics obtained via
 lowering.


 Andrei


I'm glad that you responded and also responded so positively. I hope we 
could get this in the language.

-- 
/Jacob Carlborg



 Dec 13 2010



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:ie2g72$1sf3$1 digitalmars.com...

 On 2010-12-11 18:21, Andrei Alexandrescu wrote:

 On 12/11/10 11:05 AM, so wrote:

 Not to hijack this one but on the other thread i asked why this is
 needed.
 I am not here asking for syntax or commanding phobos team to implement
 something, I just want to know about technical limitations and license
 issues, but got no answer to these.
 Why? Either i am labeled here as a troll (maybe something worse since my
 usage of English is not the best) or people here lack the vision (Oh
 vision here actually bad usage since this bad practice have been here
 forever, lack of eyesight would be the better definition)
 One another thing might be that the community finds this issue is not an
 important, (which makes me ask myself what you guys actually 
 developing).


 I don't think you're near the danger of being labeled as a troll. Would
 be great to focus the discussion a bit.

 For example, let's take a look at the code example given in the talk's
 first part that shows the beauty of Ruby. What does it look like in D?
 What can we do to make it look and behave better?


 Andrei


 If we take a look at the very first code example from the talk it looks 
 like this:

 account.people.each do |person|
     puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
     writeln(person.name);

 I guess this is the most natural translation into D. If we want to be 
 closer to the Ruby code which uses a block we can translate the code to 
 use a delegate like this:

 account.people.each((Person person) {
     writeln(person.name);
 });

 In my opinion this looks really ugly, D has no way of passing a delegate 
 to a function that looks good. If D could allow to pass a delegate to a 
 function outside the parameter list, after the function call, and had 
 better type inference it could look like this:

 account.people.each(person) {
     writeln(person.name);
 }

 The above code is very close to the original Ruby code the only 
 differences is that D uses {} and Ruby uses "do" and "end".


There's one important difference you missed. Granted, it's not applicable in 
that particular example, but more generally, it's important:

int foo()
{
    foreach (person ; account.people)
    {
        writeln(person.name);
        if(blah)
            return 7; // Returns from foo
    }
}


int bar()
{
    account.people.each((Person person) {
        writeln(person.name);
        if(blah)
            return 7; // Only tries to return from the delegate
    });
}

In D, there is currently no way to convert "foo()" above to use a delgate 
(at least not without odd contorsions). So if we were to make syntax sugar 
for "bar()", it would get really confusing:

int bar2()
{
    account.people.each(Person person)
    {
        writeln(person.name);
        if(blah)
            return 7; // Only returns from the delegate, not bar2!! WTF?!
    }
}

There are similar issues with break, continue, and probably goto.

In Ruby, the syntax sugar works out fine because you can make it work it 
either way. You can create something that behaves like a delegate ("return" 
only returns from the delegate), or you can create something that is treated 
as part of the function it's declared within ("return" unwinds the stack and 
returns from the function that created it). (Although Ruby leaves the choice 
up the the caller. I'm not entirely convinced that's the right way to do 
it.)

D would need something similar for "passing a delegate" sugar to work out 
sensibly. One idea is to say that if-and-only-if the "sugar" is used, it's 
considered part of the original function that declared it rather than being 
a true degelate. The function that takes the "sugared delegate" must declare 
that it takes a "sugared delegate" instead of a normal one so that it can 
make sure not to do this:

doSomething();
callSugaredDelegateThatMightUnwindTheStackEvenWithoutThrowing();
doCleanup();



 Dec 12 2010



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2010-12-12 19:27, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:ie2g72$1sf3$1 digitalmars.com...

 On 2010-12-11 18:21, Andrei Alexandrescu wrote:

 On 12/11/10 11:05 AM, so wrote:

 Not to hijack this one but on the other thread i asked why this is
 needed.
 I am not here asking for syntax or commanding phobos team to implement
 something, I just want to know about technical limitations and license
 issues, but got no answer to these.
 Why? Either i am labeled here as a troll (maybe something worse since my
 usage of English is not the best) or people here lack the vision (Oh
 vision here actually bad usage since this bad practice have been here
 forever, lack of eyesight would be the better definition)
 One another thing might be that the community finds this issue is not an
 important, (which makes me ask myself what you guys actually
 developing).


 I don't think you're near the danger of being labeled as a troll. Would
 be great to focus the discussion a bit.

 For example, let's take a look at the code example given in the talk's
 first part that shows the beauty of Ruby. What does it look like in D?
 What can we do to make it look and behave better?


 Andrei


 If we take a look at the very first code example from the talk it looks
 like this:

 account.people.each do |person|
      puts person.name
 end

 You could translate this in two ways when translating into D.
 First way:

 foreach (person ; account.people)
      writeln(person.name);

 I guess this is the most natural translation into D. If we want to be
 closer to the Ruby code which uses a block we can translate the code to
 use a delegate like this:

 account.people.each((Person person) {
      writeln(person.name);
 });

 In my opinion this looks really ugly, D has no way of passing a delegate
 to a function that looks good. If D could allow to pass a delegate to a
 function outside the parameter list, after the function call, and had
 better type inference it could look like this:

 account.people.each(person) {
      writeln(person.name);
 }

 The above code is very close to the original Ruby code the only
 differences is that D uses {} and Ruby uses "do" and "end".


 There's one important difference you missed. Granted, it's not applicable in
 that particular example, but more generally, it's important:

 int foo()
 {
      foreach (person ; account.people)
      {
          writeln(person.name);
          if(blah)
              return 7; // Returns from foo
      }
 }


 int bar()
 {
      account.people.each((Person person) {
          writeln(person.name);
          if(blah)
              return 7; // Only tries to return from the delegate
      });
 }

 In D, there is currently no way to convert "foo()" above to use a delgate
 (at least not without odd contorsions). So if we were to make syntax sugar
 for "bar()", it would get really confusing:

 int bar2()
 {
      account.people.each(Person person)
      {
          writeln(person.name);
          if(blah)
              return 7; // Only returns from the delegate, not bar2!! WTF?!
      }
 }

 There are similar issues with break, continue, and probably goto.

 In Ruby, the syntax sugar works out fine because you can make it work it
 either way. You can create something that behaves like a delegate ("return"
 only returns from the delegate), or you can create something that is treated
 as part of the function it's declared within ("return" unwinds the stack and
 returns from the function that created it). (Although Ruby leaves the choice
 up the the caller. I'm not entirely convinced that's the right way to do
 it.)

 D would need something similar for "passing a delegate" sugar to work out
 sensibly. One idea is to say that if-and-only-if the "sugar" is used, it's
 considered part of the original function that declared it rather than being
 a true degelate. The function that takes the "sugared delegate" must declare
 that it takes a "sugared delegate" instead of a normal one so that it can
 make sure not to do this:

 doSomething();
 callSugaredDelegateThatMightUnwindTheStackEvenWithoutThrowing();
 doCleanup();


Yes, absolutely correct, I totally forgot about this. D would need a way 
to return from the delegate and a way to return from the context where 
the delegate is called. Perhaps introduce a new keyword "yield"?

-- 
/Jacob Carlborg



 Dec 13 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:ie5n2o$2v7s$2 digitalmars.com...

 On 2010-12-12 19:27, Nick Sabalausky wrote:

 There's one important difference you missed. Granted, it's not applicable 
 in
 that particular example, but more generally, it's important:

 int foo()
 {
      foreach (person ; account.people)
      {
          writeln(person.name);
          if(blah)
              return 7; // Returns from foo
      }
 }


 int bar()
 {
      account.people.each((Person person) {
          writeln(person.name);
          if(blah)
              return 7; // Only tries to return from the delegate
      });
 }

 In D, there is currently no way to convert "foo()" above to use a delgate
 (at least not without odd contorsions). So if we were to make syntax 
 sugar
 for "bar()", it would get really confusing:

 int bar2()
 {
      account.people.each(Person person)
      {
          writeln(person.name);
          if(blah)
              return 7; // Only returns from the delegate, not bar2!! 
 WTF?!
      }
 }

 There are similar issues with break, continue, and probably goto.

 In Ruby, the syntax sugar works out fine because you can make it work it
 either way. You can create something that behaves like a delegate 
 ("return"
 only returns from the delegate), or you can create something that is 
 treated
 as part of the function it's declared within ("return" unwinds the stack 
 and
 returns from the function that created it). (Although Ruby leaves the 
 choice
 up the the caller. I'm not entirely convinced that's the right way to do
 it.)

 D would need something similar for "passing a delegate" sugar to work out
 sensibly. One idea is to say that if-and-only-if the "sugar" is used, 
 it's
 considered part of the original function that declared it rather than 
 being
 a true degelate. The function that takes the "sugared delegate" must 
 declare
 that it takes a "sugared delegate" instead of a normal one so that it can
 make sure not to do this:

 doSomething();
 callSugaredDelegateThatMightUnwindTheStackEvenWithoutThrowing();
 doCleanup();


 Yes, absolutely correct, I totally forgot about this. D would need a way 
 to return from the delegate and a way to return from the context where the 
 delegate is called. Perhaps introduce a new keyword "yield"?


I've been reminded in another branch of this thread that foreach/opApply 
already handles this issue, so that approach could probably just be copied. 
Ie with:

foreach(item; somethingWithOpApply)
{
    if(item.isItBoyant())
        return item;
}

The body gets converted to a delegate which gets passed to opApply, but the 
"return" still works as expected. I would be interested to hear how exactly 
that works though, particularly when returning something other than void.



 Dec 13 2010



 next sibling parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


This is how:

http://www.youtube.com/asterite#p/u/10/oAhrFQVnsrY



 Dec 13 2010



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:ie5r0q$86t$1 digitalmars.com...

 This is how:

 http://www.youtube.com/asterite#p/u/10/oAhrFQVnsrY


Cool :)

I don't use Eclipse because there's a lot I don't like about it for normal 
day-to-day coding, but I may install it with Descent and/or that other newer 
D plugin just as a secondary tool for doing that neat stuff.



 Dec 13 2010



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


Mon, 13 Dec 2010 14:23:24 -0500, Nick Sabalausky wrote:


 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message
 news:ie5r0q$86t$1 digitalmars.com...

 This is how:

 http://www.youtube.com/asterite#p/u/10/oAhrFQVnsrY


 
 Cool :)
 
 I don't use Eclipse because there's a lot I don't like about it for
 normal day-to-day coding, but I may install it with Descent and/or that
 other newer D plugin just as a secondary tool for doing that neat stuff.


Beware, the startup time might be unacceptable.



 Dec 13 2010



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 12/13/10, Ary Borenszweig <ary esperanto.org.ar> wrote:

 This is how:

 http://www.youtube.com/asterite#p/u/10/oAhrFQVnsrY


That is insanely cool, especially the mixin expansion part. Is this
functionality in DDT as well or only in Descent?



 Dec 13 2010



  parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


I think just in Descent. But it comes with a bonus pack: lots of bugs. :-P



 Dec 13 2010



  parent reply Paolo Invernizzi <arathorn NOSPAM.fastwebnet.it>  writes:


Also with bugs (the most hated is the *freeze* one), I'm still using Descent
every single day, to code in D in the company where I work.
By far it is the most productive and incredible D IDE (sorry Bruno, I *relly*
hope that DDT will catch up!).

/Paolo Invernizzi

Ary Borenszweig Wrote:


 I think just in Descent. But it comes with a bonus pack: lots of bugs. :-P





 Dec 13 2010



  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 13/12/2010 20:25, Paolo Invernizzi wrote:

 Also with bugs (the most hated is the *freeze* one), I'm still using Descent
every single day, to code in D in the company where I work.
 By far it is the most productive and incredible D IDE (sorry Bruno, I *relly*
hope that DDT will catch up!).


I'm hoping for that as well!

-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2010-12-13 20:04, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:ie5n2o$2v7s$2 digitalmars.com...

 On 2010-12-12 19:27, Nick Sabalausky wrote:

 There's one important difference you missed. Granted, it's not applicable
 in
 that particular example, but more generally, it's important:

 int foo()
 {
       foreach (person ; account.people)
       {
           writeln(person.name);
           if(blah)
               return 7; // Returns from foo
       }
 }


 int bar()
 {
       account.people.each((Person person) {
           writeln(person.name);
           if(blah)
               return 7; // Only tries to return from the delegate
       });
 }

 In D, there is currently no way to convert "foo()" above to use a delgate
 (at least not without odd contorsions). So if we were to make syntax
 sugar
 for "bar()", it would get really confusing:

 int bar2()
 {
       account.people.each(Person person)
       {
           writeln(person.name);
           if(blah)
               return 7; // Only returns from the delegate, not bar2!!
 WTF?!
       }
 }

 There are similar issues with break, continue, and probably goto.

 In Ruby, the syntax sugar works out fine because you can make it work it
 either way. You can create something that behaves like a delegate
 ("return"
 only returns from the delegate), or you can create something that is
 treated
 as part of the function it's declared within ("return" unwinds the stack
 and
 returns from the function that created it). (Although Ruby leaves the
 choice
 up the the caller. I'm not entirely convinced that's the right way to do
 it.)

 D would need something similar for "passing a delegate" sugar to work out
 sensibly. One idea is to say that if-and-only-if the "sugar" is used,
 it's
 considered part of the original function that declared it rather than
 being
 a true degelate. The function that takes the "sugared delegate" must
 declare
 that it takes a "sugared delegate" instead of a normal one so that it can
 make sure not to do this:

 doSomething();
 callSugaredDelegateThatMightUnwindTheStackEvenWithoutThrowing();
 doCleanup();


 Yes, absolutely correct, I totally forgot about this. D would need a way
 to return from the delegate and a way to return from the context where the
 delegate is called. Perhaps introduce a new keyword "yield"?


 I've been reminded in another branch of this thread that foreach/opApply
 already handles this issue, so that approach could probably just be copied.
 Ie with:

 foreach(item; somethingWithOpApply)
 {
      if(item.isItBoyant())
          return item;
 }

 The body gets converted to a delegate which gets passed to opApply, but the
 "return" still works as expected. I would be interested to hear how exactly
 that works though, particularly when returning something other than void.


That's probably why one has to mess with the result of the delegate in 
opApply and it's also probably why opApply is unnecessary complicated.

But if I want the other behavior, just return from the delegate, is it 
common enough to support both behaviors?

BTW have a look at the following code:

struct Foo
{
     string array = "0123456789";

     int opApply(int delegate(ref char) dg)
     {
         int result = 0;

         for (int i = 0; i < array.length; i++)
         {
             result = dg(array[i]);
             //if (result)
                 //break;
         }

         return result;
     }
}

void bar ()
{
     Foo foo;

     foreach (c ; foo)
     {
         if (c == '3')
             return;

         writeln(c);
     }
}

void main ()
{
     bar();
}

With the "break" commented out the foreach will just continue even with 
the return.

-- 
/Jacob Carlborg



 Dec 13 2010



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"so" <so so.do> wrote in message news:op.vnj620a17dtt59 so-pc...

 Why? Either i am labeled here as a troll (maybe something worse since my 
 usage of English is not the best)


You're definitely not a troll. Sometimes I have difficulty understanding 
what you mean, though. (But I can't complain - I've tried to learn another 
language (Japanese), but I'm terrible at it. Your English is certainly much 
better than my Japanese.)



 Dec 11 2010



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


so <so so.do> wrote:


 I am not here asking for syntax or commanding phobos team to implement  
 something, I just want to know about technical limitations and license  
 issues, but got no answer to these.
 Why? Either i am labeled here as a troll (maybe something worse since my  
 usage of English is not the best)


Your posts have at times come off as less than polite, but your knowledge
and insight have shown it to likely be caused merely by limited mastery of
the language.

-- 
Simen



 Dec 11 2010



prev sibling  parent  Jean Crystof <news news.com>  writes:


Don Wrote:


 Andrei Alexandrescu wrote:

 On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:

 On 12/10/10 19:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


 I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
 use the tool that feels best for the job, whatever that may be at a
 given time.  Sitting on a disc somewhere are some personal tools I used
 to use when working with D... which are themselves written in Ruby (and
 bash script, but hey).

 Then again, I'm the same one who really really likes Ruby on Rails...
 and yet still does most things with PHP.  Why?  Well for one, because
 for plenty of projects, Rails is less an aid and more a hindrance.  (And
 yes, before someone brings it up, I'm well aware of CakePHP... and don't
 care for it much.)

 There are times in D when I find myself wishing, momentarily, for the
 loose typing of Ruby... but then there are times in Ruby when I find
 myself wishing for stricter typing.

 There are times when I wish D had open classes... but then there are
 times when Ruby's open classes give me headaches.

 I could go on like this... but the point was really just: use the right
 tool for the job.  Keep several tools in your toolbox.  There is no "THE
 BEST LANGUAGE OMG!!!"  There is just the best one for a given programmer
 in a given scenario.  Some of the things I've done could probably have
 been better written in, say, Pike!  But I don't really know Pike (very
 well), and don't feel the need to learn it just for those few things
 that might have benefited.

 -- Chris N-S


 
 Agreed. One issue with the talk is non-acceptance of "the right tool for 
 the job" (the speaker literally says he's tired of that phrase). There 
 is one best tool - and that's Ruby. Ahem.
 
 Andrei


 
 I find this issue interesting. I think the "the right tool for the job"
 is justification for the existence of multiple languages, but on the 
 other hand, I'd agree with him that it's overused.
 
 If you consider all problem domains, and then ask: what is the minimum 
 number of languages required to be "the best tool" or "close enough to 
 the best tool" for all those jobs? For sure the minimum number is > 1.
 But I suspect the minimum isn't very high, essentially because most real 
 world tasks involve a combination of several problem domains.
 I think the minimum might be as small as five, and I seriously doubt 
 it's more than a dozen.


My wish is D supported all important paradigms in the future. It would make
other languages obsolete. D should at least support scripting, build tool
languages, systems programming (C++ like and assembly), application
programming, metaprogramming, functional, and DSL. The next version of D could

other common languages and make D invulnerable ultimate language.



 Dec 11 2010



prev sibling  parent reply Michael Stover <michael.r.stover gmail.com>  writes:


 LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
 must


compile with Visual Studio that the fact that C++ doesn't integrate with D
all

that well and the fact that you have to use dmc on Windows for the C or C++
code

if you want to link it with D code make it so that it doesn't make any sense
at

all to use D at this point.

Having to use the dmc compiler on windows in order to leverage legacy C++
code while being able to move on with new D code doesn't sound like too much
of a restriction.  Is there a similar tool that allows linking D and C++ on
linux and mac?

Mike

On Sat, Dec 11, 2010 at 3:32 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Saturday 11 December 2010 00:01:35 Andrei Alexandrescu wrote:

 On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:

 On 12/10/10 19:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


 I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
 use the tool that feels best for the job, whatever that may be at a
 given time.  Sitting on a disc somewhere are some personal tools I used
 to use when working with D... which are themselves written in Ruby (and
 bash script, but hey).

 Then again, I'm the same one who really really likes Ruby on Rails...
 and yet still does most things with PHP.  Why?  Well for one, because
 for plenty of projects, Rails is less an aid and more a hindrance.




  (And

 yes, before someone brings it up, I'm well aware of CakePHP... and




 don't

 care for it much.)

 There are times in D when I find myself wishing, momentarily, for the
 loose typing of Ruby... but then there are times in Ruby when I find
 myself wishing for stricter typing.

 There are times when I wish D had open classes... but then there are
 times when Ruby's open classes give me headaches.

 I could go on like this... but the point was really just: use the right
 tool for the job.  Keep several tools in your toolbox.  There is no




 "THE

 BEST LANGUAGE OMG!!!"  There is just the best one for a given




 programmer

 in a given scenario.  Some of the things I've done could probably have
 been better written in, say, Pike!  But I don't really know Pike (very
 well), and don't feel the need to learn it just for those few things
 that might have benefited.

 -- Chris N-S


 Agreed. One issue with the talk is non-acceptance of "the right tool for
 the job" (the speaker literally says he's tired of that phrase). There
 is one best tool - and that's Ruby. Ahem.


 LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
 must
 compile with Visual Studio that the fact that C++ doesn't integrate with D
 all
 that well and the fact that you have to use dmc on Windows for the C or C++
 code
 if you want to link it with D code make it so that it doesn't make any
 sense at
 all to use D at this point.

 And of course, there are plenty of cases where a particular language is
 just
 incredibly well suited for a particular job, and the best general purpose
 language just isn't as good.

 I think that it's good to strive to a have a language that is excellent for
 most
 use cases, but ultimately, you always have to pick the best tool for the
 job. No
 language is the best for all scenarios even if it's the best for most
 scenarios.

 - Jonathan M Davis





 Dec 11 2010



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Michael Stover" <michael.r.stover gmail.com> wrote in message 
news:mailman.900.1292075203.21107.digitalmars-d puremagic.com...

 LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
 must


 compile with Visual Studio that the fact that C++ doesn't integrate with D
 all

 that well and the fact that you have to use dmc on Windows for the C or 
 C++
 code

 if you want to link it with D code make it so that it doesn't make any 
 sense
 at

 all to use D at this point.

 Having to use the dmc compiler on windows in order to leverage legacy C++
 code while being able to move on with new D code doesn't sound like too 
 much
 of a restriction.  Is there a similar tool that allows linking D and C++ 
 on
 linux and mac?


AIUI, gcc will work. 



 Dec 11 2010



prev sibling  parent reply David Nadlinger <see klickverbot.at>  writes:


On 12/11/10 2:46 PM, Michael Stover wrote:

 Having to use the dmc compiler on windows in order to leverage legacy
 C++ code while being able to move on with new D code doesn't sound like
 too much of a restriction.  Is there a similar tool that allows linking
 D and C++ on linux and mac?


You don't need any »similar tool« for statically linking C with D code 
on Linux or Mac – DMD produces standard ELF resp. Mach-O code there.

The problem you mentioned exists just on Windows, where DMD 
unfortunately generates object files/libraries in the fairly obscure 
OMF, whereas most other compilers use the PE/COFF format.

I understand that Walter had reasons when he picked OMF for DMD 
(experience, compatibility with his own C++ compiler), but in practice 
this can be a huge pain – you can't ignore that MSVC is what everyone 
uses on Windows, plus MinGW for some open source projects, both of which 
use COFF for their object files.

Since switching to DMC is not at all trivial in many cases (reasons 
include the build systems, not being able to use any precompiled 
packages, non-standard extensions, …), the issue is often worked around 
by building a DLL out of the C/C++ code, which is then loaded at runtime.


David



 Dec 11 2010



  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


I've seen some tools that can convert OMF > COFF, but never the other
way around.

On 12/11/10, David Nadlinger <see klickverbot.at> wrote:

 On 12/11/10 2:46 PM, Michael Stover wrote:

 Having to use the dmc compiler on windows in order to leverage legacy
 C++ code while being able to move on with new D code doesn't sound like
 too much of a restriction.  Is there a similar tool that allows linking
 D and C++ on linux and mac?


 You don't need any =BBsimilar tool=AB for statically linking C with D cod=


e

 on Linux or Mac =96 DMD produces standard ELF resp. Mach-O code there.

 The problem you mentioned exists just on Windows, where DMD
 unfortunately generates object files/libraries in the fairly obscure
 OMF, whereas most other compilers use the PE/COFF format.

 I understand that Walter had reasons when he picked OMF for DMD
 (experience, compatibility with his own C++ compiler), but in practice
 this can be a huge pain =96 you can't ignore that MSVC is what everyone
 uses on Windows, plus MinGW for some open source projects, both of which
 use COFF for their object files.

 Since switching to DMC is not at all trivial in many cases (reasons
 include the build systems, not being able to use any precompiled
 packages, non-standard extensions, =85), the issue is often worked around
 by building a DLL out of the C/C++ code, which is then loaded at runtime.


 David





 Dec 11 2010



  parent reply David Nadlinger <see klickverbot.at>  writes:


On 12/11/10 8:18 PM, Andrej Mitrovic wrote:

 I've seen some tools that can convert OMF>  COFF, but never the other
 way around.


Well, there is e.g. »coff2omf« from DigitalMars, but I haven't had any 
success with it.

David



 Dec 11 2010



  parent  Don <nospam nospam.com>  writes:


David Nadlinger wrote:

 On 12/11/10 8:18 PM, Andrej Mitrovic wrote:

 I've seen some tools that can convert OMF>  COFF, but never the other
 way around.


 
 Well, there is e.g. »coff2omf« from DigitalMars, but I haven't had any 
 success with it.
 
 David


objconv (available at www.agner.org) now claims that it can do it, as of 
3 months ago.



 Dec 11 2010



prev sibling next sibling parent  spir <denis.spir gmail.com>  writes:


On Fri, 10 Dec 2010 20:31:38 -0500
"Adam D. Ruppe" <destructionator gmail.com> wrote:


 On Sat, Dec 11, 2010 at 01:26:01AM +0000, Ary Borenszweig wrote:

 http://vimeo.com/17420638


=20
 Is that a full hour of a guy preaching to the choir...
=20
 Got a summary?
=20

 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


=20
 But they are so beautiful! The lack of punctuation is one of the
 (many) reasons I hate working with Python and Ruby - the code
 is really hard to read.


"the code is really hard to read": People should stop thinking & feeling ev=
erybody should think & feel the way they do. To my eyes, most punctuation i=
n common PLs is noise --just noise. Python (and to some extent Ruby) code i=
s much easier to read _for me_ than D, C++, or Java code (*). Should I have=
 my brain repaired?


Denis

(*) Knowing my first langage (and the only one I have ever been trained for=
) was C, shouldn't it be the contrary?
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com



 Dec 11 2010



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


Ary Borenszweig wrote:

 http://vimeo.com/17420638
=20
 A very interesting talk.
=20
 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.
=20

 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.
=20
 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


	There is a major syntax issue with Ruby. This line:

foo(a, b)

does not mean the same thing as this line:

foo (a, b)

	!!WT?

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



 Dec 11 2010



 next sibling parent  spir <denis.spir gmail.com>  writes:


On Sat, 11 Dec 2010 10:29:20 +0100
"J=C3=A9r=C3=B4me M. Berger" <jeberger free.fr> wrote:


 	There is a major syntax issue with Ruby. This line:
=20
 foo(a, b)
=20
 does not mean the same thing as this line:
=20
 foo (a, b)
=20
 	!!WT?


It is an issue for us, because we are used to non-significant spacing. But =
non (yet) programmers instead expect _everything_ to be significant, includ=
ing spacing; more generally, they expect 2 different pieces of code to mean=
 something different for the machine (however irrelevant the difference to =
our trained eyes). The fact that in mainstream languages one can express th=
e same semantics using a wide variety of (very or slightly) distinct idioms=
 is highly confusing and unexpected (not only about spacing).

This is also contradictory to the well-know fact (everyone "knows" that) th=
at code for the machine must be written exactly (or copied exactly as is), =
that any tiny error may lead to a completely different process, and to a po=
tential calamity. Non-significant spacing also demands thinking about text =
as single-dimensional stream of terminals, which is both rather abstract an=
d opposite the obvious concrete 2-dimensional layout of text (code).

On the other hand, once one knows what a difference (like the one above) me=
ans, that's it. Simpler, easier, matches expectations.


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com



 Dec 11 2010



prev sibling  parent  Stephan Soller <stephan.soller helionweb.de>  writes:


On 11.12.2010 10:29, "Jérôme M. Berger" wrote:

 Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


 	There is a major syntax issue with Ruby. This line:

 foo(a, b)

 does not mean the same thing as this line:

 foo (a, b)

 	!!WT?

 		Jerome


Well, this is only a major syntax issue if you write Ruby code like you 
write C code (with many parenthesis). Usually method calls in Ruby don't 
contain any parenthesis:

	foo a, b

Parenthesis are only used if a parameter is an expression:

	foo (a + 1), b

Because of that coding style the above example is an rare edge case. I 
tried it in IRB (interactive Ruby console) and your two method calls 
actually do the same. The second one however generates a warning ("don't 
put space before argument parentheses").

ps.: For "foo (a, b)" to really screw up "," has to be a method defined 
on "a". I don't think that's possible in Ruby.

Happy programming
Stephan Soller



 Dec 13 2010



prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


On 12/10/2010 10:26 PM, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D. To write code in a high level while at the same
 time being very close to the machine, with class invariants, unit
 tests and many other features seemed very appealing. But I always
 felt there was something wrong.


 Python and D kind of ugly and uncomfortable. Why? Exactly because of
 what it is said in that video.

 This is not to start a flame war or trolling, it's just to show you
 why I changed my mind so much about D, and why I think (IMHO) you
 should care about naming conventions (like bearophile says), more
 powerful unittests (and not having unittests integrated into the
 language but rather being able to build your own test frameworks
 with ease) and stop caring about being C-syntax friendly. The world
 doesn't need that many semicolons and parenthesis. :-)


I guess what I liked about it (and Ruby) is that I see everything is 
very consistent and nice to my eyes. I never squeeze my brian to 
understand a piece of code, nor I had to deal with __some__strange 
variable names, or even __keywords.

Code is read many more times than it is written and so it is of huge 
important that code is as readable as possible. Of course this is a 
subjective matter, but I don't understand why some people think __traits 
or __gshared are ok. So what if those are compiler extensions or 
whatever? I don't want to stop thinking about those details of a 
programming language when I'm dealing with another problem. When I read 
Ruby code I feel like I'm reading an English textbook (better, a poem 
:-P), while why I read other languages I feel I'm reading... well, a 
programming language. And my head is so much better at reading text than 
reading machine code.

Then, other things in D like properties for which you do ++ don't work 
or such corner cases doesn't happen in Ruby. It's consistent. Once Ruby 
defines something, it does it well, not just half through it.

But yes, I agree with everyone here, the rest of the talk is not very 
serious...



 Dec 11 2010



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


Ary Borenszweig <ary esperanto.org.ar> wrote:

 Code is read many more times than it is written and so it is of huge  
 important that code is as readable as possible. Of course this is a  
 subjective matter, but I don't understand why some people think __traits  
 or __gshared are ok.


__gshared is ok. It is supposed to indicate low-level hackery and
unpleasant, rough edges. __traits, however, is an abomination and should
be shot repeatedly with something high-caliber.

-- 
Simen



 Dec 11 2010



  parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com>  writes:


Simen kjaeraas wrote:


 Ary Borenszweig <ary esperanto.org.ar> wrote:

 Code is read many more times than it is written and so it is of huge
 important that code is as readable as possible. Of course this is a
 subjective matter, but I don't understand why some people think __traits
 or __gshared are ok.


 
 __gshared is ok. It is supposed to indicate low-level hackery and
 unpleasant, rough edges. __traits, however, is an abomination and should
 be shot repeatedly with something high-caliber.
 


Is std.traits not sufficient for that? 



 Dec 12 2010



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


Lutger Blijdestijn <lutger.blijdestijn gmail.com> wrote:


 Simen kjaeraas wrote:


 Ary Borenszweig <ary esperanto.org.ar> wrote:

 Code is read many more times than it is written and so it is of huge
 important that code is as readable as possible. Of course this is a
 subjective matter, but I don't understand why some people think  
 __traits
 or __gshared are ok.


 __gshared is ok. It is supposed to indicate low-level hackery and
 unpleasant, rough edges. __traits, however, is an abomination and should
 be shot repeatedly with something high-caliber.


 Is std.traits not sufficient for that?


I have yet to see std.traits.compiles( some code ). There is a very nice
enhancement request in Bugzilla that __traits be replaces with a magic
namespace. meta.compiles( some code ) is heads and heels superior to
__traits( compiles, some code ). I've not checked if others of __traits'
capabilities are impossible to implement as templates.

It has also been suggested that __LINE__ and __FILE__ be stored in this
namespace, but I find that rather less likely to happen.

-- 
Simen



 Dec 12 2010



prev sibling  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 11/12/2010 13:53, Ary Borenszweig wrote:

 I guess what I liked about it (and Ruby) is that I see everything is
 very consistent and nice to my eyes. I never squeeze my brian to
 understand a piece of code, nor I had to deal with __some__strange
 variable names, or even __keywords.

 Code is read many more times than it is written and so it is of huge
 important that code is as readable as possible. Of course this is a
 subjective matter, but I don't understand why some people think __traits
 or __gshared are ok. So what if those are compiler extensions or
 whatever? I don't want to stop thinking about those details of a
 programming language when I'm dealing with another problem. When I read
 Ruby code I feel like I'm reading an English textbook (better, a poem
 :-P), while why I read other languages I feel I'm reading... well, a
 programming language. And my head is so much better at reading text than
 reading machine code.

 Then, other things in D like properties for which you do ++ don't work
 or such corner cases doesn't happen in Ruby. It's consistent. Once Ruby
 defines something, it does it well, not just half through it.



I see what with mean with consistency, and I agree with that. Especially 
in regards to criticism of D, yeah, there is a lot of stuff I think that 
could be simplified, removed, made consistent, cleaned, generalized, etc..

But I would never trade those downsides for a language with dynamic 
typing, not even close! And this regardless of whether the language is
systems programmings (like D), or not (like Java).

-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



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


On Saturday 11 December 2010 05:46:33 Michael Stover wrote:

 LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
 must


 
 compile with Visual Studio that the fact that C++ doesn't integrate with D
 all
 
 that well and the fact that you have to use dmc on Windows for the C or C++
 code
 
 if you want to link it with D code make it so that it doesn't make any
 sense at
 
 all to use D at this point.
 
 Having to use the dmc compiler on windows in order to leverage legacy C++
 code while being able to move on with new D code doesn't sound like too
 much of a restriction.  Is there a similar tool that allows linking D and
 C++ on linux and mac?


When your company has a whole pile of projects in C++, many of which are 
libraries which depend on other projects that you have, and most of them are
set 
up to be built automatically on a build server, it is _not_ trivial to use dmc. 
Virtually the whole enginerring department uses C++, and they all use 
Microsoft's compiler for the Windows builds. If you wanted to use dmc, you'd 
pretty much have to move them _all_ over to dmc, which is _not_ going to
happen. 
The Linux builds use gcc, and D links with gcc on Linux, so using D on Linux 
wouldn't be all that big a deal (though the interface to C++ could cause some 
issues), but most of what we do supposed to be cross platform, so it's going to 
have to build on Windows. So, unless it's a standalone project that doesn't 
depend on any others (which isn't very likely), there's no way that I'd be able 
to do it in D. If you could link D with Microsoft's compiler, or if dmc was
link 
campatible with Microsoft's compiler, then it could be done, but neither of 
those is the case.

- Jonathan M Davis



 Dec 11 2010



prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 12/11/10, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Saturday 11 December 2010 05:46:33 Michael Stover wrote:

 LOL. I'd _love_ to use D at work, but so much of our code is in C++ and
 must


 compile with Visual Studio that the fact that C++ doesn't integrate with D
 all

 that well and the fact that you have to use dmc on Windows for the C or
 C++
 code

 if you want to link it with D code make it so that it doesn't make any
 sense at

 all to use D at this point.

 Having to use the dmc compiler on windows in order to leverage legacy C++
 code while being able to move on with new D code doesn't sound like too
 much of a restriction.  Is there a similar tool that allows linking D and
 C++ on linux and mac?


 When your company has a whole pile of projects in C++, many of which are
 libraries which depend on other projects that you have, and most of them are
 set
 up to be built automatically on a build server, it is _not_ trivial to use
 dmc.
 Virtually the whole enginerring department uses C++, and they all use
 Microsoft's compiler for the Windows builds. If you wanted to use dmc, you'd
 pretty much have to move them _all_ over to dmc, which is _not_ going to
 happen.
 The Linux builds use gcc, and D links with gcc on Linux, so using D on Linux
 wouldn't be all that big a deal (though the interface to C++ could cause
 some
 issues), but most of what we do supposed to be cross platform, so it's going
 to
 have to build on Windows. So, unless it's a standalone project that doesn't
 depend on any others (which isn't very likely), there's no way that I'd be
 able
 to do it in D. If you could link D with Microsoft's compiler, or if dmc was
 link
 campatible with Microsoft's compiler, then it could be done, but neither of
 those is the case.

 - Jonathan M Davis


Maybe if we have any luck with SWIG we'll be able to make some
primitive wrappers for common C++ libraries. I'm just trying SWIG out
these days, but some people have reported success in wrapping some
libraries.



 Dec 11 2010



  parent reply David Nadlinger <see klickverbot.at>  writes:


On 12/11/10 8:06 PM, Andrej Mitrovic wrote:

 Maybe if we have any luck with SWIG we'll be able to make some
 primitive wrappers for common C++ libraries. I'm just trying SWIG out
 these days, but some people have reported success in wrapping some
 libraries.


While I certainly appreciate the advertisement, the OMF/COFF issue 
described in this thread is not fundamentally solved by SWIG. In fact, 
this is precisely the reason why SWIG by default generates code to 
dynamically bind the symbols from the wrapper DLL at run-time – contrary 
to static linking, you don't need object file compatibility then (the 
same approach is also used by other projects like Derelict and QtD).

David



 Dec 11 2010



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


On Saturday 11 December 2010 11:17:27 David Nadlinger wrote:

 On 12/11/10 8:06 PM, Andrej Mitrovic wrote:

 Maybe if we have any luck with SWIG we'll be able to make some
 primitive wrappers for common C++ libraries. I'm just trying SWIG out
 these days, but some people have reported success in wrapping some
 libraries.


=20
 While I certainly appreciate the advertisement, the OMF/COFF issue
 described in this thread is not fundamentally solved by SWIG. In fact,
 this is precisely the reason why SWIG by default generates code to
 dynamically bind the symbols from the wrapper DLL at run-time =E2=80=93 c=


ontrary

 to static linking, you don't need object file compatibility then (the
 same approach is also used by other projects like Derelict and QtD).


You don't need that compatability with dlls? _That_ I did not know. That wo=
uld=20
help a _lot_ in my case then, because most of our projects are shared libra=
ries.=20
It doesn't entirely solve the problem, but in this case, it's enough that i=
t may=20
make it feasible to actually do some stuff in D.

=2D Jonathan M Davis



 Dec 11 2010



  parent reply David Nadlinger <see klickverbot.at>  writes:


On 12/11/10 8:30 PM, Jonathan M Davis wrote:

 You don't need that compatability with dlls? _That_ I did not know. That would
 help a _lot_ in my case then, because most of our projects are shared
libraries.
 It doesn't entirely solve the problem, but in this case, it's enough that it
may
 make it feasible to actually do some stuff in D.


Yes, you don't need object file compatibility if you don't link in the 
DLL via an implib, but instead look up the symbols dynamically (e.g. via 
LoadLibrary/GetProcAddress on Windows).

If I remember correctly, there are some tools for generating OMF implibs 
as well, but they have never worked for me…

By the way, this reminds me that we desperately need solid 
cross-platform dynamic library support in Phobos – std.loader is 
undocumented, does not conform to the Phobos coding style, and exposes a 
very strange API (ExeModule is a scope class? WTF?). In SWIG, for 
example, I use a homegrown solution based on the loading code from 
Derelict2, but I'd very much prefer having this in Phobos.

This will probably get even more important if shared library support 
will eventually be added to DMD (When was this scheduled to happen 
again? After 64bit support and fixing the const system?).

David



 Dec 11 2010



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


On Saturday 11 December 2010 11:48:36 David Nadlinger wrote:

 On 12/11/10 8:30 PM, Jonathan M Davis wrote:

 You don't need that compatability with dlls? _That_ I did not know. That
 would help a _lot_ in my case then, because most of our projects are
 shared libraries. It doesn't entirely solve the problem, but in this
 case, it's enough that it may make it feasible to actually do some stuff
 in D.


=20
 Yes, you don't need object file compatibility if you don't link in the
 DLL via an implib, but instead look up the symbols dynamically (e.g. via
 LoadLibrary/GetProcAddress on Windows).
=20
 If I remember correctly, there are some tools for generating OMF implibs
 as well, but they have never worked for me=E2=80=A6
=20
 By the way, this reminds me that we desperately need solid
 cross-platform dynamic library support in Phobos =E2=80=93 std.loader is
 undocumented, does not conform to the Phobos coding style, and exposes a
 very strange API (ExeModule is a scope class? WTF?). In SWIG, for
 example, I use a homegrown solution based on the loading code from
 Derelict2, but I'd very much prefer having this in Phobos.
=20
 This will probably get even more important if shared library support
 will eventually be added to DMD (When was this scheduled to happen
 again? After 64bit support and fixing the const system?).


I expect that the loader would be fixed after shared library support in the=
=20
compiler was fixed. Shared library support was supposed to be after 64-bit=
=20
support, but there has been talk about fixing the const stuff next, so I do=
n't=20
know if shared library support is really going to happen immediately follow=
ing=20
64-bit support or not. It's high on the list though.

=2D Jonathan M Davis



 Dec 11 2010



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 12/11/10, David Nadlinger <see klickverbot.at> wrote:

 On 12/11/10 8:06 PM, Andrej Mitrovic wrote:

 Maybe if we have any luck with SWIG we'll be able to make some
 primitive wrappers for common C++ libraries. I'm just trying SWIG out
 these days, but some people have reported success in wrapping some
 libraries.


 While I certainly appreciate the advertisement, the OMF/COFF issue
 described in this thread is not fundamentally solved by SWIG. In fact,
 this is precisely the reason why SWIG by default generates code to
 dynamically bind the symbols from the wrapper DLL at run-time =96 contrar=


y

 to static linking, you don't need object file compatibility then (the
 same approach is also used by other projects like Derelict and QtD).

 David


Yeah, I know that. :) But using C++ DLL's in a D project isn't a walk
in the park, which is where SWIG can come in handy.



 Dec 11 2010



prev sibling next sibling parent reply Justin Johansson <noreply jj.com>  writes:


On 11/12/10 12:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.

 I used to like D....<cut/>


Just to be sure Ary, are you not the author behind "Descent", the
Eclipse Plugin for D?  Likely I am mistaken, but if not, this is
a bit of a wikileak for your former support of D?



 Dec 13 2010



  parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


Yes I am :-)

I stopped "supporting" D because it grew to be a very confusing and hard to
master
monster, with all those const, invariant and "this is not avaialble in the
language, but writing this function and using it in a way it works but it's very
unintuitive, we can have it" (like the mixin(yield("why do I have to write/read
so
much?")) or dont!shout_at_me("please")).

But... I know D is a very different and difficult to implement language, exactly
because everything has to be compiled to machine code and it must be really
efficient, so I still watch it, see it's progression and try to comment on
things
I like from other languages and how I would implement them in D (like the  mixin
attribute I commented in another post).

Sorry if sometimes I sound rude or angry, I can't be any of those because D owes
me nothing.



 Dec 13 2010



  parent reply Jeff Nowakowski <jeff dilacero.org>  writes:


On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


Since you were the Descent author, I wonder how you feel about Ruby's 
lack of static typing. In the video, the speaker bashes type safety as 
"having your balls fondled at the airport", that is, security theater 
that doesn't accomplish much.

But that misses many of the good features that come with it, especially 
in an IDE like Eclipse: code completion, find declaration, find 
references, rename refactoring, and compiler checked documentation.

Ruby is also one of the slowest languages around, and I'm sure some of 
that is due to the "freedom" it gives you, "freedom" being what the 
speaker calls no static typing and monkey patching.



 Dec 13 2010



 next sibling parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


Well, about a year ago I started programming in dynamic languages like python
and
Ruby. I did very little of python and a lot in Ruby. At first I thought "Hm, it
must be really hard to program without autocompletion, static type verification,
etc.". Soon I found out I was wrong.

First, in Ruby it's very easy to test the code. And you can do crazy things like
what I mention in here (
http://weblogs.manas.com.ar/ary/2010/04/15/quick-way-to-test-
any-values-in-ruby/ )

[[1, 1], [4, 2], [9, 3]].each do |input, output|

    assert_equal output, sqrt(input)
  end
end

and the good thing is that if it fails for a specific input/output pair it is
treated as a different test, so you can clearly see which input/output pair
failed. I can see you can do the same in D with string mixins, probably putting
all the code between do/end in a string... :-(

Second, I found out I have to type a lot less. And names are very consistent and
intuitive in Ruby and specially in Ruby on Rails, so I don't need that
autocompletion anymore, I can just type what my mind think is correct and it
works. And I do use some autocompletion, I switched to use gedit first, then
vim,
and it seems to be enough to autocomplete things based on the words on the open
documents.

And autocompletion might show you the list of methods of a class, but that's not
useful if you don't know how to use those methods in combination. For that, you
need to read the class' documentation about it's usage. And that, you can find
it
*a lot* in Ruby libraries. After all, what's important is how to use a class for
what you want to do, not what methods it provides. This concept is so strong in
Ruby that sometimes you just see things documented like "To use this, do
'basic_auth :user => x, :pass => b' without even caring about the signature of
the
method".

Third, go to declaration, I can do that in vim with ctrl+], using ctags.

Fourth, rename refactoring. That is the thing that is likely less to happen in a
project. The most common refactoring are logical, not just names. And after
refactoring by hand I just run the tests and fix whatever is there to fix. It
completely changed my mind about how to develop software (previously I also did
tests, but in Ruby I can test more things and much more easily... for instance,
I
can mock a static method or even a top level function, which I cannot do in D or
Java... so in those languages I have to do dependency injection and change a lot
the way I should be programming... making my code harder to understand and to
follow. In Ruby I can program directly what I want and still test it, always).

What do you mean by "compiler checked documentation"?

And Ruby might be slow(er than X), but when you program a website or something
where the database time or http request time is orders of magnitude higher, you
don't care the language to be a little slower. In the end you can never blame
the
language for your app being slow, you might to do load balancing, optimize your
queries, etc.

BUT. D is a systems programming language, so the above paragraph doesn't apply.
But I still think some things in D could be improved.



 Dec 13 2010



 next sibling parent  Jeff Nowakowski <jeff dilacero.org>  writes:


On 12/13/2010 10:37 AM, Ary Borenszweig wrote:

 Fourth, rename refactoring. That is the thing that is likely less to happen in
a
 project.


Actually, I do that quite a bit. I found that I renamed things a lot 
more when it became easy to do so. Before that I would tend to live with 
a name I didn't like any more.


 What do you mean by "compiler checked documentation"?


I mean the parameters to a method are documented, at least at the type 
level, and the compiler verifies it.

Anyways, thanks for sharing your experience. I'm not really sold, but 
maybe one day I'll give it a shot.



 Dec 13 2010



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:ie5ek1$2bn5$1 digitalmars.com...

 Well, about a year ago I started programming in dynamic languages like 
 python and
 Ruby. I did very little of python and a lot in Ruby. At first I thought 
 "Hm, it
 must be really hard to program without autocompletion, static type 
 verification,
 etc.". Soon I found out I was wrong.

 First, in Ruby it's very easy to test the code. And you can do crazy 
 things like
 what I mention in here (
 http://weblogs.manas.com.ar/ary/2010/04/15/quick-way-to-test-
any-values-in-ruby/ )

 [[1, 1], [4, 2], [9, 3]].each do |input, output|

    assert_equal output, sqrt(input)
  end
 end

 and the good thing is that if it fails for a specific input/output pair it 
 is
 treated as a different test, so you can clearly see which input/output 
 pair
 failed. I can see you can do the same in D with string mixins, probably 
 putting
 all the code between do/end in a string... :-(


That's why I refuse to use assert in unittests, and use a non-fatal 
alternative instead. There isn't a chance in hell I'm replacing:

------------------------------------------
unittest
{
    /*
    A few lines
    of setup
    for foo
    */

    assert(foo(/*arg set 1*/) == /*answer 1*/);
    assert(foo(/*arg set 2*/) == /*answer 2*/);
    assert(foo(/*arg set 3*/) == /*answer 3*/);
    assert(foo(/*arg set 4*/) == /*answer 4*/);
    assert(foo(/*arg set 5*/) == /*answer 5*/);

    /*
    A few lines
    of setup
    for bar
    */

    assert(bar(/*arg set 1*/) == /*answer 1*/);
    assert(bar(/*arg set 2*/) == /*answer 2*/);
    assert(bar(/*arg set 3*/) == /*answer 3*/);
    assert(bar(/*arg set 4*/) == /*answer 4*/);
    assert(bar(/*arg set 5*/) == /*answer 5*/);
}
------------------------------------------

...With this god-awful mess, or any equally-bad mixin-based alternative, 
just to get the damn thing to run all my tests:
------------------------------------------
/*
The declarations needed by
foo's unittests here
*/
void setupUnittestFoo()
{
    /*
    A few lines
    of setup
    for foo
    */
}

unittest { setupUnittestFoo() }
unittest { assert(foo(/*arg set 1*/) == /*answer 1*/); }
unittest { assert(foo(/*arg set 2*/) == /*answer 2*/); }
unittest { assert(foo(/*arg set 3*/) == /*answer 3*/); }
unittest { assert(foo(/*arg set 4*/) == /*answer 4*/); }
unittest { assert(foo(/*arg set 5*/) == /*answer 5*/); }

/*
The declarations needed by
bar's unittests here
*/
void setupUnittestBar()
{
    /*
    A few lines
    of setup
    for bar
    */
}

unittest { setupUnittestBar() }
unittest { assert(bar(/*arg set 1*/) == /*answer 1*/); }
unittest { assert(bar(/*arg set 2*/) == /*answer 2*/); }
unittest { assert(bar(/*arg set 3*/) == /*answer 3*/); }
unittest { assert(bar(/*arg set 4*/) == /*answer 4*/); }
unittest { assert(bar(/*arg set 5*/) == /*answer 5*/); }

------------------------------------------



 Dec 13 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:ie5n5t$2vuk$1 digitalmars.com...

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:ie5ek1$2bn5$1 digitalmars.com...

 Well, about a year ago I started programming in dynamic languages like 
 python and
 Ruby. I did very little of python and a lot in Ruby. At first I thought 
 "Hm, it
 must be really hard to program without autocompletion, static type 
 verification,
 etc.". Soon I found out I was wrong.

 First, in Ruby it's very easy to test the code. And you can do crazy 
 things like
 what I mention in here (
 http://weblogs.manas.com.ar/ary/2010/04/15/quick-way-to-test-
any-values-in-ruby/ )

 [[1, 1], [4, 2], [9, 3]].each do |input, output|

    assert_equal output, sqrt(input)
  end
 end

 and the good thing is that if it fails for a specific input/output pair 
 it is
 treated as a different test, so you can clearly see which input/output 
 pair
 failed. I can see you can do the same in D with string mixins, probably 
 putting
 all the code between do/end in a string... :-(


 That's why I refuse to use assert in unittests, and use a non-fatal 
 alternative instead. There isn't a chance in hell I'm replacing:

 ------------------------------------------
 unittest
 {
    /*
    A few lines
    of setup
    for foo
    */

    assert(foo(/*arg set 1*/) == /*answer 1*/);
    assert(foo(/*arg set 2*/) == /*answer 2*/);
    assert(foo(/*arg set 3*/) == /*answer 3*/);
    assert(foo(/*arg set 4*/) == /*answer 4*/);
    assert(foo(/*arg set 5*/) == /*answer 5*/);

    /*
    A few lines
    of setup
    for bar
    */

    assert(bar(/*arg set 1*/) == /*answer 1*/);
    assert(bar(/*arg set 2*/) == /*answer 2*/);
    assert(bar(/*arg set 3*/) == /*answer 3*/);
    assert(bar(/*arg set 4*/) == /*answer 4*/);
    assert(bar(/*arg set 5*/) == /*answer 5*/);
 }
 ------------------------------------------

 ...With this god-awful mess, or any equally-bad mixin-based alternative, 
 just to get the damn thing to run all my tests:
 ------------------------------------------
 /*
 The declarations needed by
 foo's unittests here
 */
 void setupUnittestFoo()
 {
    /*
    A few lines
    of setup
    for foo
    */
 }

 unittest { setupUnittestFoo() }
 unittest { assert(foo(/*arg set 1*/) == /*answer 1*/); }
 unittest { assert(foo(/*arg set 2*/) == /*answer 2*/); }
 unittest { assert(foo(/*arg set 3*/) == /*answer 3*/); }
 unittest { assert(foo(/*arg set 4*/) == /*answer 4*/); }
 unittest { assert(foo(/*arg set 5*/) == /*answer 5*/); }

 /*
 The declarations needed by
 bar's unittests here
 */
 void setupUnittestBar()
 {
    /*
    A few lines
    of setup
    for bar
    */
 }

 unittest { setupUnittestBar() }
 unittest { assert(bar(/*arg set 1*/) == /*answer 1*/); }
 unittest { assert(bar(/*arg set 2*/) == /*answer 2*/); }
 unittest { assert(bar(/*arg set 3*/) == /*answer 3*/); }
 unittest { assert(bar(/*arg set 4*/) == /*answer 4*/); }
 unittest { assert(bar(/*arg set 5*/) == /*answer 5*/); }

 ------------------------------------------


The reason I mention that, of course, is that with a non-fatal alternative 
to assert you can do like you said even without being able to put a 
"unittest{...}" inside a foreach:

unittest
{
    foreach(pair; [[1, 1], [4, 2], [9, 3]])
        nonFatalAssertEqual(pair[0], sqrt(pair[1]));
}



 Dec 13 2010



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


On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


By the way, I couldn't stop cringing at the distasteful, male-centric 
sexual jokes that the talk is peppered with. Wonder if there was any 
woman in the audience, and how she might have felt. And this is not a 
ghetto rant - it's the keynote of a major Ruby conference! (And I'm 
definitely not a prude.) Am I alone in thinking that this is not what 
our metier should evolve into?

Besides, the argument in favor of dynamic typing is one of the most 
disingenuous around. C is a language for consenting adults that gives 
you that kind of freedom. If we took the speaker's arguments to their 
logical conclusion, Ruby would be a language for people who don't care 
about correctness, despise efficiency, and have contempt for modularity.


 But that misses many of the good features that come with it, especially
 in an IDE like Eclipse: code completion, find declaration, find
 references, rename refactoring, and compiler checked documentation.

 Ruby is also one of the slowest languages around, and I'm sure some of
 that is due to the "freedom" it gives you, "freedom" being what the
 speaker calls no static typing and monkey patching.


Clearly focusing on one thing is easier when other concerns are reduced. 
D code has a lot more to worry about than Ruby code. That being said, 
I'm very glad about this discussion - we stand to learn from a variety 
of languages including Ruby.


Andrei



 Dec 13 2010



 next sibling parent  spir <denis.spir gmail.com>  writes:


On Mon, 13 Dec 2010 09:49:50 -0600
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 By the way, I couldn't stop cringing at the distasteful, male-centric=20
 sexual jokes that the talk is peppered with. Wonder if there was any=20
 woman in the audience, and how she might have felt. And this is not a=20
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm=20
 definitely not a prude.) Am I alone in thinking that this is not what=20
 our metier should evolve into?


You are not! (Thankfully, I can hardly understand talks by native english s=
peakers, so I did not watch this one.)

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com



 Dec 13 2010



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ie5fe7$2df7$1 digitalmars.com...

 On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


 By the way, I couldn't stop cringing at the distasteful, male-centric 
 sexual jokes that the talk is peppered with. Wonder if there was any woman 
 in the audience, and how she might have felt.


Not much of a danger of that, there's probably about 10 female programmers 
in the world anyway. I see no problem catering a talk to the people who are 
actually there rather than the people you think should be there.


 And this is not a ghetto rant - it's the keynote of a major Ruby 
 conference! (And I'm definitely not a prude.) Am I alone in thinking that 
 this is not what our metier should evolve into?


I didn't watch the video, but the only problem I see with the example above 
is the absurdity of implying that static typing is a useless bother. But I'm 
the kind of guy who finds Richard Pryor's stand-up funny rather than 
offensive.



 Dec 13 2010



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


Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful, male-centric 
 sexual jokes that the talk is peppered with. Wonder if there was any 
 woman in the audience, and how she might have felt. And this is not a 
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm 
 definitely not a prude.) Am I alone in thinking that this is not what 
 our metier should evolve into?


I thought the foul language, dirty jokes, etc., were inappropriate for a 
keynote. I had had enough and stopped watching about 2/3 of the way through.



 Dec 13 2010



prev sibling next sibling parent reply piotrek <starpit tlen.pl>  writes:


On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?
 
 
 Andrei


You're definitely not. No matter how strong pressure is, I stand and 
fight against common acceptance for female humiliation. It's so sad 
to me how many think they're real men while treating women as a things 
they can freely abuse. 

Cheers
Piotrek



 Dec 14 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"piotrek" <starpit tlen.pl> wrote in message 
news:ie8fu9$ejl$1 digitalmars.com...

 On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?


 Andrei


 You're definitely not. No matter how strong pressure is, I stand and
 fight against common acceptance for female humiliation. It's so sad
 to me how many think they're real men while treating women as a things
 they can freely abuse.


Didja hear the one about the blonde who couldn't find her pencil?



 Dec 14 2010



  parent reply lurker <lurk lurk.net>  writes:


Nick Sabalausky Wrote:


 "piotrek" <starpit tlen.pl> wrote in message 
 news:ie8fu9$ejl$1 digitalmars.com...

 On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?


 Andrei


 You're definitely not. No matter how strong pressure is, I stand and
 fight against common acceptance for female humiliation. It's so sad
 to me how many think they're real men while treating women as a things
 they can freely abuse.


 
 Didja hear the one about the blonde who couldn't find her pencil?


I have a bad sense of humor, but what is this if I'm trolling?



 Dec 14 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"lurker" <lurk lurk.net> wrote in message 
news:ie8rc3$27l1$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "piotrek" <starpit tlen.pl> wrote in message
 news:ie8fu9$ejl$1 digitalmars.com...

 On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?


 Andrei


 You're definitely not. No matter how strong pressure is, I stand and
 fight against common acceptance for female humiliation. It's so sad
 to me how many think they're real men while treating women as a things
 they can freely abuse.


 Didja hear the one about the blonde who couldn't find her pencil?


 I have a bad sense of humor, but what is this if I'm trolling?


Heh. It's me being an ass :)

But seriously, I'm not flaming anyone here, and really taking a round-about 
way to point out that there's too much "inventing things to be offended 
about" going on in the world. I still haven't looked at the video, so maybe 
some of the things really were worse than the example Andrei mentioned or 
the joke I referenced above, but *if* these things are the sorts of things 
that piotrek and Andrei find "offensive to women", then I'd have to call a 
big "bullshit, this is just inventing blatant assumptions and then getting 
offended by them".



 Dec 14 2010



  parent reply piotrek <starpit tlen.pl>  writes:


On Wed, 15 Dec 2010 02:53:40 -0500, Nick Sabalausky wrote:


 "lurker" <lurk lurk.net> wrote in message
 news:ie8rc3$27l1$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "piotrek" <starpit tlen.pl> wrote in message
 news:ie8fu9$ejl$1 digitalmars.com...

 On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful,
 male-centric sexual jokes that the talk is peppered with. Wonder if
 there was any woman in the audience, and how she might have felt.
 And this is not a ghetto rant - it's the keynote of a major Ruby
 conference! (And I'm definitely not a prude.) Am I alone in
 thinking that this is not what our metier should evolve into?


 Andrei


 You're definitely not. No matter how strong pressure is, I stand and
 fight against common acceptance for female humiliation. It's so sad
 to me how many think they're real men while treating women as a
 things they can freely abuse.


 Didja hear the one about the blonde who couldn't find her pencil?


 I have a bad sense of humor, but what is this if I'm trolling?


 
 Heh. It's me being an ass :)
 
 But seriously, I'm not flaming anyone here, and really taking a
 round-about way to point out that there's too much "inventing things to
 be offended about" going on in the world. I still haven't looked at the
 video, so maybe some of the things really were worse than the example
 Andrei mentioned or the joke I referenced above, but *if* these things
 are the sorts of things that piotrek and Andrei find "offensive to
 women", then I'd have to call a big "bullshit, this is just inventing
 blatant assumptions and then getting offended by them".


Firstly I apologize Andrei if I put him in bad light after hijacking his
sub-thread 
and then using it to add some personal opinion. Secondly I was referring to 
bigger picture of society and not only this video. And still I don't agree to 
"tolerate"* behavior which is based on so called "freedom". Because all you do 
has its consequence and interacts with "freedom" of other people and vice 
versa. Of course appropriate action should be used not exaggerated ones. 
And I had a peaceful intercommunication on my mind when speaking about
fighting ;) I can say as a Christian that respect for dignity goes along with
love. 
But your choice. And in the world the weak ones are abused all the time. 
I couldn't live pretending I don't see it. So one way is to give my opinion.
Not 
don't giving a shit.

Cheers
Piotrek



 Dec 15 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"piotrek" <starpit tlen.pl> wrote in message 
news:ieb3ik$1ri8$1 digitalmars.com...

 On Wed, 15 Dec 2010 02:53:40 -0500, Nick Sabalausky wrote:


 "lurker" <lurk lurk.net> wrote in message
 news:ie8rc3$27l1$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "piotrek" <starpit tlen.pl> wrote in message
 news:ie8fu9$ejl$1 digitalmars.com...

 On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:

 By the way, I couldn't stop cringing at the distasteful,
 male-centric sexual jokes that the talk is peppered with. Wonder if
 there was any woman in the audience, and how she might have felt.
 And this is not a ghetto rant - it's the keynote of a major Ruby
 conference! (And I'm definitely not a prude.) Am I alone in
 thinking that this is not what our metier should evolve into?


 Andrei


 You're definitely not. No matter how strong pressure is, I stand and
 fight against common acceptance for female humiliation. It's so sad
 to me how many think they're real men while treating women as a
 things they can freely abuse.


 Didja hear the one about the blonde who couldn't find her pencil?


 I have a bad sense of humor, but what is this if I'm trolling?


 Heh. It's me being an ass :)

 But seriously, I'm not flaming anyone here, and really taking a
 round-about way to point out that there's too much "inventing things to
 be offended about" going on in the world. I still haven't looked at the
 video, so maybe some of the things really were worse than the example
 Andrei mentioned or the joke I referenced above, but *if* these things
 are the sorts of things that piotrek and Andrei find "offensive to
 women", then I'd have to call a big "bullshit, this is just inventing
 blatant assumptions and then getting offended by them".


 Firstly I apologize Andrei if I put him in bad light after hijacking his 
 sub-thread
 and then using it to add some personal opinion. Secondly I was referring 
 to
 bigger picture of society and not only this video. And still I don't agree 
 to
 "tolerate"* behavior which is based on so called "freedom". Because all 
 you do
 has its consequence and interacts with "freedom" of other people and vice
 versa. Of course appropriate action should be used not exaggerated ones.
 And I had a peaceful intercommunication on my mind when speaking about
 fighting ;) I can say as a Christian that respect for dignity goes along 
 with love.
 But your choice. And in the world the weak ones are abused all the time.
 I couldn't live pretending I don't see it. So one way is to give my 
 opinion. Not
 don't giving a shit.


Yea, it's entirely possible that we have completely different sorts of 
things in mind when you're talking about "offensive" and when I'm talking 
about "not offensive".

I'll admit I was being a bit of an ass by referencing that joke as an 
attempt to guage whether or not it was the sort of thing you would find 
offensive. Should have just come out and asked "Is this the sort of thing 
you mean?" Feel free not to answer that though, I don't think either of us 
are feeling particularly inclined to end up in a heated debate about it 
today.



 Dec 15 2010



  parent  piotrek <starpit tlen.pl>  writes:


On Wed, 15 Dec 2010 17:13:48 -0500, Nick Sabalausky wrote:

 Feel free not to answer that though, I don't think
 either of us are feeling particularly inclined to end up in a heated
 debate about it today.


Yes, peace. I also understand you and agree that there's an issue with
overreactions. However I try to act somehow rationally  ;)

Cheers
Piotrek



 Dec 16 2010



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 13/12/2010 15:49, Andrei Alexandrescu wrote:

 On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?

 Besides, the argument in favor of dynamic typing is one of the most
 disingenuous around. C is a language for consenting adults that gives
 you that kind of freedom. If we took the speaker's arguments to their
 logical conclusion, Ruby would be a language for people who don't care
 about correctness, despise efficiency, and have contempt for modularity.



Ah, hold on a second. I agree the talk was rude and unprofessional (not 
that it was meant to be either), but I disagree it was sexist or 
offensive to women. Looking at the comment in question, "having your 
balls fondled at the airport", it's simply something that you cannot 
convey with anywhere the same meaning in a gender-neutral way ("having 
your gonads fondled at the airports"?... "having your genitals fondled 
at the airport"?... "having your crotch fondled at the airport"?...)
For better or worse, "balls" has become a metaphor for braveness, 
boldness, power, recklessness, (or a combination therefore), and has 
even been applied to women some times ("does she have the balls to do 
that?").

-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



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


On 12/21/10 2:38 PM, Bruno Medeiros wrote:

 On 13/12/2010 15:49, Andrei Alexandrescu wrote:

 On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?

 Besides, the argument in favor of dynamic typing is one of the most
 disingenuous around. C is a language for consenting adults that gives
 you that kind of freedom. If we took the speaker's arguments to their
 logical conclusion, Ruby would be a language for people who don't care
 about correctness, despise efficiency, and have contempt for modularity.



 Ah, hold on a second. I agree the talk was rude and unprofessional (not
 that it was meant to be either), but I disagree it was sexist or
 offensive to women. Looking at the comment in question, "having your
 balls fondled at the airport", it's simply something that you cannot
 convey with anywhere the same meaning in a gender-neutral way ("having
 your gonads fondled at the airports"?... "having your genitals fondled
 at the airport"?... "having your crotch fondled at the airport"?...)


You presuppose there's a need to stick with the original metaphor. There 
are many good metaphors to use, and there are a lot of good jokes around 
the "porn scanners".


 For better or worse, "balls" has become a metaphor for braveness,
 boldness, power, recklessness, (or a combination therefore), and has
 even been applied to women some times ("does she have the balls to do
 that?").


There are a lot of actually good jokes around that topic. I think this 
one, for example, is not gross at all: when describing the shortcomings 
of iterators, I mentioned "you have to have a pair to do anything". I 
delivered that with a straight face and it was really interesting to see 
the audience slowly getting the doublespeak and starting to laugh with 
various latencies. I am subjective but I think that one is firmly on the 
opposite side of a thin line than the "fondled balls" joke.


Andrei



 Dec 21 2010



  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 21/12/2010 21:24, Andrei Alexandrescu wrote:

 On 12/21/10 2:38 PM, Bruno Medeiros wrote:

 On 13/12/2010 15:49, Andrei Alexandrescu wrote:

 On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?

 Besides, the argument in favor of dynamic typing is one of the most
 disingenuous around. C is a language for consenting adults that gives
 you that kind of freedom. If we took the speaker's arguments to their
 logical conclusion, Ruby would be a language for people who don't care
 about correctness, despise efficiency, and have contempt for modularity.



 Ah, hold on a second. I agree the talk was rude and unprofessional (not
 that it was meant to be either), but I disagree it was sexist or
 offensive to women. Looking at the comment in question, "having your
 balls fondled at the airport", it's simply something that you cannot
 convey with anywhere the same meaning in a gender-neutral way ("having
 your gonads fondled at the airports"?... "having your genitals fondled
 at the airport"?... "having your crotch fondled at the airport"?...)


 You presuppose there's a need to stick with the original metaphor. There
 are many good metaphors to use, and there are a lot of good jokes around
 the "porn scanners".


 For better or worse, "balls" has become a metaphor for braveness,
 boldness, power, recklessness, (or a combination therefore), and has
 even been applied to women some times ("does she have the balls to do
 that?").


 There are a lot of actually good jokes around that topic. I think this
 one, for example, is not gross at all: when describing the shortcomings
 of iterators, I mentioned "you have to have a pair to do anything". I
 delivered that with a straight face and it was really interesting to see
 the audience slowly getting the doublespeak and starting to laugh with
 various latencies. I am subjective but I think that one is firmly on the
 opposite side of a thin line than the "fondled balls" joke.


 Andrei


I forgot part of my argument actually: Just as the "balls" metaphor has 
that meaning, conversely, "being grabbed by the balls" means kinda the 
opposite: being subjugated, dominated, restrained, kept-under-control, 
emasculated, etc.. So I think the "having your balls fondled at the 
airport" is a direct allusion to that metaphor, which goes in line with 
the talk's general theme of anti-authoritarianism.
So yes, I am presupposing there's a need to stick with the original 
metaphor. (in order to convey the subjugation meaning/allusion.)

-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



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


On 12/21/10 4:02 PM, Bruno Medeiros wrote:

 On 21/12/2010 21:24, Andrei Alexandrescu wrote:

 On 12/21/10 2:38 PM, Bruno Medeiros wrote:

 On 13/12/2010 15:49, Andrei Alexandrescu wrote:

 On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?

 Besides, the argument in favor of dynamic typing is one of the most
 disingenuous around. C is a language for consenting adults that gives
 you that kind of freedom. If we took the speaker's arguments to their
 logical conclusion, Ruby would be a language for people who don't care
 about correctness, despise efficiency, and have contempt for
 modularity.



 Ah, hold on a second. I agree the talk was rude and unprofessional (not
 that it was meant to be either), but I disagree it was sexist or
 offensive to women. Looking at the comment in question, "having your
 balls fondled at the airport", it's simply something that you cannot
 convey with anywhere the same meaning in a gender-neutral way ("having
 your gonads fondled at the airports"?... "having your genitals fondled
 at the airport"?... "having your crotch fondled at the airport"?...)


 You presuppose there's a need to stick with the original metaphor. There
 are many good metaphors to use, and there are a lot of good jokes around
 the "porn scanners".


 For better or worse, "balls" has become a metaphor for braveness,
 boldness, power, recklessness, (or a combination therefore), and has
 even been applied to women some times ("does she have the balls to do
 that?").


 There are a lot of actually good jokes around that topic. I think this
 one, for example, is not gross at all: when describing the shortcomings
 of iterators, I mentioned "you have to have a pair to do anything". I
 delivered that with a straight face and it was really interesting to see
 the audience slowly getting the doublespeak and starting to laugh with
 various latencies. I am subjective but I think that one is firmly on the
 opposite side of a thin line than the "fondled balls" joke.


 Andrei


 I forgot part of my argument actually: Just as the "balls" metaphor has
 that meaning, conversely, "being grabbed by the balls" means kinda the
 opposite: being subjugated, dominated, restrained, kept-under-control,
 emasculated, etc.. So I think the "having your balls fondled at the
 airport" is a direct allusion to that metaphor, which goes in line with
 the talk's general theme of anti-authoritarianism.
 So yes, I am presupposing there's a need to stick with the original
 metaphor. (in order to convey the subjugation meaning/allusion.)


I'd almost agree had the word "fondled" been absent :o).

Andrei



 Dec 21 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ier8i4$1db8$1 digitalmars.com...

 On 12/21/10 4:02 PM, Bruno Medeiros wrote:

 On 21/12/2010 21:24, Andrei Alexandrescu wrote:

 On 12/21/10 2:38 PM, Bruno Medeiros wrote:

 On 13/12/2010 15:49, Andrei Alexandrescu wrote:

 On 12/13/10 9:11 AM, Jeff Nowakowski wrote:

 On 12/13/2010 09:08 AM, Ary Borenszweig wrote:

 Yes I am :-)


 Since you were the Descent author, I wonder how you feel about Ruby's
 lack of static typing. In the video, the speaker bashes type safety 
 as
 "having your balls fondled at the airport", that is, security theater
 that doesn't accomplish much.


 By the way, I couldn't stop cringing at the distasteful, male-centric
 sexual jokes that the talk is peppered with. Wonder if there was any
 woman in the audience, and how she might have felt. And this is not a
 ghetto rant - it's the keynote of a major Ruby conference! (And I'm
 definitely not a prude.) Am I alone in thinking that this is not what
 our metier should evolve into?

 Besides, the argument in favor of dynamic typing is one of the most
 disingenuous around. C is a language for consenting adults that gives
 you that kind of freedom. If we took the speaker's arguments to their
 logical conclusion, Ruby would be a language for people who don't care
 about correctness, despise efficiency, and have contempt for
 modularity.



 Ah, hold on a second. I agree the talk was rude and unprofessional (not
 that it was meant to be either), but I disagree it was sexist or
 offensive to women. Looking at the comment in question, "having your
 balls fondled at the airport", it's simply something that you cannot
 convey with anywhere the same meaning in a gender-neutral way ("having
 your gonads fondled at the airports"?... "having your genitals fondled
 at the airport"?... "having your crotch fondled at the airport"?...)


 You presuppose there's a need to stick with the original metaphor. There
 are many good metaphors to use, and there are a lot of good jokes around
 the "porn scanners".


 For better or worse, "balls" has become a metaphor for braveness,
 boldness, power, recklessness, (or a combination therefore), and has
 even been applied to women some times ("does she have the balls to do
 that?").


 There are a lot of actually good jokes around that topic. I think this
 one, for example, is not gross at all: when describing the shortcomings
 of iterators, I mentioned "you have to have a pair to do anything". I
 delivered that with a straight face and it was really interesting to see
 the audience slowly getting the doublespeak and starting to laugh with
 various latencies. I am subjective but I think that one is firmly on the
 opposite side of a thin line than the "fondled balls" joke.


 Andrei


 I forgot part of my argument actually: Just as the "balls" metaphor has
 that meaning, conversely, "being grabbed by the balls" means kinda the
 opposite: being subjugated, dominated, restrained, kept-under-control,
 emasculated, etc.. So I think the "having your balls fondled at the
 airport" is a direct allusion to that metaphor, which goes in line with
 the talk's general theme of anti-authoritarianism.
 So yes, I am presupposing there's a need to stick with the original
 metaphor. (in order to convey the subjugation meaning/allusion.)


 I'd almost agree had the word "fondled" been absent :o).


This is what makes me question the existence of anti-female sexism in the 
joke: Replace the word "balls" with either "breasts" or any slang (or 
non-slang) term for female genitalia. Maybe replace the speaker with a 
woman, too, I don't care, either way. Or keep the word "balls" and make the 
speaker a woman. Any combination, whatever. Would that make it offensive to 
men? Maybe I'm just really weird as far as men go, but I honestly can't see 
how it would be. I certainly wouldn't take offense to it, no matter how you 
arranged the male/female-ness. But I can certainly imagine people that would 
still wave an "offensive to women" banner.

So unless I just have a really bad grasp of human behavior (and knowing me, 
I very well might), what we have is a situation where references to any 
gender-specific body part is offensive to...women and only women. Which 
triggers the "Reductio ad absurdum" flag in my mind.



 Dec 21 2010



  parent  Ary Borenszweig <ary esperanto.org.ar>  writes:


I agree with you.

We should ask a woman how she felt about that.



 Dec 22 2010



prev sibling  parent  spir <denis.spir gmail.com>  writes:


On Mon, 13 Dec 2010 10:11:15 -0500
Jeff Nowakowski <jeff dilacero.org> wrote:


 Ruby is also one of the slowest languages around, and I'm sure some of=20
 that is due to the "freedom" it gives you, "freedom" being what the=20
 speaker calls no static typing and monkey patching.


I wonder why there are so few dynamic & compiled languages.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com



 Dec 13 2010



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


Ary Borenszweig:


 D should provide a yield keyword that basically rewrites the body of the 
 method into the first code. What's that "if (result) break;"? That's 
 showing the implementation of foreach. Why do I have to rememebr the 
 result of dg? What's that? What if I forget it? I just want to yield two 
 elements :-(


Time ago I have asked for the "yield" syntax&semantics of Python in D too. It's
just syntax sugar for opApply. A syntax like:

yield(int) squares(int n) {
  foreach (i; 0 .. n)
    yield i * i;
}

Bye,
bearophile



 Dec 15 2010



prev sibling next sibling parent reply loser <noneedtotalkanymore to.me>  writes:


Andrei Alexandrescu Wrote:


 On 12/19/10 11:54 AM, foobar wrote:

 Andrei Alexandrescu Wrote:


 Either way, I personally don't care that much for another syntax for
delegates. I personally just want to see this ugly hack removed from the
standard library and discouraged. This feature promotes a code smell. And for
what, as you said yourself, to save 4 characters?


 "a>  b" vs. (a, b) { return a>  b; }

 Savings: 17 characters.


 I reserve the right to dislike it even if it was 20 characters. The fact that
it's a useful hack doesn't make it smell less.


 
 It doesn't smell. You believe it does only because you mistakenly 
 believe it's not hygienic.
 

 D should be consistent with only ONE delegate syntax. This is why Ruby reads
like poetry to its followers and c++ is like carving letters in stone.


 Also, Ruby is well slower than C++ and other languages. It's easy to
 design a beautiful language if that's the primary concern. It's
 difficult to design a language when you want to keep in harmony a larger
 list of desiderata.


 I much prefer that the lowering you mentioned to be implemented so that
performance wise this UGLY hack will have no benefits.


 The lowering will unfortunately solve little. I don't see how

 sort!"a>  b"(array);

 is horrible but

 sort(a, b; array) { return a>  b; }


 I wasn't referring to the above which still deals with the syntactic issue.
 I'm talking about making:

 sort!"a>b"(whatever);
 and
 sort(whatever, (a, b) { return a>b; });

 have the same performance. Thus obviating the need for the first form.


 
 I explained how this is much more difficult than it might seem at first 
 sight.


Your only argument was that it's more difficult because it's more difficult and
even the great lisp gods won't do that. Listen, we see through your bluff. Do I
need to list you the names of 10 functional language compilers that actually do
this optimization. It might even be the case that LDC optimizes this unlike DMD.



 Dec 19 2010



  parent  Caligo <iteronvexor gmail.com>  writes:


 Your only argument was that it's more difficult because it's more difficult
 and even the great lisp gods won't do that. Listen, we see through your
 bluff. Do I need to list you the names of 10 functional language compilers
 that actually do this optimization. It might even be the case that LDC
 optimizes this unlike DMD.



"Talk is cheap. Show me the code." --Linus Torvald



 Dec 19 2010



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 11/12/2010 01:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.


Whoa.

Over the last 5 years or so, with surge in popularity of dynamic 
languages like Ruby, Python, etc., I've seen several arguments put forth 
in favor of dynamic typing, and gradually I've always found there was a 
/subtle/ parallel with the arguments and reasons put forth for 
libertarian/anti-authoritarian/anti-corporate ideologies.
After seeing this talk, I guess it's not so subtle after all... ~_~'


Let me offer my thoughts on this. I don't think his argument is 
fundamentally rational. And I don't just mean wrong or illogical, I mean 
/irrational/: it is driven by an emotional bias of something not related 
to programmer productivity, which is what the discussion should be 
about. And I think his opinion is somewhat generally representative of 
many dynamic language proponents.

What I think is happening is this: These people, if and when they 
program on languages with static typing, they get annoyed by some (or 
all) of the aspects of static typing. That's normal so far, but now the 
problem is that while some of this annoyance may be driven from a 
genuine questioning of whether static typing is worth it or not (in 
usefulness and productivity), the rest of the annoyance is instead 
driven by an external emotional factor: if the language doesn't let you 
do something that it could easily let you do, then it is perceived as a 
"restriction of your freedoms". The programmer makes an emotional 
connection to personal issues unrelated to the field of programming. 
Another variant of this emotional response in this situation, and 
probably a much more common one, is not about political ideology, but 
rather the programmer perceives the language restriction to be part of a 
corporate culture that says that programmers are not smart enough to be 
fully trusted, and they need to be controlled to make sure they don't do 
stupid things. In other words the language thinks your are a dumb monkey 
who needs to be kept in line. Java is the poster child for this 
mentality, not only due to the language itself which is perceived to be 
simplistic, but also due to Java's strong association to the corporate 
and enterprise world. In a less extreme view, it is not about 
controlling stupidity, but controlling creativity (a view popular 
amongst "artist"/"painter" programmers). So here the programmers are not 
dumb, but still they need to be kept in line with rules, constraints, 
specifications, strict APIs, etc.. You can't do anything too strange or 
out of the ordinary, and the language is a reflection of that, 
especially with regards to restrictions on dynamic typing (and other 
dynamic stuff like runtime class modification).

Unfortunately this emotional response is often not fully conscious, or 
at least, it is not clearly expressed to others by the underlying 
programmer. And once this happens, _everything is lost from the 
beginning, in terms of trying to have a sensible debate._ Because from 
now on, these programmers will use half-baked arguments to try to 
justify their preference of dynamic languages. The arguments will be 
half-baked because they will try to argue in the area of effectiveness 
(programmer productivity), yet the main reason they like/dislike the 
language is the attitude of the language creators and/or community. 
(Interestingly enough, an incredibly similar cognitive-dissonance driven 
fallacy happens in discussions of actual political ideologies)

(Note, I'm not saying this is the case with all programmers, or even 
most, of the proponents of dynamic typing. In particular, nor I am 
saying it's the case with Ary :p )


BTW, for a while I was quite okay with this talk, because the author 
seemed to make clear what the liked about Ruby was the underlying 
attitude. He mentioned the language design goal of "making the 
programmer happy". He mentioned all those quirks of the community like 
the 'second' property, the 42 one, the cheerleaders at the convention, 
etc.. But then he made those comments about how static typing is there 
in Java and other languages because it is thought programmers are too 
stupid to be able to handle things otherwise (don't remember his exact 
words), or even worse, the comment/point about how many programmers in 
the audience made a bug because of not specifying a type... And from 
that point it was easy to go downhill, and indeed the talk did. Although 
I am happy for him making that explicit parallel with political 
ideology, it illustrates my point very well, even if not all Ruby 
developers would agree with him 100%.


Note that all of what I said above is a comment about the nature of the 
discussion of static vs. typing. I didn't make an actual argument for or 
against static typing (in case you were thinking this was the 
intention). I won't do that now, I'll just say that, not only I am a 
long-time proponent of static typing, in the last few years I've become 
a proponent of *even more* static typing. But done in a smart way of course.


-- 
Bruno Medeiros - Software Engineer



 Dec 21 2010



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:ier0hh$us8$1 digitalmars.com...

 On 11/12/2010 01:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.


 Whoa.

 Over the last 5 years or so, with surge in popularity of dynamic languages 
 like Ruby, Python, etc., I've seen several arguments put forth in favor of 
 dynamic typing, and gradually I've always found there was a /subtle/ 
 parallel with the arguments and reasons put forth for 
 libertarian/anti-authoritarian/anti-corporate ideologies.
 After seeing this talk, I guess it's not so subtle after all... ~_~'


 Let me offer my thoughts on this. I don't think his argument is 
 fundamentally rational. And I don't just mean wrong or illogical, I mean 
 /irrational/: it is driven by an emotional bias of something not related 
 to programmer productivity, which is what the discussion should be about. 
 And I think his opinion is somewhat generally representative of many 
 dynamic language proponents.

 What I think is happening is this: These people, if and when they program 
 on languages with static typing, they get annoyed by some (or all) of the 
 aspects of static typing. That's normal so far, but now the problem is 
 that while some of this annoyance may be driven from a genuine questioning 
 of whether static typing is worth it or not (in usefulness and 
 productivity), the rest of the annoyance is instead driven by an external 
 emotional factor: if the language doesn't let you do something that it 
 could easily let you do, then it is perceived as a "restriction of your 
 freedoms". The programmer makes an emotional connection to personal issues 
 unrelated to the field of programming. Another variant of this emotional 
 response in this situation, and probably a much more common one, is not 
 about political ideology, but rather the programmer perceives the language 
 restriction to be part of a corporate culture that says that programmers 
 are not smart enough to be fully trusted, and they need to be controlled 
 to make sure they don't do stupid things. In other words the language 
 thinks your are a dumb monkey who needs to be kept in line. Java is the 
 poster child for this mentality, not only due to the language itself which 
 is perceived to be simplistic, but also due to Java's strong association 
 to the corporate and enterprise world. In a less extreme view, it is not 
 about controlling stupidity, but controlling creativity (a view popular 
 amongst "artist"/"painter" programmers). So here the programmers are not 
 dumb, but still they need to be kept in line with rules, constraints, 
 specifications, strict APIs, etc.. You can't do anything too strange or 
 out of the ordinary, and the language is a reflection of that, especially 
 with regards to restrictions on dynamic typing (and other dynamic stuff 
 like runtime class modification).

 Unfortunately this emotional response is often not fully conscious, or at 
 least, it is not clearly expressed to others by the underlying programmer. 
 And once this happens, _everything is lost from the beginning, in terms of 
 trying to have a sensible debate._ Because from now on, these programmers 
 will use half-baked arguments to try to justify their preference of 
 dynamic languages. The arguments will be half-baked because they will try 
 to argue in the area of effectiveness (programmer productivity), yet the 
 main reason they like/dislike the language is the attitude of the language 
 creators and/or community. (Interestingly enough, an incredibly similar 
 cognitive-dissonance driven fallacy happens in discussions of actual 
 political ideologies)

 (Note, I'm not saying this is the case with all programmers, or even most, 
 of the proponents of dynamic typing. In particular, nor I am saying it's 
 the case with Ary :p )


 BTW, for a while I was quite okay with this talk, because the author 
 seemed to make clear what the liked about Ruby was the underlying 
 attitude. He mentioned the language design goal of "making the programmer 
 happy". He mentioned all those quirks of the community like the 'second' 
 property, the 42 one, the cheerleaders at the convention, etc.. But then 
 he made those comments about how static typing is there in Java and other 
 languages because it is thought programmers are too stupid to be able to 
 handle things otherwise (don't remember his exact words), or even worse, 
 the comment/point about how many programmers in the audience made a bug 
 because of not specifying a type... And from that point it was easy to go 
 downhill, and indeed the talk did. Although I am happy for him making that 
 explicit parallel with political ideology, it illustrates my point very 
 well, even if not all Ruby developers would agree with him 100%.


 Note that all of what I said above is a comment about the nature of the 
 discussion of static vs. typing. I didn't make an actual argument for or 
 against static typing (in case you were thinking this was the intention). 
 I won't do that now, I'll just say that, not only I am a long-time 
 proponent of static typing, in the last few years I've become a proponent 
 of *even more* static typing. But done in a smart way of course.


*Very* interesting observation.



 Dec 21 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Nick Sabalausky wrote:

 *Very* interesting observation.


I agree. I hadn't thought about it that way, and thanks to Bruno for the
insight.



 Dec 21 2010



prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 21 Dec 2010 14:50:21 -0500, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:


 In a less extreme view, it is not about controlling stupidity, but  
 controlling creativity (a view popular amongst "artist"/"painter"  
 programmers). So here the programmers are not dumb, but still they need  
 to be kept in line with rules, constraints, specifications, strict APIs,  
 etc.. You can't do anything too strange or out of the ordinary, and the  
 language is a reflection of that, especially with regards to  
 restrictions on dynamic typing (and other dynamic stuff like runtime  
 class modification).


Those aren't bugs, they are the artistic qualities of my program!  It's a  
statement on the political bias against bugs, I mean most people kill bugs  
without a second thought!

;)

-Steve



 Dec 21 2010



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vn2zzvlceav7ka steve-laptop...

 On Tue, 21 Dec 2010 14:50:21 -0500, Bruno Medeiros 
 <brunodomedeiros+spam com.gmail> wrote:


 In a less extreme view, it is not about controlling stupidity, but 
 controlling creativity (a view popular amongst "artist"/"painter" 
 programmers). So here the programmers are not dumb, but still they need 
 to be kept in line with rules, constraints, specifications, strict APIs, 
 etc.. You can't do anything too strange or out of the ordinary, and the 
 language is a reflection of that, especially with regards to 
 restrictions on dynamic typing (and other dynamic stuff like runtime 
 class modification).


 Those aren't bugs, they are the artistic qualities of my program!  It's a 
 statement on the political bias against bugs, I mean most people kill bugs 
 without a second thought!


Or even worse, they try to "fix" bugs...just like people will "fix" their 
pets, or how tyrants will "fix" their opposition or their scapegoats.  Save 
the bugs! Thay have just as much a right to exist as any compiler or audio 
codec!

Ok, I'm done now :)



 Dec 21 2010



prev sibling  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 21/12/2010 20:46, Steven Schveighoffer wrote:

 On Tue, 21 Dec 2010 14:50:21 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:


 In a less extreme view, it is not about controlling stupidity, but
 controlling creativity (a view popular amongst "artist"/"painter"
 programmers). So here the programmers are not dumb, but still they
 need to be kept in line with rules, constraints, specifications,
 strict APIs, etc.. You can't do anything too strange or out of the
 ordinary, and the language is a reflection of that, especially with
 regards to restrictions on dynamic typing (and other dynamic stuff
 like runtime class modification).


 Those aren't bugs, they are the artistic qualities of my program! It's a
 statement on the political bias against bugs, I mean most people kill
 bugs without a second thought!

 ;)

 -Steve


I'm not sure if my meaning was fully understood thete, but I wasn't 
implying it was a programmer tried to masquerade problems in code by 
saying it is "artistic" or something.
Rather it was a not-so-thinly veiled reference (and critique) of Paul 
Graham's "painter" hacker/programmer archetype.

-- 
Bruno Medeiros - Software Engineer



 Jan 28 2011



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


Tue, 21 Dec 2010 19:50:21 +0000, Bruno Medeiros wrote:


 On 11/12/2010 01:26, Ary Borenszweig wrote:

 http://vimeo.com/17420638

 A very interesting talk.


 Whoa.
 
 Over the last 5 years or so, with surge in popularity of dynamic
 languages like Ruby, Python, etc., I've seen several arguments put forth
 in favor of dynamic typing, and gradually I've always found there was a
 /subtle/ parallel with the arguments and reasons put forth for
 libertarian/anti-authoritarian/anti-corporate ideologies. After seeing
 this talk, I guess it's not so subtle after all... ~_~'
 
 
 Let me offer my thoughts on this. I don't think his argument is
 fundamentally rational. And I don't just mean wrong or illogical, I mean
 /irrational/: it is driven by an emotional bias of something not related
 to programmer productivity, which is what the discussion should be
 about. And I think his opinion is somewhat generally representative of
 many dynamic language proponents.
 
 What I think is happening is this: These people, if and when they
 program on languages with static typing, they get annoyed by some (or
 all) of the aspects of static typing. That's normal so far, but now the
 problem is that while some of this annoyance may be driven from a
 genuine questioning of whether static typing is worth it or not (in
 usefulness and productivity), the rest of the annoyance is instead
 driven by an external emotional factor: if the language doesn't let you
 do something that it could easily let you do, then it is perceived as a
 "restriction of your freedoms". The programmer makes an emotional
 connection to personal issues unrelated to the field of programming.
 Another variant of this emotional response in this situation, and
 probably a much more common one, is not about political ideology, but
 rather the programmer perceives the language restriction to be part of a
 corporate culture that says that programmers are not smart enough to be
 fully trusted, and they need to be controlled to make sure they don't do
 stupid things. In other words the language thinks your are a dumb monkey
 who needs to be kept in line. Java is the poster child for this
 mentality, not only due to the language itself which is perceived to be
 simplistic, but also due to Java's strong association to the corporate
 and enterprise world. In a less extreme view, it is not about
 controlling stupidity, but controlling creativity (a view popular
 amongst "artist"/"painter" programmers). So here the programmers are not
 dumb, but still they need to be kept in line with rules, constraints,
 specifications, strict APIs, etc.. You can't do anything too strange or
 out of the ordinary, and the language is a reflection of that,
 especially with regards to restrictions on dynamic typing (and other
 dynamic stuff like runtime class modification).
 
 Unfortunately this emotional response is often not fully conscious, or
 at least, it is not clearly expressed to others by the underlying
 programmer. And once this happens, _everything is lost from the
 beginning, in terms of trying to have a sensible debate._ Because from
 now on, these programmers will use half-baked arguments to try to
 justify their preference of dynamic languages. The arguments will be
 half-baked because they will try to argue in the area of effectiveness
 (programmer productivity), yet the main reason they like/dislike the
 language is the attitude of the language creators and/or community.
 (Interestingly enough, an incredibly similar cognitive-dissonance driven
 fallacy happens in discussions of actual political ideologies)
 
 (Note, I'm not saying this is the case with all programmers, or even
 most, of the proponents of dynamic typing. In particular, nor I am
 saying it's the case with Ary :p )
 
 
 BTW, for a while I was quite okay with this talk, because the author
 seemed to make clear what the liked about Ruby was the underlying
 attitude. He mentioned the language design goal of "making the
 programmer happy". He mentioned all those quirks of the community like
 the 'second' property, the 42 one, the cheerleaders at the convention,
 etc.. But then he made those comments about how static typing is there
 in Java and other languages because it is thought programmers are too
 stupid to be able to handle things otherwise (don't remember his exact
 words), or even worse, the comment/point about how many programmers in
 the audience made a bug because of not specifying a type... And from
 that point it was easy to go downhill, and indeed the talk did. Although
 I am happy for him making that explicit parallel with political
 ideology, it illustrates my point very well, even if not all Ruby
 developers would agree with him 100%.
 
 
 Note that all of what I said above is a comment about the nature of the
 discussion of static vs. typing. I didn't make an actual argument for or
 against static typing (in case you were thinking this was the
 intention). I won't do that now, I'll just say that, not only I am a
 long-time proponent of static typing, in the last few years I've become
 a proponent of *even more* static typing. But done in a smart way of
 course.


My experiences in several language communities have shown that 
programmers easily resort to emotional, completely irrational arguments. 
It's best to avoid these kind of arguments as much as possible. 
Passionate people seem to favor this juxtapositioning.

For example, the static type systems develop further each day. These 
aren't even supposed to be practical in the real world in their current 
state. At least I hope we can cherry-pick the best parts and build a 
practical language once the underpinnings are clearly studied and 
specified. It's just plainly stupid to compare these now.

One reason I favor dry theoretical programming books is that they often 
cite concrete facts and describe the logical reasoning leading to a 
conclusion. The other group of books, programming cook books, are mostly 
just pure poop:

"Book: You must always do A and should also prefer choices like B."

"Me: why?"

"Book: Just do it, don't think."



 Dec 21 2010



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


retard wrote:

 "Book: You must always do A and should also prefer choices like B."
 
 "Me: why?"
 
 "Book: Just do it, don't think."


A novice follows the rules because he is told to.

A master follows the rules because he understands them.

A guru breaks the rules because the rules don't always apply.



 Dec 21 2010



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


On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote:

 retard wrote:

 "Book: You must always do A and should also prefer choices like B."
 
 "Me: why?"
 
 "Book: Just do it, don't think."


 
 A novice follows the rules because he is told to.
 
 A master follows the rules because he understands them.
 
 A guru breaks the rules because the rules don't always apply.


So, is that a (possibly paraphrased) quote or just highly quotable?

- Jonathan M Davis



 Dec 21 2010



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


Jonathan M Davis wrote:

 On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote:

 retard wrote:

 "Book: You must always do A and should also prefer choices like B."

 "Me: why?"

 "Book: Just do it, don't think."


 A novice follows the rules because he is told to.

 A master follows the rules because he understands them.

 A guru breaks the rules because the rules don't always apply.


 
 So, is that a (possibly paraphrased) quote or just highly quotable?


I heard it a very long time ago, and I do not know where it originated, or even 
if it wasn't just coined by my friends.



 Dec 21 2010



 next sibling parent  Ulrik Mikaelsson <ulrik.mikaelsson gmail.com>  writes:


2010/12/21 Walter Bright <newshound2 digitalmars.com>:

 Jonathan M Davis wrote:

 On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote:

 A novice follows the rules because he is told to.

 A master follows the rules because he understands them.

 A guru breaks the rules because the rules don't always apply.


 So, is that a (possibly paraphrased) quote or just highly quotable?


 I heard it a very long time ago, and I do not know where it originated, or
 even if it wasn't just coined by my friends.


I think it stems from a traditional Japanese model of learning, known
as the Shu-Ha-Ri. As usual, Wikipedia gives a good overview.
http://en.wikipedia.org/wiki/Shuhari



 Dec 21 2010



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ier98d$1ecj$1 digitalmars.com...

 Jonathan M Davis wrote:

 On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote:

 retard wrote:

 "Book: You must always do A and should also prefer choices like B."

 "Me: why?"

 "Book: Just do it, don't think."


 A novice follows the rules because he is told to.

 A master follows the rules because he understands them.

 A guru breaks the rules because the rules don't always apply.


 So, is that a (possibly paraphrased) quote or just highly quotable?


 I heard it a very long time ago, and I do not know where it originated, or 
 even if it wasn't just coined by my friends.


Sounds a bit Zen Buddhist or maybe Taoist to me.



 Dec 21 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Nick Sabalausky wrote:

 Sounds a bit Zen Buddhist or maybe Taoist to me.



Gravity - it's the law.



 Dec 22 2010



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 21/12/2010 20:55, retard wrote:

 My experiences in several language communities have shown that
 programmers easily resort to emotional, completely irrational arguments.
 It's best to avoid these kind of arguments as much as possible.
 Passionate people seem to favor this juxtapositioning.


http://www.penny-arcade.com/comic/2004/3/19/
Penny Arcade is about games, but I'd say that theory applies to just 
about any internet community, including programmers.
Especially in the FOSS world.


-- 
Bruno Medeiros - Software Engineer



 Jan 28 2011



  parent  so <so so.do>  writes:


 http://www.penny-arcade.com/comic/2004/3/19/
 Penny Arcade is about games, but I'd say that theory applies to just  
 about any internet community, including programmers.
 Especially in the FOSS world.


I have seen that and similar pictures many times, but never fully  
understand what they are trying to say.

1. Anonymity is bad? (My answer: if anonymity is using nicks instead of  
names, certainly no)
2. We all are nothing but total fuckwads (whatever that means)? (My  
answer: possibly yes)
3. What the hell anonymity actually mean in internet anyways? (My answer:  
i am not sure)

For example, i am using a nick (instead of a random name, which might be  
as well forged), because i hate seeing my name everywhere, good or bad.



 Jan 28 2011