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.

About a year ago I met Ruby. Now I find languages like Java, C#,
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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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
next sibling 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
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 parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

 language/thought-process" feel, but it just ends up feeling=20
 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. I=

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

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

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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. If you are using language ### instead of D/C/C++, the first and biggest 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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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.
 
 About a year ago I met Ruby. Now I find languages like Java, C#,
 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
next sibling 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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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 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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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 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
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
next sibling 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 "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 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: http://forums.gentoo.org/viewtopic-p-6500059.html#6500059 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: http://forums.gentoo.org/viewtopic-p-6500059.html#6500059 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

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

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.

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

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.

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

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

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: http://forums.gentoo.org/viewtopic-p-6500059.html#6500059 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

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 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: http://forums.gentoo.org/viewtopic-p-6500059.html#6500059 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 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 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
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 next sibling 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 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
next sibling 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 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?). The second one reminds me of C#'s lambdas and seems like an excellent 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?). The second one reminds me of C#'s lambdas and seems like an excellent 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?). The second one reminds me of C#'s lambdas and seems like an excellent 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.

Not entirely bad points, but C# doesn't seem to have a problem with it. 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/
 The second one reminds me of C#'s lambdas and seems like an excellent
 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 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 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
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.

Any problem with the other Scala/C#-style one?: (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 be mixed in). The lowered Scala/C#-style would be able to though: 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.

Any problem with the other Scala/C#-style one?: (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 compilers are better, it would be embarrasing to admit that C# and Scala made a 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.

Any problem with the other Scala/C#-style one?: (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 be mixed in). The lowered Scala/C#-style would be able to though: int foo(int x) { ... } collection.map!((a) => foo(a) + 3)(); // Lowered to the messier: collection.map!((a) { return foo(a) + 3; })();

As Nick writes here the Scala/C#-style syntax is one suggestion. There 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(_ * _) 2 C#: foo(x => x * x); 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 and C#'s lambda syntax. Basically like this: 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 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
 and C#'s lambda syntax. Basically like this:

 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(_ * _)
 2 C#: foo(x => x * x);
 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 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(_ * _)
 2 C#: foo(x => x * x);
 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 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 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
parent "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
prev sibling 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 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 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
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 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 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 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; }

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

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

 As Nick writes here the Scala/C#-style syntax is one suggestion. There
 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)

 2 C#: 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:
Nick Sabalausky wrote:
 Any problem with the other Scala/C#-style one?:
 
 (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:
 Any problem with the other Scala/C#-style one?:

 (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:
 Any problem with the other Scala/C#-style one?:

 (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:
 Any problem with the other Scala/C#-style one?:

 (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:
 Any problem with the other Scala/C#-style one?:

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

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

Is that the royal "we" as in singular? If plural, may one politely inquire as to whom "we" are?

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

 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
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 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
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 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
prev sibling next 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 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 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 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 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 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 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-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 next 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 "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
prev sibling 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:
"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
prev sibling next 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 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 next 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 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
prev sibling parent 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
prev sibling next sibling parent "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
prev 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 "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 next 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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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 integrate more dynamic features like C# 4 and Java 7 do. This would eliminate other common languages and make D invulnerable ultimate language.
Dec 11 2010
prev sibling 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 "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:

 Jacob Carlborg:

 1 D: foo(writeln(3)); // lazy argument
 1 Scala: foo(_ * _)
 2 C#: foo(x => x * x);
 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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; }
 
 

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
prev sibling 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
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 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 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 next 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 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
 ?

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=

 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=

 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=

 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=

 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=

 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=

 a terser syntax for lambda's than most of the other languages we've been=

 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 next sibling parent 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=


 simply a small extension to an already existing feature that would give=


 a terser syntax for lambda's than most of the other languages we've bee=


 discussing. =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
prev sibling 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 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; }
 
 

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
prev sibling next 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; }
 
 

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 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 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 next sibling parent 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
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 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 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.
 
 About a year ago I met Ruby. Now I find languages like Java, C#,
 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
prev sibling 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=


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


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

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=

 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 Michael Stover <michael.r.stover gmail.com> writes:
--000e0cd328a0ecb290049722b26a
Content-Type: text/plain; charset=ISO-8859-1

 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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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.


 yes, before someone brings it up, I'm well aware of CakePHP... and


 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


 BEST LANGUAGE OMG!!!"  There is just the best one for a given


 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

--000e0cd328a0ecb290049722b26a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> LOL. I&#39;d _love_ to use D at work, but so much of our code is in C++ and= must</blockquote><meta http-equiv=3D"content-type" content=3D"text/html; c= harset=3Dutf-8"><meta http-equiv=3D"content-type" content=3D"text/html; cha= rset=3Dutf-8"><blockquote> compile with Visual Studio that the fact that C++ doesn&#39;t integrate wit= h D all</blockquote><blockquote>that well and the fact that you have to use= dmc on Windows for the C or C++ code</blockquote><blockquote>if you want t= o link it with D code make it so that it doesn&#39;t make any sense at</blo= ckquote> <blockquote>all to use D at this point.</blockquote><div>Having to use the = dmc compiler on windows in order to leverage legacy C++ code while being ab= le to move on with new D code doesn&#39;t sound like too much of a restrict= ion. =A0Is there a similar tool that allows linking D and C++ on linux and = mac?</div> <div><br></div><div>Mike</div><br><div class=3D"gmail_quote">On Sat, Dec 11= , 2010 at 3:32 AM, Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto= :jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On Saturday 11 December 2010 00:01:35 And= rei Alexandrescu wrote:<br> &gt; On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:<br> &gt; &gt; On 12/10/10 19:26, Ary Borenszweig wrote:<br> &gt; &gt;&gt; <a href=3D"http://vimeo.com/17420638" target=3D"_blank">http:= //vimeo.com/17420638</a><br> &gt; &gt;&gt;<br> &gt; &gt;&gt; A very interesting talk.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; I used to like D. To write code in a high level while at the = same<br> &gt; &gt;&gt; time being very close to the machine, with class invariants, = unit<br> &gt; &gt;&gt; tests and many other features seemed very appealing. But I al= ways<br> &gt; &gt;&gt; felt there was something wrong.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; About a year ago I met Ruby. Now I find languages like Java, = C#,<br> &gt; &gt;&gt; Python and D kind of ugly and uncomfortable. Why? Exactly bec= ause of<br> &gt; &gt;&gt; what it is said in that video.<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; This is not to start a flame war or trolling, it&#39;s just t= o show you<br> &gt; &gt;&gt; why I changed my mind so much about D, and why I think (IMHO)= you<br> &gt; &gt;&gt; should care about naming conventions (like bearophile says), = more<br> &gt; &gt;&gt; powerful unittests (and not having unittests integrated into = the<br> &gt; &gt;&gt; language but rather being able to build your own test framewo= rks<br> &gt; &gt;&gt; with ease) and stop caring about being C-syntax friendly. The= world<br> &gt; &gt;&gt; doesn&#39;t need that many semicolons and parenthesis. :-)<br=

&gt; &gt; I&#39;m a strange one. =A0I use Ruby, and D. =A0(And a couple of = others...) =A0I<br> &gt; &gt; use the tool that feels best for the job, whatever that may be at= a<br> &gt; &gt; given time. =A0Sitting on a disc somewhere are some personal tool= s I used<br> &gt; &gt; to use when working with D... which are themselves written in Rub= y (and<br> &gt; &gt; bash script, but hey).<br> &gt; &gt;<br> &gt; &gt; Then again, I&#39;m the same one who really really likes Ruby on = Rails...<br> &gt; &gt; and yet still does most things with PHP. =A0Why? =A0Well for one,= because<br> &gt; &gt; for plenty of projects, Rails is less an aid and more a hindrance= . =A0(And<br> &gt; &gt; yes, before someone brings it up, I&#39;m well aware of CakePHP..= . and don&#39;t<br> &gt; &gt; care for it much.)<br> &gt; &gt;<br> &gt; &gt; There are times in D when I find myself wishing, momentarily, for= the<br> &gt; &gt; loose typing of Ruby... but then there are times in Ruby when I f= ind<br> &gt; &gt; myself wishing for stricter typing.<br> &gt; &gt;<br> &gt; &gt; There are times when I wish D had open classes... but then there = are<br> &gt; &gt; times when Ruby&#39;s open classes give me headaches.<br> &gt; &gt;<br> &gt; &gt; I could go on like this... but the point was really just: use the= right<br> &gt; &gt; tool for the job. =A0Keep several tools in your toolbox. =A0There= is no &quot;THE<br> &gt; &gt; BEST LANGUAGE OMG!!!&quot; =A0There is just the best one for a gi= ven programmer<br> &gt; &gt; in a given scenario. =A0Some of the things I&#39;ve done could pr= obably have<br> &gt; &gt; been better written in, say, Pike! =A0But I don&#39;t really know= Pike (very<br> &gt; &gt; well), and don&#39;t feel the need to learn it just for those few= things<br> &gt; &gt; that might have benefited.<br> &gt; &gt;<br> &gt; &gt; -- Chris N-S<br> &gt;<br> &gt; Agreed. One issue with the talk is non-acceptance of &quot;the right t= ool for<br> &gt; the job&quot; (the speaker literally says he&#39;s tired of that phras= e). There<br> &gt; is one best tool - and that&#39;s Ruby. Ahem.<br> <br> </div></div>LOL. I&#39;d _love_ to use D at work, but so much of our code i= s in C++ and must<br> compile with Visual Studio that the fact that C++ doesn&#39;t integrate wit= h D all<br> that well and the fact that you have to use dmc on Windows for the C or C++= code<br> if you want to link it with D code make it so that it doesn&#39;t make any = sense at<br> all to use D at this point.<br> <br> And of course, there are plenty of cases where a particular language is jus= t<br> incredibly well suited for a particular job, and the best general purpose<b= r> language just isn&#39;t as good.<br> <br> I think that it&#39;s good to strive to a have a language that is excellent= for most<br> use cases, but ultimately, you always have to pick the best tool for the jo= b. No<br> language is the best for all scenarios even if it&#39;s the best for most s= cenarios.<br> <font color=3D"#888888"><br> - Jonathan M Davis<br> </font></blockquote></div><br> --000e0cd328a0ecb290049722b26a--
Dec 11 2010
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 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
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 next sibling 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 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=

 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
prev sibling next 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 next sibling parent 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
prev sibling next sibling parent "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
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?

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: http://forums.gentoo.org/viewtopic-p-6500059.html#6500059 =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 next sibling parent "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
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 "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=

 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=

 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 next sibling parent 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
prev sibling 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 next sibling parent "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
prev sibling 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=


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


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

 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 next sibling 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=

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

 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 i=

 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 next sibling parent 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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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.

_)" 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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling 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 next sibling parent 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
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--001636e0a9ccee32c20497a4afa3
Content-Type: text/plain; charset=ISO-8859-1

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/

--001636e0a9ccee32c20497a4afa3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable People have indeed designed and implemented very big software systems using= &quot;one of those so called not so complex languages&quot;.<br>What peopl= e have not done is write anything meaningful of any size in D.=A0 The main = reason for that is that, after so many years, there is still no decent D co= mpiler, nothing near GCC quality, to be found.=A0 For such a complex langua= ge as D, there are sure too many compilers and &quot;standard&quot; librari= es, none of which are stable, up-to-date, or usable enough.=A0 GCC is the g= old standard (for openness, quality, and user-base), and it seems D won&#39= ;t make it in till 2012.=A0 So, we&#39;re still years away from the &quot;b= ig D software&quot;.=A0 According to Ohloh, there is currently a total of 1= 6 million lines of code written in D.=A0 Compare that to 70 million for Rub= y, and 160 million for Python.=A0 And that&#39;s only for open source proje= cts that Ohloh keeps track of.=A0 The count is in billions for C/C++.=A0 <b= r> <br>What I don&#39;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 issu= es?=A0 How complex is D really?<br><br><div class=3D"gmail_quote">2010/12/1= 7 so <span dir=3D"ltr">&lt;so so.do&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"im"=
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; bord=

Please, please, please, look back at what you&#39;ve done and think hard if= it is<br> really the right way to go. Everything seems overly complex by now.<br> <br> &lt;/just trying to help&gt;<br> </blockquote> <br></div> Can you name a single language as powerful and as expressive as D and doesn= &#39;t have complexity?<br> Just name one, Walter and Andrei would be the first one to migrate that lan= guage i am sure.<br> Everyone on this thread must read the D overview on the main page.<br> <br> People use this word &quot;complexity&quot; quite often. I don&#39;t think = i get what they mean with that really.<br> Go write a big software using one of those so called &quot;not so complex&q= uot; languages and lets talk about this word complexity again.<br> <br> Thank you.<br><font color=3D"#888888"> <br> -- <br> Using Opera&#39;s revolutionary email client: <a href=3D"http://www.opera.c= om/mail/" target=3D"_blank">http://www.opera.com/mail/</a><br> </font></blockquote></div><br> --001636e0a9ccee32c20497a4afa3--
Dec 17 2010
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling parent reply Caligo <iteronvexor gmail.com> writes:
--001636ef04694a86910497a8edef
Content-Type: text/plain; charset=ISO-8859-1

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/

--001636ef04694a86910497a8edef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Obviously you&#39;re not going to find an OS kernel that&#39;s written in P= ython or Ruby, and just because it&#39;s an OS kernel doesn&#39;t necessarl= y mean it&#39;s that big.=A0 The Linux kernel is about 8 million, and about= half of it is the drivers.=A0 The core is actually rather small (about 2 m= illion).=A0 Qt, on the other hand, is well over 14 million lines of C/C++.= =A0 Things are very different for an actual operating system, however.=A0 G= entoo Linux is a great example, and I&#39;ve been using it for almost 10 ye= ars.=A0 Portage, its package management system, is over 1 million lines of = bash; that&#39;s a lot for bash, and portage is a very important part of th= e Gentoo OS (i.e., it&#39;s big).=A0 <br> <br>&quot;Big&quot; doesn&#39;t necessarily have to be lines-of-code, and k= eep in mind that 5 lines of, say, Ruby code could easily translate into 50 = lines of C++.=A0 If a software program plays an important role in people&#3= 9;s lives, then I think it could be considered big.=A0 SCons is a medium-si= ze project (100k of Python), but it sure beats Make when it come to ease of= use.=A0 Interesting enough, the Qt team is working on a new build tool to = replace qmake, and JavaScript is their primary choice for a programming lan= guage to do the job.<br> <br>Another example is Emacs.=A0 It&#39;s well over 1 million lines of Lisp= .=A0 Not to start a religious war, but Emacs is by far one of the best, if = not the best, text editor out there.=A0 It&#39;s much more than that.=A0 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.=A0 You sa= id to text processing, so I&#39;ll stop.<br> <br>IMO there is no honor in game development as it contributes nothing to = society.=A0 I&#39;ve rarely played any, so I won&#39;t be able to name too = many, but I do know about EVE Online.=A0 Its core is in C++ as far as I kno= w, but majority of it is in Python.=A0 In fact, I remember reading how CPP = temporarily hired Guido Rossum to help out because they were pushing Python= to its limits.<br> <br>Another example is Autodesk Maya.=A0 The core is probably C/C++, but Ma= ya Embeded Language (MEL) plays a very big role.=A0 In fact, at start-up, t= he entire GUI is created by MEL scripts.=A0 Maya by itself is probably one = of the most complex software programs out there, and in the early days a si= ngle license used to cost close to 15k dollars (probably because of a niche= market and all the secrecy in the computer graphics industry).=A0 Today it= &#39;s about half I think.=A0 They&#39;ve also recently added Python to it.= =A0 Maya has been used in pretty much every motion picture in the last ten = years or so, and I don&#39;t see how special effects artists could have wri= tten all those lines of code in C/C++ instead of MEL or Python.=A0 The Foun= dry Nuke and Apple Shake are other some examples.<br> <br>So, I guess it&#39;s fair to say that sometimes large software programs= are written in multiple programming languages.=A0 The core might be C/C++ = because of performance and efficiency, but everything else is some form of = scripting language.=A0 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.=A0 <br> <br>BTW, I&#39;m not trying to bash D in any way.=A0 In fact I&#39;m very e= xcited about it, and I want to see it succeed.=A0 I&#39;m a university stud= ent and C++ is my main programming language.=A0 I tried D1 about two years = ago for the first time, and that was with GDC (the old one).=A0 Since then = I haven&#39;t been able to experience all the cool features in D2 because t= here are no stable D2 compilers available for my system.=A0 I&#39;ve tried = compiling GDC from source several times with different versions of GCC, but= it always failed with an error.=A0 Spending a long time waiting for a comp= ile to finish, and finally failing is a big turnoff when you want to try so= mething new.=A0 I remember when Go was announced, and it took me less than = 5 minutes to clone the repo and compile.=A0 I was coding in Go in no time.= =A0 I still prefer D, but it&#39;s little things like this that dictate whe= ther or not a new programming language gains traction quicker.=A0 I think t= he day that I&#39;m able to do &#39;git clone git github.com:walter/d.git&#= 39; or &#39;emerge gdc&#39; is the day that D will be ready :-)<br> <br>I think I&#39;m digressing.=A0 I&#39;ll shut up now.<br><br>P.S.<br>I a= gree, C++ is a very complex language and I speak from experience.=A0 But I = wouldn&#39;t say the same about C.=A0 C is surely low-level, but not comple= x.=A0 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&#39;t know how accurate they are).=A0 At first I was drawn to Ruby bec= ause of its one-liners, but I soon realized that it kept reminding me of C+= +&#39;s complexity.=A0 I don&#39;t like the idea of &quot;more than one way= to do the same thing&quot; in a programming language.=A0 I think a natural= language suffers from this, and that is why, no matter how formal, your wr= itings are almost always open for interpretation.=A0 Interesting enough, if= you notice when you are talking to someone you&#39;re not actually talking= to them, but, rather, at them.=A0 That&#39;s probably why scientists use m= athematics to communicate.=A0 I haven&#39;t touched Ruby in over a year now= , and I&#39;ve been learning Python in my free time.<br> <br>Peace!<br><br><br><br><div class=3D"gmail_quote">2010/12/17 so <span di= r=3D"ltr">&lt;so so.do&gt;</span><br><blockquote class=3D"gmail_quote" styl= e=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); = padding-left: 1ex;"> On Sat, 18 Dec 2010 02:51:28 +0200, Caligo &lt;<a href=3D"mailto:iteronvexo= r gmail.com" target=3D"_blank">iteronvexor gmail.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> People have indeed designed and implemented very big software systems using= <br> &quot;one of those so called not so complex languages&quot;.<br> </blockquote> <br> Why don&#39;t you name one?<br> I obviously wasn&#39;t clear enough with &quot;big software&quot;.<br> I don&#39;t know of any serious OS, game, &lt;insert anything but text proc= essing&gt; written in anything except C/C++ (both complex languages).<div c= lass=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> What people have not done is write anything meaningful of any size in D.<br=


complex language as D, there are sure too many compilers and &quot;standard= &quot;<br> libraries, none of which are stable, up-to-date, or usable enough. =A0GCC i= s<br> the gold standard (for openness, quality, and user-base), and it seems D<br=

&quot;big D<br> software&quot;. =A0According to Ohloh, there is currently a total of 16 mil= lion<br> lines of code written in D. =A0Compare that to 70 million for Ruby, and 160= <br> million for Python. =A0And that&#39;s only for open source projects that Oh= loh<br> keeps track of. =A0The count is in billions for C/C++.<br> <br> What I don&#39;t understand is this: how is it that Walter was able to impl= ement<br> C++ all on his own from scratch, and yet D is having so many issues? =A0How= <br> complex is D really?<br> </blockquote> <br></div> I completely agree with you, Walter is a superman.<br> But i guess he is not super enough, he couldn&#39;t even singlehandedly sol= ve every programming issue known to man for last 50 years.<div><div></div><= div class=3D"h5"><br> <br> -- <br> Using Opera&#39;s revolutionary email client: <a href=3D"http://www.opera.c= om/mail/" target=3D"_blank">http://www.opera.com/mail/</a><br> </div></div></blockquote></div><br> --001636ef04694a86910497a8edef--
Dec 17 2010
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
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

Touch. ;) But I said 'game' not 'cult.' :D -- Chris N-S
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 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 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
 and C#'s lambda syntax. Basically like this:
 
 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
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
--485b393aafa55194120497b5f600
Content-Type: text/plain; charset=ISO-8859-1

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

func(int function(int, int)) or func(int, int function(int)) --485b393aafa55194120497b5f600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Dec 18, 2010 at 12:09 PM, Jacob Carlborg= <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com">doob me.com</a>&gt;</= span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;"> <br> Actually if it would be possible to skip the parentheses when the lambda ta= ke more than one argument I would be more happy with that:<br> <br> foo(x, y =3D&gt; x * y);<br> <font color=3D"#888888"><br></font></blockquote><div><br></div><div>Pretty = sure you&#39;ll need parenthesis. Should the above match:</div><div>func(in= t function(int, int))</div><div>or</div><div>func(int, int function(int))= =A0</div> </div><br> --485b393aafa55194120497b5f600--
Dec 18 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 18 Dec 2010 19:09:24 +0100, Jacob Carlborg wrote:

 As Nick writes here the Scala/C#-style syntax is one suggestion. There
 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)
 2 C#: 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
prev sibling next 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=

rather The Battle for Wesnoth ;-) Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Dec 19 2010
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
--000e0cd2e1c6dae45c0497c61455
Content-Type: text/plain; charset=ISO-8859-1

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

--000e0cd2e1c6dae45c0497c61455 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are absolutely right; life sucks for many people, and that&#39;s why so= me of them choose to play video games.=A0 It gives them a chance to escape = reality, and game companies exploit this to make money.=A0 Game companies u= se all kinds of psychology in their games to keep you playing as long as po= ssible.=A0 That is why to me there is no honor in game development.=A0 Also= , I never said it&#39;s worthless; they make tons of money, and that&#39;s = almost always at the expense of people like you.<br> <br>If it helps any, I&#39;m not one of those baby boomers.=A0 I&#39;m actu= ally in my early twenties.=A0 So if you are going to insult me at least do = it properly.<br><br>You sound way too angry and unhappy.=A0 Instead of play= ing video games, you should definitely pick up Ruby if you haven&#39;t alre= ady.=A0 I hear it&#39;s &quot;designed to make programmers happy.&quot;<br> <br><br><br><div class=3D"gmail_quote">On Sat, Dec 18, 2010 at 2:03 PM, Nic= k Sabalausky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px s= olid rgb(204, 204, 204); padding-left: 1ex;"> &quot;Caligo&quot; &lt;<a href=3D"mailto:iteronvexor gmail.com">iteronvexor= gmail.com</a>&gt; wrote in message<br> news:mailman.5.1292651710.4588.digitalmars-d puremagic.com...<br> &gt;<br> &gt; IMO there is no honor in game development as it contributes nothing to= <br> &gt; society. =A0I&#39;ve rarely played any,<br> <br> I gotta jump on this as being a giant load of pretentous bullshit. First of= <br> all, there&#39;s the patently obvious &quot;how in the world would you know= ?&quot;<br> considering the &quot;I&#39;ve rarely played any&quot;.<br> <br> But more importantly, games make life suck less - I can&#39;t even imagine = any<br> more significant contribution to society than that. Even all of the endevor= s<br> generally considered to be the biggest contributions to society are *only*<= br> significant contributions *because* that&#39;s exactly what they do: they m= ake<br> life suck less, and are therefore well-regarded.<br> <br> Seriously, what up with all those presumptuous assholes out there (mostly<b= r> baby boomer dinos and their even more anachronistic parents, interestingly<= br> enough) who have barely ever touched a videogame and yet figure they<br> actually have reason to believe such absurd pretentous crap? Fuck, they all= <br> remind me of that pompous Roger Ebert douchebag. (Speaking of ways to<br> benefit society, when&#39;s he finally gonna keel over? Isn&#39;t it about = time by<br> now? And speaking of &quot;contributions to society&quot; what the fuck&#39= ;s he ever<br> done? Collect a salary just to spout off opinions? Fucking useless wanker.)= <br> <br> <br> </blockquote></div><br> --000e0cd2e1c6dae45c0497c61455--
Dec 19 2010
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 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 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=

 them choose to play video games.=A0 It gives them a chance to escape real=

 and game companies exploit this to make money.=A0 Game companies use all =

 of psychology in their games to keep you playing as long as possible.=A0 =

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

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

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

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
 About a year ago I met Ruby. Now I find languages like Java, C#,
 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
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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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 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 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.

 About a year ago I met Ruby. Now I find languages like Java, C#,
 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 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
prev sibling next sibling 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 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 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
parent 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
prev sibling next sibling parent 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.

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=

 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
prev sibling next 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=

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

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 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
next sibling 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|
  test "sqrt #{input}"
    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|
  test "sqrt #{input}"
    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|
  test "sqrt #{input}"
    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 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 "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 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 next 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 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 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 "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
prev sibling next sibling 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.


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


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
prev sibling 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 next sibling parent 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
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 next 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.

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 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 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
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 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 next sibling parent 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
prev sibling 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.

as the Shu-Ha-Ri. As usual, Wikipedia gives a good overview. http://en.wikipedia.org/wiki/Shuhari
Dec 21 2010
prev sibling parent 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
prev sibling 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