Hacker News Reader

Hacker News

Comment by DFHippie | Hacker News Reader

Full thread

DFHippie

The discussion of Ruby could use a mention of Enumerable.

https://ruby-doc.org/core-3.0.2/Enumerable.html

View on HN

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.enum...

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.

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.

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.)

> A line of LINQ looks and works nothing like a line of C#

Maybe if you're using the query form, but if you're using the method form, I'd argue that they work together very nicely.

For me, at least, I've found embracing Lambda expressions to be very helpful in a number of cases, between Linq, or writing my own code for doing things like rendering tables (long story there).

Granted, I learned C# right after LINQ was released, but I'd still argue that LINQ is well worth having around.

Are you using the query syntax instead of the method syntax? Because the method syntax is completely in line with normal OO code (it's just a bunch of chained methods). I'll agree that the query syntax is weird, but I haven't seen it used much.

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.

It is interesting that this kind of context switch for some programmers is a breath of fresh air, and for others its a horrible hack.

I think the fact this is not an objectively good or bad thing has led to a lot of the tension we see in other aspects of programming.

I think a connected issue is tooling: if you presume a certain floor on tooling, more 'advanced' things like multiple composed domain languages become much more feasible since the tooling can remove the need for memorization and help guide construction without fear of errors. But if you presume all tooling beyond text editing should be regarded as non-essential at best and superfluous at worst, it greatly constrains the set of things in programming one can consider sane or not. I do wish we had more projects experimenting + getting traction with "high tooling, high abstractions, high domain mixing" so we could get more literacy around these methods, but I think the vast majority of programmers today have abandoned these kinds of ideas as good or worthy of further development. On pure interia alone, I long ago capitulated to the idea we will be stuck in text editors and having heated debates over typographical syntax for programming languages for the foreseeable future.

People working on things like LINQ and more advanced domain mixing like MPL or (where I once worked) Intentional Software run up against lots of resistance from people I think probably due to some fundamental differences in assumptions, but I'm not really sure what the deepest differences are.

Out of idiom? Extension methods, the way LINQ is implemented, has been introduced in C# 3

Are you talking about the `from x in y select x.z` syntax or the `y.Select(x => x.z)` syntax? Because the latter is the one I most commonly see, and it fits in fine with the rest of the language.

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

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 ...

puts Stuff.new.map(&:to_s).join("\n")

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.

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).

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.

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.

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.

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.

#collect is an alias for #reduce, not #map, making it like Python reduce().

> #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-col...

[1] https://ruby-doc.org/core-3.0.2/Enumerable.html#method-i-inj...

Then should the example in the above comment, `some_enum.collect(&:+)`, be using reduce instead of collect?

Yes. My bad. :)

I haven't been a professional Rubyist in some years but my habit here was to use inject.

You’re right. My apologies.

While this is cool, you can also just do `some_enum.sum` (also works with string concacts)

One thing that is cool about the .to_proc shorthand though is, for example, you have a method

def square_it(x); x * 2; end;

people tend to write an enumeration that uses it like

items.map {|i| square_it i }

but you can actually write it like this

items.map(&method(:square_it))

So not only can you write shorthands to methods on the object itself, you can write shorthands to other methods and "automagically" pass the item as its argument. Nifty stuff.

Reply on news.ycombinator.com