All the more reason to admire and appreciate MS Research and the development of C# generics. Really amazing accomplishment.
And Linq is one of the single greatest inventions in modern day programming.
I was bored of Java at university, and as the project I was basing my dissertation on was a web-based search engine I decided to use C# and ASP.NET. The professor helping me was fine with it, since he didn't know PHP or Ruby, and he felt he could read C#.
I came across some stumbling blocks with some logic, so I remember posting on a forum somewhere asking for help with setting up a data structure. Someone sent me some LINQ, and I thanked them for the pseudocode. When they pointed out that it was real functioning code, I plopped it into Visual Studio and the whole thing worked. From that moment, I fell in love with the language - ASP.NET WebForms less so, but shortly after this MVC became a thing in the .NET world and I jumped on the bandwagon.
A decade later, and while I've moved onto other languages I still fight C#'s corner, and LINQ/the lambda syntax is one of the first points I raise when people bitch about Micro$oft. The only negatives about working as a .NET developer is being locking into an ecosystem, so if Microsoft and the .NET Foundation can get .NET Core to be feature compatible with .NET Standard then they've got a winner on their hands.
They used to do presentations together with Sun, had the crazy Network Computer idea together with those Java Stations at Sun, ported their installers to Java, were the first RDBMS to allow stored procedures to be written in Java, had their own JVM, IDE and JEE server long before Sun started to get into troubles.
Have kept Java team together, saved Sun labs, turned the Maxime research work into Graal, are making the effort of supporting AOT compilation (tabu at Sun),....
I am a polyglot developer, and while Oracle could be doing a better job, they surely are doing much better than Sun was doing on its later days.
Who knows, if Google hadn't ripped off Sun and they were getting some Android revenue, maybe Sun would still be around.
Or maybe if Sun showed some promise with J2ME and tried to challenge iOS it would have been main iOS competitor instead of Android. But J2ME did not deliver much and the idea to grab some bullshit patents revenue, which Oracle tried, failed.
In copyright case Oracle may still get some money but after belatedly joining CNCF Oracle would not like to be on warpath with Google.
Android fragmentation, OEM customizations, lack of enforced updates and cheapo unresponsive 100 € devices are no better than the devices that gave bad name to J2ME.
https://github.com/mythz/swift-linq-examples
https://github.com/mythz/kotlin-linq-examples
https://github.com/mythz/clojure-linq-examples
https://github.com/mythz/java-linq-examples
https://github.com/mythz/dart-linq-examples
https://github.com/omnibs/elixir-linq-examples
http://templates.servicestack.net/linq/
What? It literally already is, all the time. If anything it's full .NET that lags behind standard often.
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.
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.
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.
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 :)
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 !
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 ;).
I think LINQ gets a lot of flak it doesn't necessarily deserve in complex queries due to people stopping at the black box and assuming black magic. It's a very functional programming paradigm embedded in an otherwise procedural world, and so the skills to debug complex LINQ should be unsurprisingly just a bit different than debugging most else in C#. I don't blame people for stopping at the black box. I just think more people should know that you can do more than stop at the black box.
(Also, it amuses me that your example from ASP.NET identity's changes have nothing to with that it should be using raw SQL queries versus LINQ, and everything to do with denormalization versus the query execution engine. It shouldn't be a huge surprise that Microsoft might trust SQL Server to be able to UPPER() and CONTAINS() fast enough, and the queries rare enough that it isn't necessary to denormalize that information.)
I started a project about 4yrs ago, it was EF vs NH. Went with NH because EF was still pretty immature.
The momentum is pretty clearly toward EF IMO. NH is missing a lot, including proper migration tooling and deep async support. But I don't think that's the real issue. The more foundational problem in my view, is that NH deeply assumes blocking/synchronous database access. I have no idea how NH lazy loading will ever work with async. I imagine you'll have a bunch of FK refs all marked Task<T> that will have to be awaited? In any case, my bet is that EF will get there a lot more quickly than NH.
I would have prefered using DataReader, most often.
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.
Plus, while they are enabled by other techniques, those weren't invented in LINQ, either.
LINQ is not about generators...
But those are also more or less just about building ASTs and transforming them, something Lisp has done for decades.
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."
Don't forget it took several people a few years to do all that! But yeah, I agree, it was an impressive achievement!