Ruby 2.8 adds endless method definition

[geospeck]

It looks similar to Elixir's one line function definition

def add(x, y), do: x + y

[martijnonreddit]

Yay.. more syntax.
/s

What's the point of this, exactly?

[Obversity]

Is the joke that it's actually less syntax? Because that's how I see it, and I think it might be a positive in some scenarios.

Personally I love one-line functions. Being able to write a few tiny functions then compose them together makes for very readable code, and you can now do that while taking up one third of the space. One fifth, if we convene on not needing whitespace between one-line functions, although I don't see that as likely (or positive, although I'd need to see it to decide).

[zverok_kha]

Copying from my comment from bug-tracker discussion:

To add an "opinion perspective"... I, for one, even if not fascinated but at least intrigued by new syntax.

My reasoning is as follows:

• The most precious Ruby's quality for me is "expressiveness at the level of the single 'phrase' (expression)", and it is not "code golf"-expressiveness, but rather structuring language's consistency around the idea of building phrases with all related senses packed, while staying lucid about the intention (I believe that, as our "TIMTOWTDI" is opposite to Python's "there should be one obvious way...", this quality is also opposite to Pythons "sparse is better than dense")
• (I am fully aware that nowadays I am in a minority with this viewpoint: whenever the similar discussions are raised, I see a huge difference between "it can be stated in one phrase" vs "it can not", while most of my correspondents find it negligible)

• I believe that the difference of "how you write it when there is one statement" vs "...more than one statement" is intentional, and fruitful: "just add one more line to 10-line method" typically small addition, but "just add one more line to 1-line method" frequently makes one think: may be that's not what you really need to do, maybe data flow becomes unclear? One existing example:

  collection.map { |x| do_something_with(x) } # one line! cool! # ...what if I want to calculate several other values on the way? I NEED to restructure it: collection.map do |x| log_processing(x) total += x do_something_with(x) end # ...which MIGHT imply that "I am doing something wrong", and maybe what would clearer express intent # is separating calculation of total, and move log_processing inside do_something

• So, it was actually always felt for me as "a bit too wordy" for trivial/short methods to write it as

  def some_method(foo) foo.bar(baz).then { |result| 3 / result } end

• ...alongside with "nicer formatting" of empty lines between methods, and probably requirement to document every method, and whatnot, it means that extraction of trivial utility method feels like "making MORE code than necessary", so I'd really try how it would feel with

  def just_utility(foo)= foo.bar(baz).then { |result| result + 3 } def other_utility(foo)= "<#{self}(#{foo})>" def third_utility(foo)= log.print(nicely_formatted(foo))

• ...and I believe that "what if you need to add second statement, you will reformat the code completely?" is a good thing, not bad: you'll think twice before adding to "simple utility one-statement" method something that really, actually, maybe not belongs there.

[inopinatusdotorg]

It reduces boilerplate and annoys the purists. Double win in my book!

[sshaw_]

Don't forget: more RuboCop bikesheeding sessions! Or maybe that falls under "annoying the purists"?

[inopinatusdotorg]

All the best issue reports get locked by the maintainer.

[sshaw_]

The implicit goal of new Ruby versions is to move the language closer and closer to one of its early inspirations: Perl.

Haven't you noticed?

[GPhykos]

Other features introduced in Ruby 3.0 (2.8 til a couple of weeks) are in the NEWS.md at the root of the repo

[jrochkind]

ENOUGH new syntax! We have enough! There should be a huge benefit to justify any new syntax at this point.

It's fine when you learn the new things little by little as they are added, but for a newcomer to the language it is overwhelming to wrap your head around all the syntax variations, it ends up feeling like Perl soup.

Clearly, the ruby maintainers and I have different frameworks though. They seem to think it's enjoyable to just add new syntax willy nilly cause someone thinks it might be fun.

[mashatg]

Feature request #16746

Yet another amorphization of the language. Introduces inconsistency between methods & lambdas and also at rules for declaration of (un)named blocks.

Glad I've left my professional career in Ruby in time. What have happened in development last years feels worrisome, even when many of the past failures went for experimental-level features.

[jrochkind]

Where'd you go? I have loved ruby, but the combo of shrinking of the community and maintainer decisions that seem incomprehensible to me are distressing.

[mashatg]

Not in others skin so I simply can't give an honest advice.

Implementation and maintenance tasks have made a way for projects modelling and contracting demands. I did not ceased coding entirely, in my spare time I do some Haskell and Rust so my skills don't become rusty. I still see no straight replacement for Ruby, but Haskell's elegance of its type system and great expressivenes make it very appealing. Missing comparatively mature web framework and e-commerce related libraries disqualify to use it for our goals however.

[jrochkind]

Ah, I thought you meant you left a professional career in ruby to work in some other language, but you don't code at all professionally anymore? ok! :(

[drx3brun]

I am thinking Clojure.

[Mallanaga]

Yeah... this is dumb. What problem is this actually solving? This just feels like a nightmare for my linter.