4 ms·

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

munificent 12y ago
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.
- BugBrother 12y ago
  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.
  - andrewvc 12y ago
    Ruby definitely does have closures.
  - actsasbuffoon 12y ago
    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.
    - mcphage 12y ago
      > 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.
- dragonwriter 12y ago
  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.
- coldtea 12y ago
  >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.
  - munificent 12y ago
    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."
    - coldtea 12y ago
      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.
- dreamweapon 12y ago
  associativity of ?: in PHP TIL that PHP is even scarier than I thought.

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.

BugBrother 12y ago
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.
- andrewvc 12y ago
  Ruby definitely does have closures.
- actsasbuffoon 12y ago
  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.
  - mcphage 12y ago
    > 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.
dragonwriter 12y ago
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.
coldtea 12y ago
>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.
- munificent 12y ago
  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."
  - coldtea 12y ago
    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.
dreamweapon 12y ago
associativity of ?: in PHP TIL that PHP is even scarier than I thought.