4 ms·

Regarding LINQ: I really like certain parts of it, dislike others (mainly inline Select-statements and the EntityFramework built on top of it), but I'd be hard-

Regarding LINQ: I really like certain parts of it, dislike others (mainly inline Select-statements and the EntityFramework built on top of it), but I'd be hard-pressed to call it the greatest invention of any time. PEP 255 laid the ground work for similar language features in 2001, and I doubt that the python guys "invented" all of that out of thin air (cf. Reference #4 in the PEP). What you can argue is that LINQ made this stuff available to more developers (with useful syntax and in a statically typed language, which also must have taken a lot of work), but filter/map/reduce have been around for quite a while. That obviously doesn't make it less useful or the underlying tech less impressive though.

coldtea 9y ago
>PEP 255 laid the ground work for similar language features in 2001, and I doubt that the python guys "invented" all of that out of thin air (cf. Reference #4 in the PEP). LINQ is not about generators...
- btschaegg 9y ago
  The IEnumerable parts are mainly enabled by coroutines, which for this case more or less equate to generators. The other parts are pretty much what I've already seen so much problems with that I wouldn't touch them with a 10 foot pole (see the "black magic" comment by others, that sums it up nicely for me). But those are also more or less just about building ASTs and transforming them, something Lisp has done for decades.
tehlike 9y ago
The magic behind LINQ is that it's a query layer on top of a backing data store. When it first came out, you'd see data providers written against twitter, file system and everything like that. Then entity framework & nhibernate linq provider came out. It was great, hid a lot of details from user, brought static type checking to otherwise very hard to "verify" sql. You'd now think in terms of objects, and not tables. Linq compiler compiled the whole query into a AST, which you could then convert to a backing query your data store could understand. To date, I still think Linq was great. I was indifferent to the "sqlized linq", but i liked the lambda quite a lot. It was a nice abstraction and a pretty good language to write queries on. Disclaimer: I worked on NHibernate Linq integration ~10 years ago.
- brusch64 9y ago
  What is your opinion on the state of NHibernate ? I've started using it in 2009. I am still using it in my projects, but I am still not sure if NHibernate is functional complete or if the project is nearly dead. It works fine for me (if it is not worth the effort I am using Dapper.net), but it doesn't seem that there is much active development going on.
  - tehlike 9y ago
    To my surprise, it seems fairly active: https://github.com/nhibernate/nhibernate-core https://github.com/nhibernate/nhibernate-core I stopped working on nhibernate around 2010-2011, when i started masters. I did only keep in touch with one friend - i am not very sociable person. So I guess short answer is, i am not sure to be honest. Back in 2008ish, I was thinking it was going to die because Entity framework provided a great support for linq, and it had a great hype. A bunch of enterprises moved away from NHibernate (we also had a lot of legacy from XML configuration - a bunch of internal data structures were referencing xml), so it was clunky. Fabio, Oren (Ayende) did a bunch of improvements, I worked a bunch of shortening initialization times and so on. I think Ayende did a very good job with Linq initially, but there were plenty of edge cases that i remember having to fix :) It was my first opensource project as a core member (second and last was castle project) - so it has a very special place for me :)
    - brusch64 9y ago
      Okay - it really seems to be quite active right now. Thank you for your insight. I've used the Linq queries in one of my projects, but I like the QueryOver statements more (a little bit too much black magic in the Linq queries). But I believe that it was a great effort - so let me thank you for that !
      - mattmanser 9y ago
        In my expereince you shouldn't even touch the black magic stuff unless you're a small org or it's a throwaway app. Linq with the EF is great for simple queries and updates, anything else and you're in for serious performance problems as soon as the app scales. Better to drop to normal SQL for complicated data loading. Even MS can't write decent LINQ queries, their ASP.Net identity provider is now the most 'expensive' bit of our app now because they used expensive LINQ queries instead of using raw SQL queries. Admittedly our use-case is abnormal as the specific problem we have is that because of the way users are added their password gets reset almost immediately, as they're invited by an organiser. It also means new users are constantly being added. When the password reset is saved it completely unnecessarily "verifies" the update by making sure the username and email are unique, which means two UPPER()s and CONTAINS()s on string fields. Unlike the old provider there's no usernamelowered field already in the db to avoid this. We can fix it by over-riding these queries, but it's annoying that the ASP.Net team took a core framework piece that was very performant with fast performing SQL and made it substandard. At least I can look at the code now ;).
golergka 9y ago
I always saw Linq as the iPhone of functional programming: it didn't really invent anything, but put existing things into such an appealing package for mass-market that it really finally made all those things popular and usable by people (developers) at large.
- btschaegg 9y ago
  Yes, I think you sum it up pretty nicely.
- eldavido 9y ago
  This is a broader theme in how technology develops. When I look at technologies like bitcoin, it's just proof of work/puzzles (a well-understood defense to sybil attacks) + basic crypto primitives like signatures + some of the p2p stuff from bittorrent, etc. There's real genius in combining the pieces, though. I also spent a few years in serious CS academia so not clear how widely these things (especially puzzles) were known beyond universities.
Guillaume86 9y ago
It seems you're just thinking of the IEnumerable API and not LINQ at large, which includes the Expression and IQueryable API and enable things like LINQ-to-SQL.
- btschaegg 9y ago
  ...which I'm also not a big fan of after having seen their implications in older products (i.e. ones that had to be maintained for a while). In most cases, they made the problem worse. Plus, while they are enabled by other techniques, those weren't invented in LINQ, either.
  - deleted 9y ago
    [deleted]
wenc 9y ago
Filter/map/reduce are ubiquitous ideas from the functional world, which in turn are ideas drawn from mathematics. Math has pre-existed many of our programming constructs, so in that sense, nothing was really invented as such. To me, what LINQ offers is a very nice orthogonal DSL that allows programmers to express these thoughts. The underlying constructs are universal, but one could argue that LINQ itself was invented. LINQ was apparently guided by category thinking [0], which makes it fairly elegant, but in terms of expressiveness it is probably similar to SQL. It's all set theory underneath anyway. Unlike SQL however, LINQ does force the SELECT statement to the very end of the query expression, which makes IDE auto-complete work better due to avaiable context. :) I first had the realization that most data manipulation operations on list-like or table-like objects were actually just glorified set operations (and there was a certain universality to them regardless of query language syntax) when I read this quote [1]: "The turning point was a conversation with Erik Meijer. He told me how categorical thinking guided him in designing LINQ, and explained how category theory brings out a simple relationship between various kinds of databases. The diagram below comes from a paper he wrote on this. It turns out that so-called No-SQL databases are in a categorical sense co-SQL databases." [0] https://queue.acm.org/detail.cfm?id=2024658 https://queue.acm.org/detail.cfm?id=2024658 [1] https://www.johndcook.com/blog/applied-category-theory/ https://www.johndcook.com/blog/applied-category-theory/

coldtea 9y ago

>PEP 255 laid the ground work for similar language features in 2001, and I doubt that the python guys "invented" all of that out of thin air (cf. Reference #4 in the PEP). LINQ is not about generators...

btschaegg 9y ago
The IEnumerable parts are mainly enabled by coroutines, which for this case more or less equate to generators. The other parts are pretty much what I've already seen so much problems with that I wouldn't touch them with a 10 foot pole (see the "black magic" comment by others, that sums it up nicely for me). But those are also more or less just about building ASTs and transforming them, something Lisp has done for decades.

tehlike 9y ago

The magic behind LINQ is that it's a query layer on top of a backing data store. When it first came out, you'd see data providers written against twitter, file system and everything like that. Then entity framework & nhibernate linq provider came out. It was great, hid a lot of details from user, brought static type checking to otherwise very hard to "verify" sql. You'd now think in terms of objects, and not tables. Linq compiler compiled the whole query into a AST, which you could then convert to a backing query your data store could understand. To date, I still think Linq was great. I was indifferent to the "sqlized linq", but i liked the lambda quite a lot. It was a nice abstraction and a pretty good language to write queries on. Disclaimer: I worked on NHibernate Linq integration ~10 years ago.

brusch64 9y ago
What is your opinion on the state of NHibernate ? I've started using it in 2009. I am still using it in my projects, but I am still not sure if NHibernate is functional complete or if the project is nearly dead. It works fine for me (if it is not worth the effort I am using Dapper.net), but it doesn't seem that there is much active development going on.
- tehlike 9y ago
  To my surprise, it seems fairly active: https://github.com/nhibernate/nhibernate-core https://github.com/nhibernate/nhibernate-core I stopped working on nhibernate around 2010-2011, when i started masters. I did only keep in touch with one friend - i am not very sociable person. So I guess short answer is, i am not sure to be honest. Back in 2008ish, I was thinking it was going to die because Entity framework provided a great support for linq, and it had a great hype. A bunch of enterprises moved away from NHibernate (we also had a lot of legacy from XML configuration - a bunch of internal data structures were referencing xml), so it was clunky. Fabio, Oren (Ayende) did a bunch of improvements, I worked a bunch of shortening initialization times and so on. I think Ayende did a very good job with Linq initially, but there were plenty of edge cases that i remember having to fix :) It was my first opensource project as a core member (second and last was castle project) - so it has a very special place for me :)
  - brusch64 9y ago
    Okay - it really seems to be quite active right now. Thank you for your insight. I've used the Linq queries in one of my projects, but I like the QueryOver statements more (a little bit too much black magic in the Linq queries). But I believe that it was a great effort - so let me thank you for that !
    - mattmanser 9y ago
      In my expereince you shouldn't even touch the black magic stuff unless you're a small org or it's a throwaway app. Linq with the EF is great for simple queries and updates, anything else and you're in for serious performance problems as soon as the app scales. Better to drop to normal SQL for complicated data loading. Even MS can't write decent LINQ queries, their ASP.Net identity provider is now the most 'expensive' bit of our app now because they used expensive LINQ queries instead of using raw SQL queries. Admittedly our use-case is abnormal as the specific problem we have is that because of the way users are added their password gets reset almost immediately, as they're invited by an organiser. It also means new users are constantly being added. When the password reset is saved it completely unnecessarily "verifies" the update by making sure the username and email are unique, which means two UPPER()s and CONTAINS()s on string fields. Unlike the old provider there's no usernamelowered field already in the db to avoid this. We can fix it by over-riding these queries, but it's annoying that the ASP.Net team took a core framework piece that was very performant with fast performing SQL and made it substandard. At least I can look at the code now ;).

golergka 9y ago

I always saw Linq as the iPhone of functional programming: it didn't really invent anything, but put existing things into such an appealing package for mass-market that it really finally made all those things popular and usable by people (developers) at large.

btschaegg 9y ago
Yes, I think you sum it up pretty nicely.
eldavido 9y ago
This is a broader theme in how technology develops. When I look at technologies like bitcoin, it's just proof of work/puzzles (a well-understood defense to sybil attacks) + basic crypto primitives like signatures + some of the p2p stuff from bittorrent, etc. There's real genius in combining the pieces, though. I also spent a few years in serious CS academia so not clear how widely these things (especially puzzles) were known beyond universities.

Guillaume86 9y ago

It seems you're just thinking of the IEnumerable API and not LINQ at large, which includes the Expression and IQueryable API and enable things like LINQ-to-SQL.

btschaegg 9y ago
...which I'm also not a big fan of after having seen their implications in older products (i.e. ones that had to be maintained for a while). In most cases, they made the problem worse. Plus, while they are enabled by other techniques, those weren't invented in LINQ, either.
- deleted 9y ago
  [deleted]

wenc 9y ago

Filter/map/reduce are ubiquitous ideas from the functional world, which in turn are ideas drawn from mathematics. Math has pre-existed many of our programming constructs, so in that sense, nothing was really invented as such. To me, what LINQ offers is a very nice orthogonal DSL that allows programmers to express these thoughts. The underlying constructs are universal, but one could argue that LINQ itself was invented. LINQ was apparently guided by category thinking [0], which makes it fairly elegant, but in terms of expressiveness it is probably similar to SQL. It's all set theory underneath anyway. Unlike SQL however, LINQ does force the SELECT statement to the very end of the query expression, which makes IDE auto-complete work better due to avaiable context. :) I first had the realization that most data manipulation operations on list-like or table-like objects were actually just glorified set operations (and there was a certain universality to them regardless of query language syntax) when I read this quote [1]: "The turning point was a conversation with Erik Meijer. He told me how categorical thinking guided him in designing LINQ, and explained how category theory brings out a simple relationship between various kinds of databases. The diagram below comes from a paper he wrote on this. It turns out that so-called No-SQL databases are in a categorical sense co-SQL databases." [0] https://queue.acm.org/detail.cfm?id=2024658 https://queue.acm.org/detail.cfm?id=2024658 [1] https://www.johndcook.com/blog/applied-category-theory/ https://www.johndcook.com/blog/applied-category-theory/