Yeah, but this is an area where both languages are just a mess. If python's lambda is castrated, ruby's notion of an anonymous function is tumorous. We've got blocks, procs, lambdas and methods? What's the difference?
Ruby mixes up the syntactic requirements of "passing" some code to a loop to iterate with with the data requirements of binding a function to a scope. It's just a huge mess.
LISP and Scheme figured all this out decades ago, and yet only Javascript (and, almost, perl) among common scripting languages has managed to absorb the lesson.
You say "both languages are just a mess" as if to equate the two. But there's no comparison.
Your Ruby problem with blocks and Proc objects is a nit about elegance and semantics. How often does the difference between an actual Proc object and a block actually affect you? More importantly, if the cost of fixing that nit is that we wind up with Lisp's or Javascript's lambda notation, who would accept that? Javascript has relatively consistent semantics for anonymous functions, but extremely clumsy syntax.
Python simply doesn't have real lambdas. It has the ability to pass something called a lambda in place of a function, and that something forces you to think about things like the difference between a statement and an expression. It then tells you that you don't in fact want anonymous functions, but instead you want to define tens of itty bitty named functions and use them instead. You also "want" that "self" argument to all your methods, and you "want" to tack two underscores to the front of your method names to make them private.
So, I half agree with you. Yes, it would be nice if there was a (zero-cost) way of fixing Ruby's block semantics. Yes, I can rely on Lisp's lambda semantics slightly more than I can on Ruby's, which does start to matter when you start writing domain-specific language code. But I don't agree that this has any bearing on the Python vs. Ruby argument. Python lambdas suck.
True python's lambda's suck. And Ruby's lambda's for the most part don't suck.
But ruby's methods really do suck, and so do the complex construction of Blocks. While I recognize that blocks allow you to do weird things (like use return on the calling scope), the fact that they necessitate a special form (yield) and cannot be bound to a variable, and are not passed as standard function parameters just makes them inconsistent and gross.
Methods which aren't first class functions (but can be transformed into one with the helpful helper function!) also suck, and passing those around in a functional way is just a lesson in futility.
All that being said, I have much more faith in these warts being fixed as time goes on, than python's nasty lambda, and the gross over use of dunders.
"the fact that they necessitate a special form (yield) and cannot be bound to a variable, and are not passed as standard function parameters just makes them inconsistent and gross."
Which brings us to another point - when exactly do you actually need them? I have for every 1000 lines of ruby code maybe one line of "yield" code, and this is only to further extend classes for flexibility. Other languages dont allow you to choose what you want to have, ruby does.
You simply have to make decisions when to use what.
For me it is simplicity, elegance and beauty. These are my biggest design criterias.
I'm 100% with you on simplicity, elegance and beauty. I just demand that as much from the design of the languages I use as from my own code.
I've tried to explain it like this. To me ruby feels Turtles all the way down with respect to Objects, but some kind of nightmare tunnel of interleaved beasts down with Functions.
I don't think I should have to make that compromise, so I'll happily go about writing my ruby when I have to, but I'm waiting for the language that is consistent all the way down.
If I could replace every yield I've ever written in ruby with a .call() I would be so much happier :)
Ok, now I'm not sure I follow. Apart from the performance issues, why can't you replace every method that "yields" with a method that takes the explicit block parameter, and .call() it?
No it is not. You dodged the question again, by throwing a hardly related blog of someone else at it.
How many people will use yield _AND_ self.send in the same method please?! That seems like an awfully complicated and contrived example. Who the heck does this?
I think the "can't be bound to a variable" thing is a bit of a red herring too, especially if you're OK with Lisp and Javascript's syntax --- you can create a full-fledged Proc object with "lambda" any time you want.
The inconsistency is annoying, but 99.999% of the time, Ruby is actually giving you what you want.
That's my own language, and quite obscure (FlightGear uses it, and I've done quite a bit with it personally). But if you want to include Lua too, we might as well be consistent. I was trying to stay within languages with which most readers here would be familiar.
As does Eve (http://eve-language.blogspot.com/), as long as we're throwing out pet languages. ;-) Though I just redid virtually everything about Eve (changed it from a multiple-dispatch functional language to a single-dispatch prototype-based functional language) and haven't yet pushed the changes to GitHub.
For that matter, Ocaml/Haskell/Erlang all get it right, and those are not pet languages. And Cecil and Dylan almost get it right, but have some complications introduced by multimethods. So it's really just the popular languages tha screw up.
Yeah, but this is an area where both languages are just a mess. If python's lambda is castrated, ruby's notion of an anonymous function is tumorous. We've got blocks, procs, lambdas and methods? What's the difference?
Ruby mixes up the syntactic requirements of "passing" some code to a loop to iterate with with the data requirements of binding a function to a scope. It's just a huge mess.
LISP and Scheme figured all this out decades ago, and yet only Javascript (and, almost, perl) among common scripting languages has managed to absorb the lesson.