Paul Graham recommends Ruby
Joe Van Dyk
undergraduate C.S. students. And plugs Ruby while he's at it.
http://paulgraham.com/college.html
"... What you should learn to get a job depends on the kind you want.
If you want to work in a big company, learn how to hack Blub on
Windows. If you want to work at a cool little company or research lab,
you'll do better to learn Ruby on Linux. And if you want to start your
own company, which I think will be more and more common, master the
most powerful tools you can find, because you're going to be in a race
against your competitors, and they'll be your horse.... "
Premshree Pillai
> Paul wrote an article about his recommendations for current
> undergraduate C.S. students. And plugs Ruby while he's at it.
>
> http://paulgraham.com/college.html
>
> "... What you should learn to get a job depends on the kind you want.
> If you want to work in a big company, learn how to hack Blub on
> Windows. If you want to work at a cool little company or research lab,
> you'll do better to learn Ruby on Linux. And if you want to start your
I don't think he "recommends Ruby". He probably means something to the
effect of "use a dynamic language like Python, or Ruby".
As much as all of us would like Mr. Graham to "recommend" Ruby, I
think it's for the better if we don't draw conclusions.
> own company, which I think will be more and more common, master the
> most powerful tools you can find, because you're going to be in a race
> against your competitors, and they'll be your horse.... "
>
>
--
Premshree Pillai
http://www.livejournal.com/users/premshree/
Joao Pedrosa
On Sat, 19 Mar 2005 16:57:10 +0900, Premshree Pillai
<premshre...@gmail.com> wrote:
> On Sat, 19 Mar 2005 11:54:41 +0900, Joe Van Dyk <joev...@gmail.com> wrote:
> > Paul wrote an article about his recommendations for current
> > undergraduate C.S. students. And plugs Ruby while he's at it.
> >
> > http://paulgraham.com/college.html
> >
> > "... What you should learn to get a job depends on the kind you want.
> > If you want to work in a big company, learn how to hack Blub on
> > Windows. If you want to work at a cool little company or research lab,
> > you'll do better to learn Ruby on Linux. And if you want to start your
>
> I don't think he "recommends Ruby". He probably means something to the
> effect of "use a dynamic language like Python, or Ruby".
>
> As much as all of us would like Mr. Graham to "recommend" Ruby, I
> think it's for the better if we don't draw conclusions.
My take is that he sees Ruby as a good medium to delivering some good
results, because since some articles ago by him, he has mentioned
Ruby, together with other languages. But in this particular article,
"college.html", he mentioned Ruby alone, because in the context of
small companies and research labs, Ruby has more probability of being
used, while Perl and Python feature in bigger companies already.
It's like the Nasdaq -- some indices go down and up, depending on the
trend. :-) But these indices are kind of irrelevant to the majority of
the people.
The Perl and Python people can keep ignoring Ruby, till the trend
changes really big. :-)
Cheers,
Joao
vruz
> > Paul wrote an article about his recommendations for current
> > undergraduate C.S. students. And plugs Ruby while he's at it.
> >
> > http://paulgraham.com/college.html
> >
> > "... What you should learn to get a job depends on the kind you want.
> > If you want to work in a big company, learn how to hack Blub on
> > Windows. If you want to work at a cool little company or research lab,
> > you'll do better to learn Ruby on Linux. And if you want to start your
>
> I don't think he "recommends Ruby". He probably means something to the
> effect of "use a dynamic language like Python, or Ruby".
>
> As much as all of us would like Mr. Graham to "recommend" Ruby, I
> think it's for the better if we don't draw conclusions.
Are you arguing about the use of the verb 'to recommend' ?
or else, how do you come to the conclusion that he didn't really mean
exactly Ruby, but Ruby or something else when he has explicitly named
Ruby on Linux ?
I think Graham knows well a number of programming languages, and could
have been explicit about them had he wanted to do so.
IMHO it's for the better if we don't draw conclusions about certain
reptiles when Graham hasn't mentioned any in the entire essay.
Premshree Pillai
> [snip]
> > > Paul wrote an article about his recommendations for current
> > > undergraduate C.S. students. And plugs Ruby while he's at it.
> > >
> > > http://paulgraham.com/college.html
> > >
> > > "... What you should learn to get a job depends on the kind you want.
> > > If you want to work in a big company, learn how to hack Blub on
> > > Windows. If you want to work at a cool little company or research lab,
> > > you'll do better to learn Ruby on Linux. And if you want to start your
> >
> > I don't think he "recommends Ruby". He probably means something to the
> > effect of "use a dynamic language like Python, or Ruby".
> >
> > As much as all of us would like Mr. Graham to "recommend" Ruby, I
> > think it's for the better if we don't draw conclusions.
>
> Are you arguing about the use of the verb 'to recommend' ?
> or else, how do you come to the conclusion that he didn't really mean
> exactly Ruby, but Ruby or something else when he has explicitly named
> Ruby on Linux ?
Well, I was taking the phrase into context -- "Ruby on Linux". He
probably used that as a specific instance of "[cool dynamic language
here] on *nix".
>
> I think Graham knows well a number of programming languages, and could
> have been explicit about them had he wanted to do so.
>
> IMHO it's for the better if we don't draw conclusions about certain
> reptiles when Graham hasn't mentioned any in the entire essay.
:-)
Premshree Pillai
> It's like the Nasdaq -- some indices go down and up, depending on the
> trend. :-) But these indices are kind of irrelevant to the majority of
Heh. But we could always use name dropping. :-)
> the people.
>
> The Perl and Python people can keep ignoring Ruby, till the trend
I don't think others are _still_ ignoring Ruby. Larry Wall after all
does talk about it.
> changes really big. :-)
>
> Cheers,
> Joao
--
Premshree Pillai
http://www.livejournal.com/users/premshree/
Wai-Sun Chia
>>Are you arguing about the use of the verb 'to recommend' ?
>>or else, how do you come to the conclusion that he didn't really mean
>>exactly Ruby, but Ruby or something else when he has explicitly named
>>Ruby on Linux ?
>
>
> Well, I was taking the phrase into context -- "Ruby on Linux". He
> probably used that as a specific instance of "[cool dynamic language
> here] on *nix".
>
>
I agree. He explicitly stated "Ruby on Linux".
If going by your logic, of "[cool dynamic language here] on *nix"", I
don't think he'd have meant Tcl on Dynix[1]??? Or Lua on QNX?
The context that he was trying to bring it in is either a small R&D, SME
or startup company with small budgets.
Ruby is relevant for product-to-market-speed (dynamic, OO, etc.), and
Linux is probably due to the fact that it runs well on commodity (read
cheap) Intel/AMD hardware.
p.s. anybody else remember what this is? :-)
/wai-sun
Premshree Pillai
> I agree. He explicitly stated "Ruby on Linux".
>
> If going by your logic, of "[cool dynamic language here] on *nix"", I
> don't think he'd have meant Tcl on Dynix[1]??? Or Lua on QNX?
TCL definitely doesn't qualify as a "cool dynamic language". :-)
Christian Neukirchen
> On Sat, 19 Mar 2005 11:54:41 +0900, Joe Van Dyk <joev...@gmail.com> wrote:
>> Paul wrote an article about his recommendations for current
>> undergraduate C.S. students. And plugs Ruby while he's at it.
>>
>> http://paulgraham.com/college.html
>>
>> "... What you should learn to get a job depends on the kind you want.
>> If you want to work in a big company, learn how to hack Blub on
>> Windows. If you want to work at a cool little company or research lab,
>> you'll do better to learn Ruby on Linux. And if you want to start your
>
> I don't think he "recommends Ruby". He probably means something to the
> effect of "use a dynamic language like Python, or Ruby".
Yeah, but Python 3000 won't have lisp stuff anymore, didn't you read
that? How could PG ever advertise that? :) *eg*
> Premshree Pillai
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
gabriele renzi
> On Sat, 19 Mar 2005 18:31:46 +0900, Wai-Sun Chia <waisu...@hp.com> wrote:
>
>>I agree. He explicitly stated "Ruby on Linux".
>>
>>If going by your logic, of "[cool dynamic language here] on *nix"", I
>>don't think he'd have meant Tcl on Dynix[1]??? Or Lua on QNX?
>
>
> TCL definitely doesn't qualify as a "cool dynamic language". :-)
you're underestimating tcl, it is a *strange* language but it is in the
end a powerful one, being homoiconic and such..
I can say tcl will see, in the third quarter of 2005, a grow in momentum
when it gets to the market.
Ok, I'm becoming addicted to this:
http://buzz.research.yahoo.com/bk/market/market.html?_mid=7440
Glenn Parker
>
> Ok, I'm becoming addicted to this:
> http://buzz.research.yahoo.com/bk/market/market.html?_mid=7440
Cool! You can put your money where your keyboard is.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
Navindra Umanee
> Yeah, but Python 3000 won't have lisp stuff anymore, didn't you read
> that?
Can you expand on this?
Cheers,
Navin.
Laurent Sansonetti
vruz
> > > Yeah, but Python 3000 won't have lisp stuff anymore, didn't you read
> > > that?
> >
> > Can you expand on this?
> >
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
>
> But who cares? :-)
I believe it's just a matter of time for Paul Graham to say something
about P3k getting 'unlisped'
Navindra Umanee
> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
>
> But who cares? :-)
Ruby was a language that was designed and inspired from other
languages... It's interesting to know what others think and how other
languages are evolving.
Ruby blocks are just syntactic sugar for a special-case lambda. Ruby
doesn't support generic lambda half as cleanly, as say, Scheme. What
seems to be happening in the case of Python is that syntactic sugar is
being added to do what people used to do with lambda and so support
for the later is being removed.
Guido makes some good points... For example, I don't know about you,
but I always have trouble with non-trivial reduces as well.
Cheers,
Navin.
ES
We need eta-reduction in Ruby! :)
>Cheers,
>Navin.
E
Joao Pedrosa
I love taking a cheap shot at Python. :-)
I made this post on TheServerSide:
http://www.theserverside.com/news/thread.tss?thread_id=32723#162440
Yay!
Cheers,
Joao
Christian Neukirchen
> Laurent Sansonetti <laurent.s...@gmail.com> wrote:
>> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
>>
>> But who cares? :-)
>
> Ruby was a language that was designed and inspired from other
> languages... It's interesting to know what others think and how other
> languages are evolving.
>
> Ruby blocks are just syntactic sugar for a special-case lambda. Ruby
Care to elaborate? What's lacking?
> doesn't support generic lambda half as cleanly, as say, Scheme. What
You cannot do lambda{|x|x*2}(2), yes.
> seems to be happening in the case of Python is that syntactic sugar is
> being added to do what people used to do with lambda and so support
> for the later is being removed.
Python's lambda was broken anyway (only one expression allowed) and
the "closures" didn't seem to deserve that name from what I recall.
Still, in some cases it can't be easily removed (e.g. GUI callbacks)
without losing functionality. But IANAP.
> Guido makes some good points... For example, I don't know about you,
> but I always have trouble with non-trivial reduces as well.
If they are written in a half-way sane style, I usually don't.
And often, the fold is easier to read than the expanded version.
I don't care what methods Guido drops and whatnot. After all, you
still can write your own map, filter and reduce. But when you drop
lambdas and any way to closure (from what I have read, inner functions
can't access outer variables), it's more than a dumb move IMO.
<troll>I, for one, welcome our new indented Java.</troll>
(Yes, Java has inner classes.)
> Cheers,
> Navin.
Navindra Umanee
> > Ruby blocks are just syntactic sugar for a special-case lambda. Ruby
>
> Care to elaborate? What's lacking?
Yeah, sorry for being unclear. I was referring to higher-order
functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
higher-order function with convenient syntax... for more than that it
gets less convenient.
> > doesn't support generic lambda half as cleanly, as say, Scheme. What
>
> You cannot do lambda{|x|x*2}(2), yes.
Yup, and for calling functions objects in general.
> Python's lambda was broken anyway (only one expression allowed) and
> the "closures" didn't seem to deserve that name from what I recall.
> Still, in some cases it can't be easily removed (e.g. GUI callbacks)
> without losing functionality. But IANAP.
Agreed. IANAP either.
> I don't care what methods Guido drops and whatnot. After all, you
> still can write your own map, filter and reduce. But when you drop
> lambdas and any way to closure (from what I have read, inner functions
> can't access outer variables), it's more than a dumb move IMO.
Again, I don't have that detailed knowledge about Python, but Guido says:
"also, there is a widespread misunderstanding that lambda can do
things that a nested function can't -- I still recall Laura
Creighton's Aha!-erlebnis after I showed her there was no difference!"
So, I presume he has his bases covered.
Cheers,
Navin.
Christian Neukirchen
> Christian Neukirchen <chneuk...@gmail.com> wrote:
>> > Ruby blocks are just syntactic sugar for a special-case lambda. Ruby
>>
>> Care to elaborate? What's lacking?
>
> Yeah, sorry for being unclear. I was referring to higher-order
> functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
> higher-order function with convenient syntax... for more than that it
> gets less convenient.
This apparently got better with the anonymous blocks recently imported
in CVS, but I didn't try that yet. It's a restriction by design,
though.
>> > doesn't support generic lambda half as cleanly, as say, Scheme. What
>>
>> You cannot do lambda{|x|x*2}(2), yes.
>
> Yup, and for calling functions objects in general.
Yes. And actually this is proper OO. I couldn't justify mylambda()
somehow.
>> Python's lambda was broken anyway (only one expression allowed) and
>> the "closures" didn't seem to deserve that name from what I recall.
>> Still, in some cases it can't be easily removed (e.g. GUI callbacks)
>> without losing functionality. But IANAP.
>
> Agreed. IANAP either.
>
>> I don't care what methods Guido drops and whatnot. After all, you
>> still can write your own map, filter and reduce. But when you drop
>> lambdas and any way to closure (from what I have read, inner functions
>> can't access outer variables), it's more than a dumb move IMO.
>
> Again, I don't have that detailed knowledge about Python, but Guido says:
>
> "also, there is a widespread misunderstanding that lambda can do
> things that a nested function can't -- I still recall Laura
> Creighton's Aha!-erlebnis after I showed her there was no difference!"
Interesting... stuff must have been totally broken then. ;-)
> So, I presume he has his bases covered.
Fixing lambdas wouldn't have been an option, of course. :P
Navindra Umanee
> > Yeah, sorry for being unclear. I was referring to higher-order
> > functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
> > higher-order function with convenient syntax... for more than that it
> > gets less convenient.
>
> This apparently got better with the anonymous blocks recently imported
I'm not sure how that could be improved, since it's already doing what
it was designed to do.
> in CVS, but I didn't try that yet. It's a restriction by design,
> though.
Sure, that's why I called it syntactic sugar. It takes what Matz
thought would or should be a common case use of lambda/higher-order
functions in Ruby and makes it convenient.
I presume Guido is doing the same thing in his own way. He's making
it convenient to do things people might otherwise do with lambda. Of
course, he's going the other way and shunning lambda altogether... so
he's not looking for Lisp/Scheme fans but apparently catering to
another demographic. Afterall, there are plenty of successful
languages without lambda.
> >> You cannot do lambda{|x|x*2}(2), yes.
> >
> > Yup, and for calling functions objects in general.
>
> Yes. And actually this is proper OO. I couldn't justify mylambda()
> somehow.
Proper OO? Um, well how can you justify:
a = [1, 2]
a[1]
but not:
a = lambda{|x|x*2}
a(1)
> Fixing lambdas wouldn't have been an option, of course. :P
;-)
Cheers,
Navin.
Christian Neukirchen
> Christian Neukirchen <chneuk...@gmail.com> wrote:
>> > Yeah, sorry for being unclear. I was referring to higher-order
>> > functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
>> > higher-order function with convenient syntax... for more than that it
>> > gets less convenient.
>>
>> This apparently got better with the anonymous blocks recently imported
>
> I'm not sure how that could be improved, since it's already doing what
> it was designed to do.
I think you can write foo {|x|...}, {|y|...} with recent CVS.
>> in CVS, but I didn't try that yet. It's a restriction by design,
>> though.
>
> Sure, that's why I called it syntactic sugar. It takes what Matz
> thought would or should be a common case use of lambda/higher-order
> functions in Ruby and makes it convenient.
Exactly. Although Smalltalk doesnt suffer from "easy" (multiple) block
syntax. It needs #call^Wdo, too.
> I presume Guido is doing the same thing in his own way. He's making
> it convenient to do things people might otherwise do with lambda. Of
> course, he's going the other way and shunning lambda altogether... so
> he's not looking for Lisp/Scheme fans but apparently catering to
> another demographic. Afterall, there are plenty of successful
> languages without lambda.
For differing values of "successful". I think it is a well-known fact
that lambdas (and closures) are a powerful way of abstraction. He
*could* easily have them (and whom would they hurt?)...
All in all, I can't think of any language that gets better because it
loses lambdas. :-)
>> >> You cannot do lambda{|x|x*2}(2), yes.
>> >
>> > Yup, and for calling functions objects in general.
>>
>> Yes. And actually this is proper OO. I couldn't justify mylambda()
>> somehow.
>
> Proper OO? Um, well how can you justify:
>
> a = [1, 2]
> a[1]
>
> but not:
>
> a = lambda{|x|x*2}
> a(1)
Ever tried a[1]?
>> Fixing lambdas wouldn't have been an option, of course. :P
>
> ;-)
> Cheers,
> Navin.
Martin DeMello
>
> Proper OO? Um, well how can you justify:
>
> a = [1, 2]
> a[1]
>
> but not:
>
> a = lambda{|x|x*2}
> a(1)
Simple - [] is a method and () isn't :)
a[1] works nicely for lambdas too, btw (not that I wouldn't like to see
a(1), of course).
also lambda {|i| i+1}[2] #=> 3
martin
Martin DeMello
> Christian Neukirchen <chneuk...@gmail.com> wrote:
> > > Ruby blocks are just syntactic sugar for a special-case lambda. Ruby
> >
> > Care to elaborate? What's lacking?
>
> Yeah, sorry for being unclear. I was referring to higher-order
> functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
> higher-order function with convenient syntax... for more than that it
> gets less convenient.
Well, since you cited scheme, it's the difference between
a.meth(lambda {|i| i+1}, lambda {|i| i-1})
and
a.meth(lambda{|i| i+1}) {|i| i - 1}
So that without the "one free closure" idea things would be *less*
convenient.
martin
ES
In data 3/19/2005, "Christian Neukirchen" <chneuk...@gmail.com> ha
scritto:
>Navindra Umanee <navi...@cs.mcgill.ca> writes:
>
>> Christian Neukirchen <chneuk...@gmail.com> wrote:
>>> > Yeah, sorry for being unclear. I was referring to higher-order
>>> > functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
>>> > higher-order function with convenient syntax... for more than that it
>>> > gets less convenient.
>>>
>>> This apparently got better with the anonymous blocks recently imported
>>
>> I'm not sure how that could be improved, since it's already doing what
>> it was designed to do.
>
>I think you can write foo {|x|...}, {|y|...} with recent CVS.
I'd rather see simple first-order functions/methods although this
is certainly an improvement.
Yes, but since it looks like indexing and forces to
go back and find out what 'a' is, operator() would
be extremely useful. We will hopefully see that based
on recent comments by matz-uo[1].
>>> Fixing lambdas wouldn't have been an option, of course. :P
>>
>> ;-)
>
>> Cheers,
>> Navin.
>--
>Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
E
Christian Neukirchen
>>>> >> You cannot do lambda{|x|x*2}(2), yes.
>>>> >
>>>> > Yup, and for calling functions objects in general.
>>>>
>>>> Yes. And actually this is proper OO. I couldn't justify mylambda()
>>>> somehow.
>>>
>>> Proper OO? Um, well how can you justify:
>>>
>>> a = [1, 2]
>>> a[1]
>>>
>>> but not:
>>>
>>> a = lambda{|x|x*2}
>>> a(1)
>>
>>Ever tried a[1]?
>
> Yes, but since it looks like indexing and forces to
> go back and find out what 'a' is, operator() would
> be extremely useful. We will hopefully see that based
> on recent comments by matz-uo[1].
But with localvar(), it can be even more confusing. Besides, method
calls are possible without (). Doing it properly is a hard job, and I
can understand Matz doesn't want to do it (yet). Rather don't have
that feature at all than in a crippled and inconsistent way.
> [1] http://redhanded.hobix.com/inspect/functionCall.html
Navindra Umanee
> > I'm not sure how that could be improved, since it's already doing what
> > it was designed to do.
>
> I think you can write foo {|x|...}, {|y|...} with recent CVS.
What does the syntax for yield look like then?
> For differing values of "successful". I think it is a well-known fact
> that lambdas (and closures) are a powerful way of abstraction. He
> *could* easily have them (and whom would they hurt?)...
He probably doesn't want them used at all, and wants all Python code
to look idiomatic. This is probably the reason for the whole
indentation debacle, in fact. His design goals and objectives simply
aren't the same as yours or Larry Wall's.
Paul Graham and others have already weighed in on this:
http://www.paulgraham.com/power.html
> All in all, I can't think of any language that gets better because it
> loses lambdas. :-)
I guess he's basically forcing you to use a named function instead of
an anonymous one... he's not removing functions.
All in all, to each his own... there's no dearth of languages with
lambda in them. :-)
> Ever tried a[1]?
Interesting, no I didn't know that. I guess this ugliness is needed
to have a separate namespace for variables and functions. Common Lisp
has the same ugliness.
Cheers,
Navin.
Florian Frank
>a[1] works nicely for lambdas too, btw (not that I wouldn't like to see
>a(1), of course).
>
>
Try the 1.9 cvs version:
irb(main):001:0> a = lambda { |x| x * 2 }
=> #<Proc:0xb7c6118c@(irb):1>
irb(main):002:0> a(1)
=> 2
irb(main):003:0> a 1
=> 2
--
Florian Frank
David A. Black
On Sun, 20 Mar 2005, Christian Neukirchen wrote:
> Navindra Umanee <navi...@cs.mcgill.ca> writes:
>
>> Christian Neukirchen <chneuk...@gmail.com> wrote:
>>>> Ruby blocks are just syntactic sugar for a special-case lambda. Ruby
>>>
>>> Care to elaborate? What's lacking?
>>
>> Yeah, sorry for being unclear. I was referring to higher-order
>> functions i.e. Ruby blocks allow you to pass one anonymous lambda to a
>> higher-order function with convenient syntax... for more than that it
>> gets less convenient.
>
> This apparently got better with the anonymous blocks recently imported
> in CVS, but I didn't try that yet. It's a restriction by design,
> though.
I'm not sure anything's new in that CVS feature except:
my_lambda = {|| puts "I am a lambda"}
where the || (with or without a param list) tells you that it's a
lambda rather than a hash.
I'm not a fan of this; I prefer using the lambda keyword.
David
--
David A. Black
dbl...@wobblini.net
Martin DeMello
> Try the 1.9 cvs version:
>
> irb(main):001:0> a = lambda { |x| x * 2 }
> => #<Proc:0xb7c6118c@(irb):1>
> irb(main):002:0> a(1)
> => 2
> irb(main):003:0> a 1
> => 2
Very sweet. How does this work, internally? Have lambdas been
specialcased at the interpreter level?
martin
David A. Black
I guess I spoke too soon in my last message.
I'm getting very confused by all of this, especially calling a lambda
with (). (I know it's a popular idea, is done in other languages,
etc. I mean I'm getting confused by how all these things fit into
Ruby.)
Matz: can you clarify where this is going?
Christian Neukirchen
> Christian Neukirchen <chneuk...@gmail.com> wrote:
>> > I'm not sure how that could be improved, since it's already doing what
>> > it was designed to do.
>>
>> I think you can write foo {|x|...}, {|y|...} with recent CVS.
>
> What does the syntax for yield look like then?
No yield:
def foo(x, y)
x.call
y.call
end
foo {|x|...}, {|y|...}
>> For differing values of "successful". I think it is a well-known fact
>> that lambdas (and closures) are a powerful way of abstraction. He
>> *could* easily have them (and whom would they hurt?)...
>
> He probably doesn't want them used at all, and wants all Python code
> to look idiomatic. This is probably the reason for the whole
> indentation debacle, in fact. His design goals and objectives simply
> aren't the same as yours or Larry Wall's.
Not that mine and Larry Wall's wouldn't be very different. :-P
But it's fine with me. Not that I liked Python before that decision.
But Graham will(does?) now probably push a different language, since
he really is pro-Lisp, not pro-Python.
> Paul Graham and others have already weighed in on this:
>
> http://www.paulgraham.com/power.html
>
>> All in all, I can't think of any language that gets better because it
>> loses lambdas. :-)
>
> I guess he's basically forcing you to use a named function instead of
> an anonymous one... he's not removing functions.
>
> All in all, to each his own... there's no dearth of languages with
> lambda in them. :-)
Hey, even PHP has them. Though that probably would be a good language
to remove "lambdas" of. }:-) Must be *really* crippled from what I
heard.
>> Ever tried a[1]?
>
> Interesting, no I didn't know that. I guess this ugliness is needed
> to have a separate namespace for variables and functions. Common Lisp
> has the same ugliness.
There are arguments both for Lisp-1 and Lisp-2s. And while I prefer
Lisp-1s, object-oriented languages are "better off" if they are
Lisp-2s IMHO.
Christian Neukirchen
Katsu!
http://www.buddhamind.info/leftside/arty/requiz/lit.htm
> Florian Frank
David A. Black
On Sun, 20 Mar 2005, Christian Neukirchen wrote:
> Navindra Umanee <navi...@cs.mcgill.ca> writes:
>
>> Christian Neukirchen <chneuk...@gmail.com> wrote:
>>>> I'm not sure how that could be improved, since it's already doing what
>>>> it was designed to do.
>>>
>>> I think you can write foo {|x|...}, {|y|...} with recent CVS.
>>
>> What does the syntax for yield look like then?
>
> No yield:
>
> def foo(x, y)
> x.call
> y.call
> end
>
> foo {|x|...}, {|y|...}
I don't think you can do that, without parentheses:
irb(main):008:0> def foo(x, y)
irb(main):009:1> x.call
irb(main):010:1> y.call
irb(main):011:1> end
=> nil
irb(main):012:0> foo {|| }, {|| }
SyntaxError: compile error
(irb):12: syntax error
foo {|| }, {|| }
^
(That's CVS from about 10 minutes ago :-)
Joel VanderWerf
>>>Proper OO? Um, well how can you justify:
>>>
>>>a = [1, 2]
>>>a[1]
>>>
>>>but not:
>>>
>>>a = lambda{|x|x*2}
>>>a(1)
>>
>>Ever tried a[1]?
>
>
> Yes, but since it looks like indexing and forces to
> go back and find out what 'a' is, operator() would
> be extremely useful. We will hopefully see that based
> on recent comments by matz-uo[1].
If "operator()" is syntax sugar for some method (#call, say), then you
still have to go look at what 'a' is to find out what it does. Maybe #()
is defined for some Array instances.
I _like_ Proc#[] because it can waddle in(*) for Hash#[] and Array#[].
(*) - to waddle in is the same as to stand in, except that the maneuver
is performed by a duck.
Florian Frank
>Very sweet. How does this work, internally? Have lambdas been
>specialcased at the interpreter level?
>
>
There is a NODE_LAMBDA now, but the () change seems to be independent
of the introduction of the f = { |x, y| x + y } syntax.
Internally a method call to variable 'a' is changed to a call to "call"
on the referenced object. This means, it's also possible to define call
methods in arbitrary objects or classes, like this:
class Hash
def call(x)
self[x]
end
end
fib = Hash.new do |f, i|
f[i] = case i
when 0 then 0
when 1 then 1
else f(i - 1) + f(i - 2)
end
end
p fib(25)
--
Florian Frank
Yukihiro Matsumoto
In message "Re: Paul Graham recommends Ruby"
on Sun, 20 Mar 2005 05:42:59 +0900, "David A. Black" <dbl...@wobblini.net> writes:
|Matz: can you clarify where this is going?
Nowhere. I'm just experimenting new syntax, such as
* a lambda without "lambda"
* call without "call"
* explicit block local variables
* etc.
They are fragile by nature. They might be removed in the future.
matz.
Michael Campbell
From that article:
"filter(P, S) is almost always written clearer as [x for x in S if P(x)]"
Wow. He and I clearly have different views of "clear".
Navindra Umanee
> I'm getting very confused by all of this, especially calling a lambda
> with (). (I know it's a popular idea, is done in other languages,
> etc. I mean I'm getting confused by how all these things fit into
> Ruby.)
Why? It seems natural to call a function with ().
-N.
Navindra Umanee
> But it's fine with me. Not that I liked Python before that decision.
> But Graham will(does?) now probably push a different language, since
> he really is pro-Lisp, not pro-Python.
This thread was started because he seemed to be pushing Ruby. In any
case, Graham has his own agenda and will probably be pushing Arc if
it's ever released.
http://www.paulgraham.com/arc.html
Cheers,
Navin.
vruz
> case, Graham has his own agenda and will probably be pushing Arc if
> it's ever released.
>
> http://www.paulgraham.com/arc.html
You seem to really have a hard time believing someone IS pushing Ruby :-)
Navindra Umanee
I honestly have no idea what you're talking about... I push Ruby
myself. :-)
-N.
Aredridel
I rather like the idea of a lambda without lambda, and moreso the call
without #call. I can see the fragility, but I've wanted it. I'd love it
if it's possible without wrecking things.
Kent Sibilev
Hm, strange
irb(main):001:0> l = {|x| puts x*2}
=> #<Proc:0x00338710@(irb):1>
irb(main):002:0> l(2)
4
=> nil
irb(main):003:0> {|x| puts x*2}(2)
SyntaxError: compile error
(irb):3: parse error
{|x| puts x*2}(2)
^
from (irb):3
Kent.
Christian Neukirchen
And S.find_all { |x| P(x) } is even more readable. :-)
(What happened to the S.find_all &:P idea, btw?)
> Wow. He and I clearly have different views of "clear".
Good for you. :-)
Christian Neukirchen
gabriele renzi
I agree, even if I think a little messing up it's ok, if the stuff that
gets broken is in remote corners. I don't expect ruby to be the same for
ever.
Florian Gross
> Hm, strange
>
> irb(main):001:0> l = {|x| puts x*2}
> => #<Proc:0x00338710@(irb):1>
> irb(main):002:0> l(2)
> 4
> => nil
> irb(main):003:0> {|x| puts x*2}(2)
> SyntaxError: compile error
> (irb):3: parse error
> {|x| puts x*2}(2)
> ^
> from (irb):3
By design, it's only intended to work for local variables for now AFAIK.
Florian Gross
> (What happened to the S.find_all &:P idea, btw?)
We can do that:
class Symbol
def to_proc()
lambda { |other, *args| other.send(self, *args) }
end
end
irb(main):001:0> [1, 2, 3, 4].inject(&:+)
=> 10
irb(main):002:0> %w(foo bar qux).map(&:reverse)
=> ["oof", "rab", "xuq"]
David A. Black
I don't think anyone does. But that doesn't mean that every aspect of
its design has to have a countdown to removal or change, nor that new
things have to be added to it constantly. It *is* a good programming
language, you know :-)
In any case, I'm not concerned about things breaking at 2.0. For me,
these "x without x" things are more a matter of too many shortcuts
and additions that don't feel entirely integral with the language.
For example, {|| } (lambda without lambda). For me, the question is
not whether it's possible to understand it (which it is). Rather,
the question is: if Ruby had been designed from the ground up with a
literal function constructor, would it have been {|| } ? If so, then
fine. If not, then {|| } would be an add-on that is not properly
integrated into the language.
And if the language really needs a literal function constructor, then
the best possible one should be chosen and everything else should be
rolled back until that constructor can be accomodated. And if too
much is rolled back -- if the language overall suffers -- then it
shouldn't be done.
I *think* that this is reasonably close to how Matz approaches things.
The lesson one learns repeatedly in all of this is: trust Matz -- he's
good at this! :-)
David A. Black
Thanks for the clarification :-)
David A. Black
I'm not sure about the naturalness of it -- I'm more thinking about
the fact that () isn't a method, whereas x(), where x is an object
reference (rather than a method identifier), looks like you're calling
the method () on x.
In other words, given this:
def a; end
b = lambda {}
a and b are not the same thing or kind of thing, but allowing a() and
b() (rather than a() and b.call) makes them appear the same. (I know
that they are both callable things, in a sense, but I'm examining it
at a more granular level.)
When I say I am confused by how this fits into Ruby, what I mean is
that it seems like a step toward some kind of method/lambda
unification, but not really a whole unification design. Matz's
explanation of these as experimental changes makes sense of that
perception.
Christian Neukirchen
ES
Agreed. I think it's healthy to throw ideas around, of course:
if someone thinks that a particular enhancement would work to
the advantage of the language then it should be by all means
voiced if only to see if others feel the same way. It could
even be seen as the responsibility of the community to provide
feedback to the language developers in the form of suggestions
as well as the obvious bug reports and such.
I suppose the important thing, though, is to not _demand_ things
(particularly since this service is provided free) and to not
be horribly insulted if one's suggestion is not viewed as essential
by others or even flat-out shot down (though courtesy could
certainly be reasonably expected from the duck hunters, too).
>In any case, I'm not concerned about things breaking at 2.0. For me,
>these "x without x" things are more a matter of too many shortcuts
>and additions that don't feel entirely integral with the language.
>
>For example, {|| } (lambda without lambda). For me, the question is
>not whether it's possible to understand it (which it is). Rather,
>the question is: if Ruby had been designed from the ground up with a
>literal function constructor, would it have been {|| } ? If so, then
>fine. If not, then {|| } would be an add-on that is not properly
>integrated into the language.
Excellent point of view. Thanks!
>And if the language really needs a literal function constructor, then
>the best possible one should be chosen and everything else should be
>rolled back until that constructor can be accomodated. And if too
>much is rolled back -- if the language overall suffers -- then it
>shouldn't be done.
For this particular issue I simply advocate formal first-order
functions of which class/instance methods are just, ah, special
lambda instances with certain scope and parameter bindings. I
certainly have no deep qualms with the current implementation
but, in my lay opinion, such a change would make things more
straightforward (to a user; it might be a language developers'
nightmare). Then again, I like Haskell.
>I *think* that this is reasonably close to how Matz approaches things.
>The lesson one learns repeatedly in all of this is: trust Matz -- he's
>good at this! :-)
Agreed.
>David
E
Navindra Umanee
> I'm not sure about the naturalness of it -- I'm more thinking about
> the fact that () isn't a method, whereas x(), where x is an object
> reference (rather than a method identifier), looks like you're calling
> the method () on x.
It isn't a method in 1.9? Well, maybe it will be made a method or at
least a synonym/alias for call, although I guess that parsing-wise you
might have to find a compromise.
x() doesn't really look like a method any more than x[] does...
Cheers,
Navin.
David A. Black
On Mon, 21 Mar 2005, Navindra Umanee wrote:
> David A. Black <dbl...@wobblini.net> wrote:
>> I'm not sure about the naturalness of it -- I'm more thinking about
>> the fact that () isn't a method, whereas x(), where x is an object
>> reference (rather than a method identifier), looks like you're calling
>> the method () on x.
>
> It isn't a method in 1.9?
No:
irb(main):006:0> {||}.methods.grep(/\(/)
=> []
> Well, maybe it will be made a method or at least a synonym/alias for
> call, although I guess that parsing-wise you might have to find a
> compromise.
>
> x() doesn't really look like a method any more than x[] does...
Actually there's a kind of double reasoning process involved here.
x[] is a method designed *not* to look like a method -- but it *is* a
method, can be redefined, etc. Therefore, () attached to a variable,
while also not looking like a method, looks like it should be one of
those things that don't look like methods but actually are. So it's
really within the framework of this kind of Ruby idiom that what I'm
saying applies.
That's why the overall naturalness or universality of () as a call-ish
thing isn't (for me()) the key thing. I don't want lambdas to know
about () unless () is a method. The best analogy is container
objects, which don't automatically know that they can be indexed with
[] but come to that point through the definition of the method #[].
(I offer the analogy for its explanatory power, not because it proves
that () "should" behave analogously -- though I think it should :-)
Malte Milatz
> Try the 1.9 cvs version:
>
> irb(main):001:0> a = lambda { |x| x * 2 }
> => #<Proc:0xb7c6118c@(irb):1>
> irb(main):002:0> a(1)
> => 2
> irb(main):003:0> a 1
> => 2
I don't know whether I like that. If I understand correctly, it means that
a is an Object, whilst a() calls a.call. So the rule "parentheses are
optional" is no longer valid now.
To me, the following would make more sense (though it isn't Ruby anymore,
neither is it pragmatic):
a = define(:b) do |x|
x*2
end
a.class --> Method
a.call(2) --> 4
a[2] --> 4
b(2) --> 4
b 2 --> 4
define(:c, a)
c(2) --> 4
tony summerfelt
>TCL definitely doesn't qualify as a "cool dynamic language". :-)
i dunno, i think:
pack [button .b -text "quit" -command{exit}]
is pretty cool.
if i need a quickie gui tool for anything (or platform) i turn to
tcl/tk time and again. of course it's the 'tk' part that makes tcl
really useful.
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Daniel Amelang
will unambiguisly belong to blocks?
I know it's rather extreme, but it would solve the problem with having
to put the empty pipes in our blocks, which is...ok, just not great.
{|| puts "hello"} Ugh.
Let's see... how do these look?
hash = <name:bill, age:25>
hash = (name:bill, age:25) # I don't really like this one
hash = [name:bill, age:25] # this infringes on Array's syntax
Oh well, just a thought.
Dan
Nikolai Weibull
> hash = [name:bill, age:25] # this infringes on Array's syntax
Well, that could work, as it will be obvious that its a hash due to the
keys,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: minimalistic.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
David A. Black
On Mon, 21 Mar 2005, Nikolai Weibull wrote:
> * Daniel Amelang (Mar 20, 2005 21:10):
>> hash = [name:bill, age:25] # this infringes on Array's syntax
>
> Well, that could work, as it will be obvious that its a hash due to the
> keys,
What would this be:
[]
?
I think if {} were to be given over entirely to blocks and procs then
it would be time to use Hash.new and Hash.[] exclusively.
Nikolai Weibull
> > > hash = [name:bill, age:25] # this infringes on Array's syntax
> > Well, that could work, as it will be obvious that its a hash due to
> > the keys,
> What would this be:
> []
An empty hash/list? A proxy that defines its behavior depending on
furter use? I'm being silly,
Martin DeMello
>
> Actually there's a kind of double reasoning process involved here.
> x[] is a method designed *not* to look like a method -- but it *is* a
> method, can be redefined, etc. Therefore, () attached to a variable,
> while also not looking like a method, looks like it should be one of
> those things that don't look like methods but actually are. So it's
> really within the framework of this kind of Ruby idiom that what I'm
> saying applies.
If () ever gets to the stage where it works on literals as well as
variables, having the syntax be () and the method be #call will be
precisely analogous to the syntax for...in calling the method #each. So
at least there's some sort of precedent, and () looks far more rubyish
than for...in does.
martin
Hal Fulton
IIRC David doesn't like for/in either. :) Though I do.
I have to admit his recent posts have made me see his point far
better than I did before. But I am still happy that Matz is making
the decision, not anyone else.
And, of course, I am not saying Matz is infallible. But I do say he
is smarter than I am (though he would not say so himself).
Hal
David A. Black
On Mon, 21 Mar 2005, Martin DeMello wrote:
> David A. Black <dbl...@wobblini.net> wrote:
>>
>> Actually there's a kind of double reasoning process involved here.
>> x[] is a method designed *not* to look like a method -- but it *is* a
>> method, can be redefined, etc. Therefore, () attached to a variable,
>> while also not looking like a method, looks like it should be one of
>> those things that don't look like methods but actually are. So it's
>> really within the framework of this kind of Ruby idiom that what I'm
>> saying applies.
>
> If () ever gets to the stage where it works on literals as well as
> variables,
It doesn't work on either right now, though, just on method
identifiers.
> having the syntax be () and the method be #call will be
> precisely analogous to the syntax for...in calling the method #each. So
> at least there's some sort of precedent, and () looks far more rubyish
> than for...in does.
I admit that for...in analogies don't do a whole lot for me -- it's
not my favorite :-) But I don't think the case is exactly the same.
It's not so much the call/() thing as the method/lambda thing that I
find incongruous -- that is, putting () after a variable that refers
to a lambda and have the variable sort of morph into the equivalent of
a method name. Or something like that.
Daniel Amelang
(leaving us only Hash.new) than the adding block syntax with empty
pipes {|| puts 'eek'}. If the {} hash constructor is the *only* thing
between us and making {} refer to blocks and blocks only, I think it's
worth the loss.
Alternatively, you could make [:] the empty hash constructor. Quite a
shortcut for an associative array, if I do say so myself :)
Dan
Nikolai Weibull
> Alternatively, you could make [:] the empty hash constructor. Quite a
> shortcut for an associative array, if I do say so myself :)
Heh, that was a quite nice solution actually,
Douglas Livingstone
<mailing-lis...@rawuncut.elitemail.org> wrote:
> * Daniel Amelang (Mar 21, 2005 00:30):
> > Alternatively, you could make [:] the empty hash constructor. Quite a
> > shortcut for an associative array, if I do say so myself :)
>
> Heh, that was a quite nice solution actually,
> nikolai
As symbols are often used as keys, how about describing a hash as a
'symbolised array', like so:
:[:key => 'value', :foo => 'bar']
or an empty one:
:[]
Douglas
Daniel Amelang
:[:key => 'value', :foo => 'bar']
over this:
[key:value, foo:bar] (the key:value syntax is already part of ruby 1.9)
I'd be interested in the explaination of your preference.
About the empty hash idea, the :[] syntax represents a symbol (try
this '"[]".to_sym), so it might not be such a good idea.
Then again, I am no matz :)
Dan
Martin DeMello
>
> hash = <name:bill, age:25>
> hash = (name:bill, age:25) # I don't really like this one
> hash = [name:bill, age:25] # this infringes on Array's syntax
[: name:bill, age:25 ]
or not. too few brackety things around :)
martin
Martin DeMello
> not whether it's possible to understand it (which it is). Rather,
> the question is: if Ruby had been designed from the ground up with a
> literal function constructor, would it have been {|| } ? If so, then
> fine. If not, then {|| } would be an add-on that is not properly
> integrated into the language.
That's an excellent way of looking at it.
martin
gabriele renzi
> I admit that for...in analogies don't do a whole lot for me -- it's
> not my favorite :-) But I don't think the case is exactly the same.
> It's not so much the call/() thing as the method/lambda thing that I
> find incongruous -- that is, putting () after a variable that refers
> to a lambda and have the variable sort of morph into the equivalent of
> a method name. Or something like that.
notice that it is not a lambda thing.. is something done for callable
objects:
>> a='yu '
=> "yup"
>> def a.call( other) 'yuk yukl' end
=> nil
>> a 10
=> "yuk yukl"
I think of it as to_str, a way to duck type a callable.
Mathieu Bouchard
On Sun, 20 Mar 2005, ES wrote:
> >Ever tried a[1]?
> Yes, but since it looks like indexing and forces to
> go back and find out what 'a' is, operator() would
> be extremely useful. We will hopefully see that based
> on recent comments by matz-uo[1].
Given that a system like Mathematica uses [] for both function-calls and
indexing, and that BASIC instead uses () for both, and that most math
textbooks define sequences as being just functions with a natural domain,
.. well, I don't know what you're complaining about.
Is it because it doesn't look enough like C++ ?
PS: (the Tcl language uses [] for function-calls, and () for indexing!
except when the actual indexing is a function-call itself, of course)
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard
On Sun, 20 Mar 2005, David A. Black wrote:
> I'm not sure anything's new in that CVS feature except:
> my_lambda = {|| puts "I am a lambda"}
> where the || (with or without a param list) tells you that it's a
> lambda rather than a hash.
> I'm not a fan of this; I prefer using the lambda keyword.
Why not alias lambda/proc to L ? it would be just one more character to
type than the new syntax when there are arguments, and one _less_
character when there are none. And no syntax changes.
precedent: there's already a method called p.
Florian Frank
> For example, {|| } (lambda without lambda). For me, the question is
> not whether it's possible to understand it (which it is). Rather,
> the question is: if Ruby had been designed from the ground up with a
> literal function constructor, would it have been {|| } ? If so, then
> fine. If not, then {|| } would be an add-on that is not properly
> integrated into the language.
I think "f = {|| }" is analogous to "def f() end", and I really like it.
(To say the truth, this syntax for lambda is part of the language of my
dreams. ;) It would be even nicer, if the shortcut "f = {}" would be
possible as well, but the empty Hash constructor collides with that
syntax. Like others have said before, I'd rather substitute the hash
constructor (but only in Ruby 2.0) with another syntax to get the "{}".
It's associated in C-languages with "code to be executed" anyway, so it
would meet newbie's expectations AND it would make Ruby more
self-consistent.
BTW: Is a syntax planned to define default values for blocks? It would
be good to be able to define a method
def f(x = 1) 2 * x end
with a block like
define_method(:f) { |x=1| 2 * x }
I think blocks and methods should be as similar as possible, and this
would help a lot. (Or what about keyword arguments for Ruby 2.0?)
The implementation of call without "call" is another thing: it seems to
be rather hackish at the moment. Expressions like f()() for f = {|| {||
1} } aren't possible, while f()[] is. Perhaps it would be better, to
leave this unchanged, and rely only on the #[] method instead. It would
be easier to explain, that f() is a call to the bound method f of self,
while f[] is a call to the #[] method of object f, which could be a
Proc. f could be bound to an object/class with define_method(:f, &f) and
then called from this object's context as f or f().
Ah, and now it's possible to have SyntaxErrors in 1.9, if you first ask
for them:
a = :outer
f = {|;a| a = :inner } # local variable name conflict
Is this useful? I don't see, in which case it would be.
--
Florian Frank
Csaba Henk
> The implementation of call without "call" is another thing: it seems to
> be rather hackish at the moment. Expressions like f()() for f = {|| {||
> 1} } aren't possible, while f()[] is. Perhaps it would be better, to
> leave this unchanged, and rely only on the #[] method instead. It would
> be easier to explain, that f() is a call to the bound method f of self,
> while f[] is a call to the #[] method of object f, which could be a
> Proc. f could be bound to an object/class with define_method(:f, &f) and
> then called from this object's context as f or f().
What I don't get: why is the restriction that the "(*) falls back to
#call" thingy works ony for locals? Locals are just the most problematic
case!
5(), {|x| x+x}(), $aaa(), @b()
would unambigously mean a hidden call to #call (I mean, without knowing
of the context). Unlike
abc()
which can now mean both self.abc and abc.call, depending on context.
So, given that this sugaring of #call is introduced, if I made any
restrictions, the first case which I would exculde is applying this
construct to locals!
But, rather, I wouldn't restrict then anything. As I see, upon
evaluating some construct, ruby didn't care about the syntactical form,
only the return value of the given chunk of code. That is,
5 + case i
when String; i.to_i
when Numeric; i
else 0
end
works just as fine as
5 + 4
or as
5 + i
A kind of duck typing: if it quacks back a foo, then that foo can be
used as validly as a literal foo. (Aka "statements also have return
values").
Now it's pretty violated by this locals-restricted new syntax, and I
don't see the tradeoff behind. What purpose is served by this
restriction?
Csaba
David A. Black
On Mon, 21 Mar 2005, Florian Frank wrote:
> David A. Black wrote:
>
>> For example, {|| } (lambda without lambda). For me, the question is
>> not whether it's possible to understand it (which it is). Rather,
>> the question is: if Ruby had been designed from the ground up with a
>> literal function constructor, would it have been {|| } ? If so, then
>> fine. If not, then {|| } would be an add-on that is not properly
>> integrated into the language.
>
> I think "f = {|| }" is analogous to "def f() end", and I really like it. (To
> say the truth, this syntax for lambda is part of the language of my dreams.
> ;) It would be even nicer, if the shortcut "f = {}" would be possible as
> well, but the empty Hash constructor collides with that syntax. Like others
> have said before, I'd rather substitute the hash constructor (but only in
> Ruby 2.0) with another syntax to get the "{}". It's associated in C-languages
> with "code to be executed" anyway, so it would meet newbie's expectations AND
> it would make Ruby more self-consistent.
I don't think making Ruby resemble other languages makes it
*self*-consistent, but rather more consistent with languages other
than itself. I'm also not a big believer in meeting nubies'
expectations. Especially for Ruby 2.0... it's definitely past the
point of needing to "make <other language> programmers feel at home."
They will, if they like Ruby, and meanwhile it's important for Ruby
programmers to feel at home :-)
> BTW: Is a syntax planned to define default values for blocks? It would be
> good to be able to define a method
> def f(x = 1) 2 * x end
> with a block like
> define_method(:f) { |x=1| 2 * x }
> I think blocks and methods should be as similar as possible, and this would
> help a lot. (Or what about keyword arguments for Ruby 2.0?)
There's a strong case to be made for unification of blocks, lambdas,
Procs, and methods. I'm not sure where Matz stands on that at the
moment.
David A. Black
But this notion of "a callable" collapses things which really aren't
the same.
If I can do this:
a = Object.new; def a.call(x); end
def b(x); end
a(10)
b(10)
but I can't do this:
c = [a,b]
because one of these is an object reference and the other is a method
identifier, then the parallel is only partial and, in my view, causes
more problems than it solves.
If lambdas and methods were completely unified, and really flowed into
each other, that would be different. But this is a kind of selective
magic that obscures a difference between them without redesigning the
difference away.
Christian Neukirchen
> On Sun, 20 Mar 2005, David A. Black wrote:
>
>> I'm not sure anything's new in that CVS feature except:
>> my_lambda = {|| puts "I am a lambda"}
>> where the || (with or without a param list) tells you that it's a
>> lambda rather than a hash.
>> I'm not a fan of this; I prefer using the lambda keyword.
>
> Why not alias lambda/proc to L ? it would be just one more character to
> type than the new syntax when there are arguments, and one _less_
> character when there are none. And no syntax changes.
Rather, extend Ruby to handle uncode identifiers!! (or can it already?)
http://kronavita.de/chris/graphics/ruby-emacs.png
(That's faking by the editor, though.)
> precedent: there's already a method called p.
Seriously, I could live with L, but would use lambda nevertheless. It
has a nice ring to my lispy ears. :-)
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Florian Frank
> On Mon, 21 Mar 2005, Florian Frank wrote:
> I don't think making Ruby resemble other languages makes it
> *self*-consistent, but rather more consistent with languages other
> than itself.
Hey, this is the language of my dreams, it does only exist there. In
dreamland I am also smart enough, to make my own language, while in
reality I have to hope, that my dreams and Matz' are compatible. ;)
Moving from to {} for hashes and {} for blocks, to {} only for blocks
and something else for hashes surely does increase self-consistency.
This also would make parsing Ruby easier, consider for example this case:
def foo(h) :ok end
foo :hello # => :ok
but
foo {} # => ArgumentError: wrong number of arguments (0 for 1)
while
foo({}) # => :ok
> I'm also not a big believer in meeting nubies'
> expectations. Especially for Ruby 2.0... it's definitely past the
> point of needing to "make <other language> programmers feel at home."
> They will, if they like Ruby, and meanwhile it's important for Ruby
> programmers to feel at home :-)
I don't have any against it, but I fear it's also a trap to rely solely
one culture and heritage, while ignoring common sense and human
expectation. It's charming to have car and cdr in a language, if you're
interested in history, but it's also difficult to justify in any other
way than just saying, we always did it that way. For new users that
haven't their brains warped already, it's also difficult to understand,
that you have to use length($s) to get the length of a string in Perl,
while you have to use scalar @a to get the length of an array (or even
scalar keys %h for the size of a hash). I'd rather avoid Ruby going into
this direction, if it is possible.
--
Florian Frank
David A. Black
On Mon, 21 Mar 2005, Florian Frank wrote:
> David A. Black wrote:
>
>> On Mon, 21 Mar 2005, Florian Frank wrote:
>> I don't think making Ruby resemble other languages makes it
>> *self*-consistent, but rather more consistent with languages other
>> than itself.
>
> Hey, this is the language of my dreams, it does only exist there. In
> dreamland I am also smart enough, to make my own language, while in reality I
> have to hope, that my dreams and Matz' are compatible. ;)
>
> Moving from to {} for hashes and {} for blocks, to {} only for blocks and
> something else for hashes surely does increase self-consistency. This also
> would make parsing Ruby easier, consider for example this case:
>
> def foo(h) :ok end
>
> foo :hello # => :ok
>
> but
>
> foo {} # => ArgumentError: wrong number of arguments (0 for 1)
>
> while
>
> foo({}) # => :ok
Are you saying you'd like to have foo {} be the same as foo({})
(assuming both are lambdas/blocks)? But then, what about:
def foo; end
foo {} # called with block, or wrong # of arguments?
As often happens, the solution:
foo() {}
involves more punctuation :-)
>> I'm also not a big believer in meeting nubies'
>> expectations. Especially for Ruby 2.0... it's definitely past the
>> point of needing to "make <other language> programmers feel at home."
>> They will, if they like Ruby, and meanwhile it's important for Ruby
>> programmers to feel at home :-)
>
> I don't have any against it, but I fear it's also a trap to rely solely one
> culture and heritage, while ignoring common sense and human expectation.
But Ruby isn't within miles of having that problem. My point is that
I don't like the idea of just putting things in Ruby because they are
the culture and heritage of *other* languages. Nor do I think that if
something is part of the culture and heritage of Ruby, it therefore
has to be removed :-) (I know you weren't saying that.)
> It's
> charming to have car and cdr in a language, if you're interested in history,
> but it's also difficult to justify in any other way than just saying, we
> always did it that way. For new users that haven't their brains warped
> already, it's also difficult to understand, that you have to use length($s)
> to get the length of a string in Perl, while you have to use scalar @a to get
> the length of an array (or even scalar keys %h for the size of a hash). I'd
> rather avoid Ruby going into this direction, if it is possible.
My point exactly :-)
When it comes to nubies, I think there's a big difference between (a)
things they might find slightly surprising (but that are actually
completely logical, once you "get" the language), and (b) things that
are going to attract them to the language. If you say to someone:
Ruby offers you the ability to write top-level scripts, like Perl, and
also has OO designed into it from the ground up -- that might get
their attention. If you say: As of version 2.0, you don't have to use
the lambda keyword because {} has been repurposed as a function
constructor -- I don't think that's going to make someone go, "Wow!
That sounds like the language for me!" :-)
Florian Frank
> Are you saying you'd like to have foo {} be the same as foo({})
Not necessarily, I only pointed out, that there is a problem, that could
be resolved with a different empty hash constructor, like
def foo(h) h.class end
foo [:] # => Hash
Or even Hash[] and Hash['a': 1, 'b': 2] for Hash.[]. It would also be
possible to have Tree['a': 1, 'b': 2] in this case. What is the impact
on the planned keyword syntax in this case?
> (assuming both are lambdas/blocks)? But then, what about:
>
> def foo; end
> foo {} # called with block, or wrong # of arguments?
>
> As often happens, the solution:
>
> foo() {}
>
> involves more punctuation :-)
True, but the real source of the problem is, that Ruby handles block
parameters differently than other parameters. I don't think, that this
is really necessary, things could be made far easier here.
It's difficult to answer questions, like: Why don't I have to declare
block parameters like other parameters? But if I do, why do I have to
use this weird &-sigil? Why do I have to use it, if I want to pass the
block to another method, that expects a block? Why can I call every
method, that doesn't expect a block, with a block, that will be silently
ingored? Why can't I pass more than one block to a method?
The answers to those question would perhaps include, that the block
syntax wasn't intended be of such a general usefulness for functional
objects, closures and the like, but only as an iteration construct. For
2.0 it would be a good idea, to get rid of this bad legacy. It would
perhaps be a good idea to make {} the Proc constructor, abandon
non-objectified blocks (what about the performance trade off?) in favor of
def foo(block)
block[]
end
foo {}
or
def foo(b1, b2)
b1[]
b2[]
end
foo {}, {}
and perhaps define the following
def foo(b1, b2)
b1.call
yield # always the last block declared is executed
end
> But Ruby isn't within miles of having that problem. My point is that
> I don't like the idea of just putting things in Ruby because they are
> the culture and heritage of *other* languages. Nor do I think that if
> something is part of the culture and heritage of Ruby, it therefore
> has to be removed :-) (I know you weren't saying that.)
>
I suspect, things got screwed up step by step in Perl, too. This will
always be a problem, if people stop asking questions (like I did above),
why things are done in this and such a way, even if the answers cannot
really satisfy.
--
Florian Frank
David A. Black
On Tue, 22 Mar 2005, Florian Frank wrote:
> True, but the real source of the problem is, that Ruby handles block
> parameters differently than other parameters. I don't think, that this is
> really necessary, things could be made far easier here.
I still don't have my head around the new block param syntax... but
isn't it going to be more different from methods than the current one?
> It's difficult to answer questions, like: Why don't I have to declare block
> parameters like other parameters? But if I do, why do I have to use this
> weird &-sigil? Why do I have to use it, if I want to pass the block to
> another method, that expects a block? Why can I call every method, that
> doesn't expect a block, with a block, that will be silently ingored? Why
> can't I pass more than one block to a method?
Some of these questions are harder than others :-) To the last two, I
would say: every method call can take an optional code block, to which
transfer can be controlled with 'yield'. I guess I accept that as a
design characteristic.
> The answers to those question would perhaps include, that the block syntax
> wasn't intended be of such a general usefulness for functional objects,
> closures and the like, but only as an iteration construct. For 2.0 it would
> be a good idea, to get rid of this bad legacy. It would perhaps be a good
> idea to make {} the Proc constructor, abandon non-objectified blocks (what
> about the performance trade off?) in favor of
>
> def foo(block)
> block[]
> end
> foo {}
>
> or
>
> def foo(b1, b2)
> b1[]
> b2[]
> end
> foo {}, {}
>
> and perhaps define the following
>
> def foo(b1, b2)
> b1.call
> yield # always the last block declared is executed
> end
That leaves me asking: if yield has this situation-dependent behavior,
why does it exist at all? I'm afraid to say it -- I don't want to
appear too non-questioning :-) -- but I actually like the singularity
of the block/yield chain. If the block is done away with (not likely,
I suspect), then 'yield' makes no sense. If one were designing a
language where blocks were always objectified and always treated as
regular arguments, I don't think one would ever come up with the idea
of a special keyword to call the last one in a list.
>> But Ruby isn't within miles of having that problem. My point is that
>> I don't like the idea of just putting things in Ruby because they are
>> the culture and heritage of *other* languages. Nor do I think that if
>> something is part of the culture and heritage of Ruby, it therefore
>> has to be removed :-) (I know you weren't saying that.)
>>
> I suspect, things got screwed up step by step in Perl, too. This will always
> be a problem, if people stop asking questions (like I did above), why things
> are done in this and such a way, even if the answers cannot really satisfy.
I don't think we're in any danger of people not questioning Ruby's
design enough :-)
Florian Gross
> Rather, extend Ruby to handle uncode identifiers!! (or can it already?)
Yes. Use ruby -Ku.
Daniel Berger
I vote we leave well enough alone. All this mess so we can avoid
typing the word "proc"?
As I think David Black mentioned in one of his posts, this doesn't feel
like a unification of the proc/lambda/Proc/block syntax. It feels more
like we're just shifting ownership of "{}" to another class.
Towards what end is this heading?
Regards,
Dan
gabriele renzi
> But this notion of "a callable" collapses things which really aren't
> the same.
>
> If I can do this:
>
> a = Object.new; def a.call(x); end
> def b(x); end
>
> a(10)
> b(10)
>
> but I can't do this:
>
> c = [a,b]
>
> because one of these is an object reference and the other is a method
> identifier, then the parallel is only partial and, in my view, causes
> more problems than it solves.
but we already have something similar, CapitalNamed methods:
>> def B(x) 'yuk' end
=> nil
>> B 10
=> "yuk"
>> B
NameError: uninitialized constant B
and I think this shows the same point to me, meaning that once the
programmmer knows how it works it has quite an understandable behaviour.
Anyway, I understand your point of view, and I'd just expect matz' choice.
He already did the Right Choices enough to make me confident in future
ones :)
Navindra Umanee
> Daniel Amelang wrote:
> > (leaving us only Hash.new) than the adding block syntax with empty
> > pipes {|| puts 'eek'}. If the {} hash constructor is the *only* thing
> > between us and making {} refer to blocks and blocks only, I think
> it's
> > worth the loss.
> >
> > Alternatively, you could make [:] the empty hash constructor. Quite a
> > shortcut for an associative array, if I do say so myself :)
> >
> > Dan
>
> I vote we leave well enough alone. All this mess so we can avoid
> typing the word "proc"?
What mess? Daniel's suggestion unifies the Array/Hash literal syntax
in a pleasant way and makes anonymous block creation a bit more
elegant overall.
> As I think David Black mentioned in one of his posts, this doesn't feel
> like a unification of the proc/lambda/Proc/block syntax. It feels more
> like we're just shifting ownership of "{}" to another class.
I'm not sure if David said that. I think he also said he didn't like
{|| puts "eww"} instead of {puts "this r0x0rs!"}. Unifying the Array/Hash
syntax conveniently provides the latter. I think David also said to
consider how you might design things if you weren't limited by
constraints such as backwards compatibility. People did exactly that.
I'm sure David has other strong opinions that I might have missed though.
Cheers,
Navin.
Christian Neukirchen
> Christian Neukirchen wrote:
>> Navindra Umanee <navi...@cs.mcgill.ca> writes:
>> There are arguments both for Lisp-1 and Lisp-2s. And while I prefer
>> Lisp-1s, object-oriented languages are "better off" if they are
>> Lisp-2s IMHO.
>
> Could you expand on why OO languages are better off as Lisp 2?
Because it is more consistent. I have actually designed a primitive
OO language where methods simply are "instance variables" (well, those
don't exist in it either) bound to a lambda.
However, all(?) ground-breaking OO languages (take Smalltalk, Self
(I'm not sure about Self actually, but I think it makes a difference
between an instance variable containing a block and a method), CLOS,
Ruby :-)) are Lisp-2s. Lisp-1 doesn't match very well with the
"message sending" paradigm, I think.
Steven Shaw
> Rather,
> the question is: if Ruby had been designed from the ground up with a
> literal function constructor, would it have been {|| } ?
Do you mean syntactically? Like instead of Smalltalk like [| ]? or
something else?
> If so, then
> fine. If not, then {|| } would be an add-on that is not properly
> integrated into the language.
and here, more specifically, "not properly integrated into the language
syntax"?
Steve.
David A. Black
On Wed, 23 Mar 2005, Steven Shaw wrote:
> David A. Black wrote:
>
>> Rather,
>> the question is: if Ruby had been designed from the ground up with a
>> literal function constructor, would it have been {|| } ?
>
> Do you mean syntactically? Like instead of Smalltalk like [| ]? or something
> else?
I mean if Matz had wanted such a constructor from the beginning, what
would he have chosen? So much of the discussion of this and other
changes to Ruby involve just trying to find combinations of
punctuation that aren't already taken....
>> If so, then
>> fine. If not, then {|| } would be an add-on that is not properly
>> integrated into the language.
>
> and here, more specifically, "not properly integrated into the language
> syntax"?
"Properly" meaning "in a non-afterthought way". I'm afraid I can't
express it any more technically than that. But think of all the
things in Perl and Python about which people say: that was slapped on
after the language was already designed. There is essentially none of
that in Ruby, which I think is a great situation and one that should
be conserved.
ES
I absolutely agree with you on this and can see how this would be a
concern for this particular addition. To me the current HEAD version,
where {||} must be used for a no-argument proc definition, falls in
this category; while it's useful to be able to omit 'lambda' etc.,
this method of doing it feels distinctly tacked-on. I'm certainly
sympathetic to whoever is writing the parser, of course, and I wouldn't
mind the proposed [:]-syntax for Hashes.
I maintain that this all could be solved with an unification of all
callable code into a single first-order function definition :)
>David
E
Steven Shaw
Steven Shaw
> Hi --
>
> On Wed, 23 Mar 2005, Steven Shaw wrote:
>
>> David A. Black wrote:
>>
>>> Rather,
>>> the question is: if Ruby had been designed from the ground up with a
>>> literal function constructor, would it have been {|| } ?
>>
>>
>> Do you mean syntactically? Like instead of Smalltalk like [| ]? or
>> something else?
>
>
> I mean if Matz had wanted such a constructor from the beginning, what
> would he have chosen? So much of the discussion of this and other
> changes to Ruby involve just trying to find combinations of
> punctuation that aren't already taken....
It's clear that you are talking about syntax. That's all I wanted to
clear up. I'm not making any judgement - just clearing things up.
>>> If so, then
>>> fine. If not, then {|| } would be an add-on that is not properly
>>> integrated into the language.
>>
>>
>> and here, more specifically, "not properly integrated into the
>> language syntax"?
>
> "Properly" meaning "in a non-afterthought way". I'm afraid I can't
> express it any more technically than that. But think of all the
> things in Perl and Python about which people say: that was slapped on
> after the language was already designed. There is essentially none of
> that in Ruby, which I think is a great situation and one that should
> be conserved.
Yes, I understand where you are coming from.
Cheers,
Steve.