Hacker News Reader

Comment by stdbrouw | Hacker News Reader

Doesn't make it any less annoying to not have them.

Language design, especially syntax design, is always a series of trade-offs. Aside from relatively rare outright mistakes (bitwise precedence in C, associativity of ?: in PHP), most syntax choices that people don't like are done to make something else easier.

I really like blocks, but Python deliberately makes it harder to support those in return for not needing scope delimiters in the majority of code that isn't using blocks. It seems like a reasonable choice to me.

Blocks could be allowed in one liners. That would make Python a credible solution in that use case.

(And yes, not all one liners need it. I know.)

And list comprehensions seems like a kludge from a lack of real lambdas (map). So that is an extra concept.

Edit: Ruby doesn't have closures?!

Edit 2: 2nd paragraph of the linked article: "In Ruby, Objective-C, and C, functions are not first-class objects, they don't capture closures, and they can't be defined inline." For Ruby, that don't claim there are no closures at all. Got it.

Ruby definitely does have closures.

Methods aren't closures in Ruby (though we have procs and lambdas for that), but you certainly can pass methods around. Methods are objects, as are unbound methods. Both of them can be passed as arguments or returned as values. That's the definition of a first-class object.

You don't see the pattern often, as it's far less idiomatic than passing procs as a block, but you can do it.

Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created.

> Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created.

They added that in 2.1 Well, it was always an expression... in Ruby, every statement is an expression. But it always used to return nil. Now it returns the symbol of the method name. Still not as good as returning a method object, but since you can easily get the method object from the symbol, in practice there's no difference.

Honestly, if I had to choose between things I'd like to have in Python that exist in other languages, I'd choose improving the protocol supporting comprehension syntax improved to be more general (like Scala's) over blocks.

While blocks are nice to have, I've yet to see a good proposed syntax for them in Python.

>Language design, especially syntax design, is always a series of trade-offs.

Sure, but then again not all trade-offs make the right trade, err, off.

Even saying "right trade-off" goes against what I'm trying to say. It may be the right trade-off for some users and the wrong trade-off for others. Most of the time, when people say, "this programming language is doing this thing wrong," all it really means is "this isn't the right language for me for this problem."

That means any set of tradeoffs is valid. It's not. Tradeoffs are only OK if what you get back in each option is balanced. In some cases you're trading something very valuable for diminishing returns.

>It may be the right trade-off for some users and the wrong trade-off for others.

Well, then it matters how big are those groups relative to each other, and perhaps which one does something that's more important with the language and more tied to its core principles.

associativity of ?: in PHP

TIL that PHP is even scarier than I thought.

Reply on news.ycombinator.com