3 ms·

The following already worked in Ruby for single-line method definitions: def foo(s) s.upcase * 3 end foo "Hey" # => "HEYHEYHEY" No ; and no =

lcnPylGDnU4H9OF 3y ago
I'm not sure when the author added their update but they responded to this point: > What can I say! Once in a while, I forget how to Ruby :) This does not make the argument invalid (this way of writing methods is still frowned upon and never used; and still, reads like “several phrases”), but it probably should’ve been centered around the community’s view at `;`.
- stouset 3y ago
  Introducing new, ambiguously-parsed syntax to avoid an “ugly” semicolon or a bare `end` for code-golfing purposes is an extremely poor trade.
  - lcnPylGDnU4H9OF 3y ago
    I don't disagree, per se, but I think the point is stated too strongly. Linting rules can help to enforce careful use of this syntax even on team projects. The ambiguity can be avoided or explicitly removed as demonstrated with the parentheses around the expressions. It's just another syntax option for defining a method of appropriate simplicity. Ruby already allows for some heinous things: class Foo private # Not actually private def self.bar 'bat' end end define_method(:".38 Special, the band?") { name == '.38 Special' } Be smart about how you use it. A knife manufacturer ships sharp blades despite the possibility that a chef might cut themself with it.
    - trealira 3y ago
      > A knife manufacturer ships sharp blades despite the possibility that a chef might cut themselves with it. This is usually said about necessary but dangerous or easily abusable features, like the use of raw pointers, C++ templates, or global mutable state. I would say that adding potentially confusing syntactic sugar to a programming language is more like adding a feature to a Swiss army knife that is redundant and makes it unnecessarily more complex to use.
deleted 3y ago
[deleted]

lcnPylGDnU4H9OF 3y ago

I'm not sure when the author added their update but they responded to this point: > What can I say! Once in a while, I forget how to Ruby :) This does not make the argument invalid (this way of writing methods is still frowned upon and never used; and still, reads like “several phrases”), but it probably should’ve been centered around the community’s view at `;`.

stouset 3y ago
Introducing new, ambiguously-parsed syntax to avoid an “ugly” semicolon or a bare `end` for code-golfing purposes is an extremely poor trade.
- lcnPylGDnU4H9OF 3y ago
  I don't disagree, per se, but I think the point is stated too strongly. Linting rules can help to enforce careful use of this syntax even on team projects. The ambiguity can be avoided or explicitly removed as demonstrated with the parentheses around the expressions. It's just another syntax option for defining a method of appropriate simplicity. Ruby already allows for some heinous things: class Foo private # Not actually private def self.bar 'bat' end end define_method(:".38 Special, the band?") { name == '.38 Special' } Be smart about how you use it. A knife manufacturer ships sharp blades despite the possibility that a chef might cut themself with it.
  - trealira 3y ago
    > A knife manufacturer ships sharp blades despite the possibility that a chef might cut themselves with it. This is usually said about necessary but dangerous or easily abusable features, like the use of raw pointers, C++ templates, or global mutable state. I would say that adding potentially confusing syntactic sugar to a programming language is more like adding a feature to a Swiss army knife that is redundant and makes it unnecessarily more complex to use.

deleted 3y ago

[deleted]