4 ms·

The discussion of Ruby could use a mention of Enumerable. https://ruby-doc.org/core-3.0.2/Enumerable.html https://ruby-doc.org/core-3.0.2/Enumerable.html

softwaredoug 5y ago
Author here, wow that's great! I am still learning Ruby (hence the article to try to grok things).
- pelasaco 5y ago
  as suggestion, regarding the following code: Stuff.new().each do |item| puts item end In idiomatic ruby, we drop this parenthesis, so the code will look like Stuff.new.each ...
  - hirundo 5y ago
    puts Stuff.new.map(&:to_s).join("\n")
- usefulcat 5y ago
  If one is having to implement an each or map or select method in ruby, then I can definitely appreciate the differences you point out. Even though I've been using ruby a long time, it would frankly still be a bit of a pain to have to remember the details of how yield works. Because Enumerable provides so much functionality, I almost never need to implement methods like those. So what I really care about a lot more are the ergonomics of using each, map, select, reject, all?, any?, etc, which I use very frequently.
  - softwaredoug 5y ago
    Yes though the point is the same, Enumerable gives the objects methods (internal iteration), in Python you would use built-ins max or filter or a list comprehension on an iterator (external iteration).
busterarm 5y ago
Indeed. The real magic is when you start doing things like: some_enum.collect(&:+) This simple line will do everything from sum numbers to concatenate strings, etc.
- mikepurvis 5y ago
  Not a rubyist, but I love that collect() made it into Rust, too. I feel like it takes the role that generators have in Python, but is much easier to reason about in terms of the control flow and what data is being passed where.
  - dragonwriter 5y ago
    Enumerable#collect is just an eager version Python map() in method rather than function form (#map is a avaulable as an alias for #collect); it is a little more concise for when the function you are mapping over is a method on the object being processed (even more than Ruby’s normal advantage with lambdas), but not fundamentally more powerful. (Enumerable#lazy gives you an object where collect/map is, and other merhods are, lazy rather than eager.) > I feel like it takes the role that generators have in Python Ruby has generators, though in either Ruby or Python map/collect (the lazy versions, in Ruby) can be used for some of their uses, since it basically produces a generator from an input collection or generator and a mapping function.
    - halostatue 5y ago
      #collect is an alias for #reduce, not #map, making it like Python reduce().
      - dragonwriter 5y ago
        > #collect is an alias for #reduce It’s not, though. (If it was, we could write about its equivalence with Python’s [from functools in py3, core in Py2] reduce function, though, saying much the same thing as about the actual equivalence with map upthread, except reduce/inject is less often a substitute for generators than map/collect.) #map is an alias for #collect. [0] #reduce has the alias #inject. [1] [0] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-collect https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-col... [1] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-inject https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-inj...
ericwood 5y ago
Enumerable is one of my favorite aspects of the Ruby standard library! I've been writing it off and on for quite some time and still discover incredibly useful and elegant functions in there. It's incredibly rare to not find what I need when working with collections.
benbristow 5y ago
C# .NET implements quite a lot of these too via LINQ, albeit with different names (e.g. map is called Select). https://docs.microsoft.com/en-us/dotnet/api/system.linq.enumerable?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.linq.enum...
- TheRealDunkirk 5y ago
  Oy vey, LINQ. Meshuggeneh. Nothing like dropping COMPLETELY out of your language's idiom for a line or two to implement some Enumerable-like behavior.
  - benbristow 5y ago
    I'd argue when I'm writing C# in a web-development setting (ASP APIs etc.) that a large majority of the code is LINQ. Especially if using something like Entity Framework. It's really just part of the language now.
    - TheRealDunkirk 5y ago
      A line of LINQ looks and works nothing like a line of C#, and the difference is even worse in VB. Whether it's "part of the language" or not, it's a fundamentally different way of writing logic than the base language you're writing around it. I agree it's completely coupled with EF, but I hate EF too. (After you've used ActiveRecord for over 10 years, any other ORM just feels like a ball and chain, but that's another topic.)
      - benbristow 5y ago
        I came from a Rails background and it was definitely painful to learn EF since it has a lot of nuances and things you wouldn't know without experience (e.g. How things mutate throughout the object lifecycle, migration funkiness, how tracking works and 'AsNoTracking()' etc.) Think I'd still prefer ActiveRecord really but after you get used to EF (Core) it's still a good tool.
      - 5y ago

softwaredoug 5y ago

Author here, wow that's great! I am still learning Ruby (hence the article to try to grok things).

pelasaco 5y ago
as suggestion, regarding the following code: Stuff.new().each do |item| puts item end In idiomatic ruby, we drop this parenthesis, so the code will look like Stuff.new.each ...
- hirundo 5y ago
  puts Stuff.new.map(&:to_s).join("\n")
usefulcat 5y ago
If one is having to implement an each or map or select method in ruby, then I can definitely appreciate the differences you point out. Even though I've been using ruby a long time, it would frankly still be a bit of a pain to have to remember the details of how yield works. Because Enumerable provides so much functionality, I almost never need to implement methods like those. So what I really care about a lot more are the ergonomics of using each, map, select, reject, all?, any?, etc, which I use very frequently.
- softwaredoug 5y ago
  Yes though the point is the same, Enumerable gives the objects methods (internal iteration), in Python you would use built-ins max or filter or a list comprehension on an iterator (external iteration).

busterarm 5y ago

Indeed. The real magic is when you start doing things like: some_enum.collect(&:+) This simple line will do everything from sum numbers to concatenate strings, etc.

mikepurvis 5y ago
Not a rubyist, but I love that collect() made it into Rust, too. I feel like it takes the role that generators have in Python, but is much easier to reason about in terms of the control flow and what data is being passed where.
- dragonwriter 5y ago
  Enumerable#collect is just an eager version Python map() in method rather than function form (#map is a avaulable as an alias for #collect); it is a little more concise for when the function you are mapping over is a method on the object being processed (even more than Ruby’s normal advantage with lambdas), but not fundamentally more powerful. (Enumerable#lazy gives you an object where collect/map is, and other merhods are, lazy rather than eager.) > I feel like it takes the role that generators have in Python Ruby has generators, though in either Ruby or Python map/collect (the lazy versions, in Ruby) can be used for some of their uses, since it basically produces a generator from an input collection or generator and a mapping function.
  - halostatue 5y ago
    #collect is an alias for #reduce, not #map, making it like Python reduce().
    - dragonwriter 5y ago
      > #collect is an alias for #reduce It’s not, though. (If it was, we could write about its equivalence with Python’s [from functools in py3, core in Py2] reduce function, though, saying much the same thing as about the actual equivalence with map upthread, except reduce/inject is less often a substitute for generators than map/collect.) #map is an alias for #collect. [0] #reduce has the alias #inject. [1] [0] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-collect https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-col... [1] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-inject https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-inj...

ericwood 5y ago

Enumerable is one of my favorite aspects of the Ruby standard library! I've been writing it off and on for quite some time and still discover incredibly useful and elegant functions in there. It's incredibly rare to not find what I need when working with collections.

benbristow 5y ago

C# .NET implements quite a lot of these too via LINQ, albeit with different names (e.g. map is called Select). https://docs.microsoft.com/en-us/dotnet/api/system.linq.enumerable?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.linq.enum...

TheRealDunkirk 5y ago
Oy vey, LINQ. Meshuggeneh. Nothing like dropping COMPLETELY out of your language's idiom for a line or two to implement some Enumerable-like behavior.
- benbristow 5y ago
  I'd argue when I'm writing C# in a web-development setting (ASP APIs etc.) that a large majority of the code is LINQ. Especially if using something like Entity Framework. It's really just part of the language now.
  - TheRealDunkirk 5y ago
    A line of LINQ looks and works nothing like a line of C#, and the difference is even worse in VB. Whether it's "part of the language" or not, it's a fundamentally different way of writing logic than the base language you're writing around it. I agree it's completely coupled with EF, but I hate EF too. (After you've used ActiveRecord for over 10 years, any other ORM just feels like a ball and chain, but that's another topic.)
    - benbristow 5y ago
      I came from a Rails background and it was definitely painful to learn EF since it has a lot of nuances and things you wouldn't know without experience (e.g. How things mutate throughout the object lifecycle, migration funkiness, how tracking works and 'AsNoTracking()' etc.) Think I'd still prefer ActiveRecord really but after you get used to EF (Core) it's still a good tool.
    - 5y ago