Most active commenters
  • SideburnsOfDoom(3)

←back to thread

201 points olvy0 | 11 comments | | HN request time: 1.064s | source | bottom
Show context
high_na_euv ◴[] No.41878416[source]
LINQ is so fucking useful and well designed feature of .NET ecosystem that it is unreal when you gotta use lang which doesnt have such a thing.

C# design team is/was unparalleled

replies(7): >>41878459 #>>41878543 #>>41878588 #>>41878686 #>>41879163 #>>41879194 #>>41879315 #
1. mhh__ ◴[] No.41878588[source]
Maybe you've been unlucky but LINQ didn't really seem all that interesting to me using it.

It's pretty well put together but it was very hard to work out the patterns of what it was doing underneath e.g. I could not tell you now how to implement a custom IQueryable (I know where to look but couldn't tell you the rhythms of it) for some database and I am the type of person who usually does go and find that kind of thing out before using something for a "serious" project.

Maybe it's just a microcosm for C# as a whole - very productive language, good design team, quite hobbled by it's weird/philistine upbringings: Bjarne said within C++ there is a simple language trying to escape, in C# you basically have a simple language buried in nouns.

replies(4): >>41878661 #>>41878884 #>>41879002 #>>41879297 #
2. pjc50 ◴[] No.41878661[source]
> It's pretty well put together but it was very hard to work out the patterns of what it was doing underneath e.g. I could not tell you now how to implement a custom IQueryable

There's a lot hidden in there, but basically they expect you to use EF. Writing an IQueryable is a similar amount of work to writing a SQL query planner. You get passed a tree of Expression objects.

https://learn.microsoft.com/en-us/archive/blogs/mattwar/linq...

replies(2): >>41879320 #>>41880802 #
3. bazoom42 ◴[] No.41878884[source]
It is not rocket science to implement IQueryable but it is not trivial either since the API is optimized towards ease of use rather then ease of implementation. The Select and Where methods support arbitrary C# expression trees, so the implementation have to traverse the tree and throw errors if some expression cannot be translated to the underlying engine.
4. justin66 ◴[] No.41879002[source]
> Maybe you've been unlucky but LINQ didn't really seem all that interesting to me using it.

Getting good use out of a tool you do not find interesting would mean a person was… unlucky?

replies(1): >>41882206 #
5. SideburnsOfDoom ◴[] No.41879297[source]
> I could not tell you now how to implement a custom IQueryable

So what? I see LINQ used all the time, and it is almost entirely (extension) methods IEnumerable<T>

Could I implement IEnumerable<T>? I think I did once, as an exercise. It's not that complex. Not that interesting to be able to do it either.

LINQ is useful without EF. LINQ is not EF and EF is not LINQ.

6. SideburnsOfDoom ◴[] No.41879320[source]
> basically they expect you to use EF. Writing an IQueryable...

I don't agree. I don't feel any expectation to use EF. It would not be relevant anyway to our code.

LINQ is not EF and EF is not LINQ. EF uses LINQ but not vice versa. LINQ is useful without EF.

The LINQ extension methods that we use constantly are on IEnumerable<T> so EF and IQueryable is of no importance to us, but LINQ is used everywhere.

replies(1): >>41880438 #
7. pjc50 ◴[] No.41880438{3}[source]
> IQueryable is of no importance to us

I was discussing IQueryable with someone else to whom it was important. In reply to

> I could not tell you now how to implement a custom IQueryable (I know where to look but couldn't tell you the rhythms of it) for some database

And "for some database" the default answer is "use EF" as the intermediary between LINQ queries and the database itself, rather than delving into IQueryable.

LINQ-to-objects is very important and useful but I was talking about something else.

replies(1): >>41886496 #
8. christophilus ◴[] No.41880802[source]
Back when I was primarily a C# dev, I used OSS lightweight ORMs which had LINQ interfaces. I also frequently used LINQ on in-memory structures. It's fantastic, and I never felt any need to use EF.

That said, C# / .NET shops did have a tendency to mindlessly buy into all sorts of terrible Microsoft enterprisey stuff. That drove me crazy and ultimately is what made me head out for greener pastures.

replies(1): >>41884884 #
9. mhh__ ◴[] No.41882206[source]
Unlucky as in forced to write COBOL prior to C# or whatever
10. grugagag ◴[] No.41884884{3}[source]
What are those greener pastures for you and do you still use C#?
11. SideburnsOfDoom ◴[] No.41886496{4}[source]
My apologies, that reply of mine was a bit argumentative, without regard to which post I was arguing against.

Yes, I understand that implementing IQueryable is a beast, but let's not pretend that writing a database connectivity layer was a trivial, everyday activity before IQueryable. It's a specialised, tricky task. IQueryable may not make it easier, but it never was "easy" per se. Nor common, or usually necessary. Or something to do as an exercise "before using something for a serious project" as the grandparent post suggests.

YMMV as to how important IQueryable is to your code.

On the other hand, if you can write extension methods over "this IEnumerable<T> source" you can extend LINQ. IQueryable being complex is no barrier to that, in any way.