16 ms·

Writing your own LINQ provider

64 points by aashishkoirala 13y ago

gum_ina_package 13y ago
Awesome stuff. As a side note, anyone else see a rise in .NET/Microsoft related posts recently?
- skrowl 13y ago
  I'm actually GLAD to see this rise in .NET stuff. I feel like us enterprise developers are left out on [Y] sometimes. Not everyone rolls python / ruby / node / etc.
  - thirsteh 13y ago
    I will take .NET posts over Node.js ones any day of the week. I feel like I am taking crazy pills whenever somebody celebrates discovering "async performance" in Node.js.
    - skrowl 13y ago
      A Node.js post here is how I discovered the excellent http://nancyfx.org http://nancyfx.org framework, but I agree that the node.js performance benefits are overblown quite a bit.
    - gum_ina_package 13y ago
      Well in .NET, C# especially, asynchronous programming is a first class citizen.
      - thesz 13y ago
        Not as much as in Haskell and/or Erlang.
        bunderbunder 13y ago
        Perhaps, perhaps not. My impression has been that of late the top-tier .NET langauges have better support for asynchronous programming when considered from a pragmatic perspective, because a lot more care has been spent on designing the relevant APIs and language features to be accessible and easy to learn. Async/await really is a great abstraction on top of task parallelism; it's easy to understand without having to wade through a zillion blog posts explaining how it's just like burritos, Lego blocks, the OSI model, or homeobox genes, or underpants. Which means that it's something you could actually get away with using in enterprise software development, rather than something that'll earn you a reputation for developing software that your colleagues wouldn't be able to maintain.
        thesz 13y ago
        I don't know. I still struggle to use async/await for, for example, async reading from file. It is not that easy, actually. I have to disagree to you also on the ground that almost everything in Haskell is (and many important things in Erlang are) async without any annotations. Haskell is lazy and that alone makes many operations "asynchronous", so to say. It's run-time system is heavily threaded and employs work stealing to fit millions of green threads into several system threads. You can write your own scheduler [1] for your purposes, if you please. As fine grained as you want it to. [1] http://hackage.haskell.org/package/meta-par http://hackage.haskell.org/package/meta-par In fact, .Net is years behind of Haskell and Erlang. Just because it borrows features from Haskell (and other languages) libraries and bolts them into language. The difference here is that things in libraries are first-class, you can create them at run-time. That does not often apply to language constructs.
        thirsteh 13y ago
        I'm just being pedantic, but the asynchronous I/O of Haskell isn't really associated with laziness, although it does have lazy I/O (which often is a bad idea.) Go essentially does all the same things (all I/O is asynchronous under the hood using epoll, kqueue, etc.) without being lazy.
      - corresation 13y ago
        Few C# developers actually use asynchronous rudiments, and instead the overwhelming bulk of code is of the classic stop and wait variety (I've developed in .NET, among other platform, from its beginnings). thirsteh's cynicism is misplaced. node.js is effectively predicated on asynchronous implementations, and you have to work hard to do otherwise. The end result tends to be very efficient implementations that can serve large numbers with ease. .NET bolted on asynchronous sugar as it matured, and while that is very good, and you can make efficient implementations, most don't. So it's not really reasonable to dismiss the talk about one because it's possible in another. EDIT: thirsteh is continually editing their posts so assume their commentary is very different from what it originally was.
        thirsteh 13y ago
        I'll wager that you haven't written much Erlang, Go, Haskell, or any other language with transparently asynchronous I/O but blocking semantics. If you have, I don't understand how you can believe my cynicism is misplaced. Despite what you seem to imply in your comment, I/O does not block an entire thread in any of these languages, however the control flow in a single thread does block, i.e. err = fireTheRockets() does block until fireTheRockets completes, but performance-wise it is equivalent to fireTheRockets(function(err) { ... }). Only now you're saved the callback spaghetti. Node.js advocates are literally peddling callback spaghetti as an advantage because "it lets you write much faster applications with ease", yet Haskell's threads and blocking semantics blow any Node.js out of the water by an order of magnitude. (Check out Mighttp/Warp or Go's net/http vs. Node.js.) I come across as cynical because that is sad. It feels like we're travelling back in time, not forward. The only thing that makes node.js "good" when it comes to threading and async is that it doesn't require synchronization as there is no concurrency. (Same thing for Python with Twisted.) Neverminding that that opens up its own can of worms (I hope you don't do any actual computation in your program, as that's going to block everything): Pretending that it's anything more than that comes across as incredibly ignorant of contemporary language design.
        corresation 13y ago
        I'll wager... And you would lose. This conversation was about .NET, and then you (rather oddly) decided to pull in nodejs. It has nothing, at all, to do with Erlang, Go, Haskell, or any other language, and the tactic of using them as the "big brother" to discount another language is petty and disingenuous.
  - mattgreenrocks 13y ago
    It's a shame that .NET is considered 'just' enterprise. C# is a great language, and there are several libraries with fantastic design aesthetic; one that is much better than most of Ruby/JS.
    - UK-AL 13y ago
      Most people will admit they like c# and F#. However they won't like the microsoft tax, and the fact its tied to windows.
      - deleted 13y ago
        [deleted]
      - pjmlp 13y ago
        Yep many rather pay the company X tax, but only Microsoft's tax is evil.
        mattgreenrocks 13y ago
        Yeah, nobody seems to sweat coupling their entire codebase to Ruby on Rails. #nerdlogic
      - profquail 13y ago
        How are C# and F# tied to Windows? They run quite nicely on Mono, although I'll admit that even with the significant, recent improvements Mono has made it's still not as fast (generally) as the .NET CLR on Windows. Also -- F# is completely open-source, so there's no "Microsoft tax" to be paid. In fact, a large portion of the F# community runs exclusively on non-Windows platforms (e.g., OS X, Linux, FreeBSD, Android).
        UK-AL 13y ago
        The languages themselves are fine. The frameworks around them on mono are always half incomplete or not the latest version. Although I have noticed its getting better lately. For example its easier to get started with F# with MVC on the Xamarin IDE then it is in VS. Hope it takes off.
  - Pxtl 13y ago
    I think the big problem is that MS has a lot of catch-up to do in terms of growing a nice open-source community around the language. .NET suffers from too much "Cathedral" and not enough "Bazaar" so too many developers suffer Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. I mean, C# is a fantastic language, but a lot of the libs MS has bundled into it are absolutely horrible and people use them anyways because they're the blessed first-party product. And rather than fixing the problems, Microsoft simply creates a new replacement lib with a new approach. I mean, how many kicks at the can did they get with remoting? DB access? Serialization? Microsoft has gotten a lot better recently, taking an open-source-style development approach to Entity Framework and MVC, but they're very late to this particular party.
    - mattgreenrocks 13y ago
      This nails it. They should fund the best C# open source projects and promote them as micro replacements for existing monolithic libraries.
    - balls187 13y ago
      This isn't a very fair criticism. .NET has been around for a long time, long enough to have gone through the rise an decline[1] of many open source alternatives: DHTML, PHP, Python, RoR, NodeJs And the language and framework has been thoughtfully improved over that period of time. > Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. Developers have been writing great software with these tools for decades. And rapidly-released libs could just as easily be classified as "not-yet-ready-for-production." > I think the big problem is that MS In my estimation, the biggest problem is that using .NET "requires" the rest of MS along for the ride. Yes you can use mono, yes you can use apache, but everything just works if you use the WINS stack. I like .NET and I really like C# as a language, but I'd rather have my infrastructure be linux. [1] Not all of these have "declined", but popularity has shifted focus.
      - Pxtl 13y ago
        I've been using the MS stack since '05. I didn't say it wasn't ready for prime-time. Just that MS, like any other team, makes missteps - their libraries tend to be a bit overcomplicated and messy, but understandably so since they try to be all things to all people. Sometimes they hit on the wrong design. But where other libraries would have to compete in the open market-place of ideas, Microsoft's failures are still "blessed" by MS and so we still use them. But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. If there's a major flaw in the lib, it will not get fixed. Instead, a completely new library with its own flaws and a whole new learning curve will appear, and the old lib will remain and languish in its "functional but still fundamentally frustrating" state. Like I said, I'm ecstatic to see that MS has moved away from this methodology with Entity Framework - they've de-coupled it from the .NET core and are iterating on it faster than Once Every Major Language Release.
- sdegutis 13y ago
  Yep, I've noticed more of them. For me at least, it's because I'm beginning to throw out whatever political ideologies are stopping me from being open to using whatever technologies suit my problems best. In this case, it means I'm now open to writing GUI programs for Windows (and I'm even considering using Windows as my new development platform) if it proves to be technologically more innovative and fruitful than its competitors. Same with Windows phones. And since C# with .NET happens to be the language of the platform, I've been toying with that with an open mind. I don't know if other people have the same reason.
  - gum_ina_package 13y ago
    That's actually really interesting - what makes you excited about Win Phone? Is it just that the other platforms are getting stale/boring and WP is the "final frontier"?
    - sdegutis 13y ago
      From what I've seen, the UI looks more intuitive and easy to use, and all the iPhones and Androids I've tried are sluggish, so I'm holding out hope that Winphones won't be as sluggish. My contract's up in May though, so it'll be a while before I can really try it.
Guillaume86 13y ago
Nice post, if you plan a writing a full featured provider I recommend using the ReLINQ framework: http://relinq.codeplex.com/ http://relinq.codeplex.com/ I regret I didn't knew about it when I wrote my first LINQ provider.
- aashishkoirala 13y ago
  Thanks for the info - I just looked at the home page but have yet to try it out. Looks like it cuts down on a lot of the boilerplate associated with it. Nice.
- jdaley 13y ago
  Although it's quite a bit older than re-linq, I'll throw a recommendation in for IQToolkit: http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.aspx http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-link... I used it to build a LINQ provider for a legacy mainframe database system, abstracting away the incomprehensible table and column naming, weird date systems, EBCDIC, and other nastiness involved in querying that system using straight-up SQL. One thing I found is that implementing a custom LINQ provider gives you a better understanding of how Entity Framework runs your queries. You get to see how queries get split up into the parts executed in the CLR versus the parts that get translated, and how expressions get rearranged and rewritten.
  - aashishkoirala 13y ago
    I second the comment about getting a better understanding of how EF, etc. work after writing your own provider. Definitely.
thesz 13y ago
You can get away with providing your own classes and extension methods. I did that, my colleagues did that (floowing my attempt). We needed a LINQ access to a non-SQL (hypergraph) database, so basic LINQ wouldn't do it. You need to know how to parse function bodies and I strongly suggest algebraic types approach, e.g., using SpecificType v = genericTypedVar as SpecificType and checking if v != null. You have to write your own parametrized type supporting Where, Select, etc. And you're good to go. It took me three days to write first LINQ-like thing.
- aashishkoirala 13y ago
  That is true as well, especially if you need to support operations not part of out-of-the-box LINQ. The real meat there is in the Expressions API. The actual LINQ methods, if you look at them, don't do much except provide a way to delegate to the underlying IQueryProvider. That said, I think for stuff that is supported, better to stay within the "standard approach". But I get your point.
sidmkp96 13y ago
LINQ one of the most beautiful things in C# after extension methods!
- corresation 13y ago
  I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I do not mean to raise the ire of defensive .NET programmers by saying this: as with most things, used right it is a beautiful thing, and there is nothing fundamentally wrong with LINQ. But what it was used for in practice was almost always grotesquely inefficient. If someone had to make a loop to iterate objects to find a member on every function call, pretty soon they'll realize they should using a System.Collections.Generic.Dictionary for instance, or some other appropriate data structure (e.g. Need sorted data? Then use a sorted tree, for instance). When it's a simple LINQ query, though, it's one seemingly harmless little line, so it tends to get a pass. Pretty soon profiles were just hundreds (if not thousands) of different cases where LINQ was used as a cure-all, destroying performance under any load at all. LINQ is not magical. It is doing the same dirty work that you would be doing yourself if you needed to filter / sort / recast, but provides syntactical sugar to do so. The compiler and runtime will happily generate horrifically inefficient code if you request it, with no warning or complaints. The tldr; is that it is a fantastic set abstraction that is more often than not grossly abused.
  - aashishkoirala 13y ago
    I've seen that happen as well, but you can't blame LINQ for that. Shitty developers will make a mess out of any technology.
  - louthy 13y ago
    > I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I find it incredible when I see comments like this. What you should have done is instigated a mentoring programme for the programmers who aren't yet up to speed. LINQ is one of the best things to happen to the language and you just go and kill it.
aashishkoirala 13y ago
OP here. I wanted to comment on the discussion around ".NET vs. other things" coversation that has started brewing here. I'm not one to hate on any environment or ecosystem. I do make fun of PHP or Java at times, but it's all good-natured. Not to be too PC, but yes, every thing has its pros and cons. Personally, however, I think C# as a language strikes the right balance in terms of power, ease-of-use, learnability and code readability. Even if you have a problem with Microsoft, I think it is wrong to let your "MS-hate" translate into "C#-hate". It is a beautiful language and the open-source community around it is growing rapidly. The progress made by platform-independent endeavors (case in point Xamarin) is admirable. In the unlikely scenario that all of programming were to converge into one language, I would want it to be an open-source, platform-independent version of C# (with maybe just a tad more constructs borrowed from the functional programming world). P.S. I also think it is a mistake to lump C# and Java in the same bucket. Ten or more years ago, maybe. Today, they are VERY different.
- doorhammer 13y ago
  I do C# dev in my day to day and I really enjoy it, though my personal preference for a "one language" scenario would probably be F#, if it were to come from the MS camp. (I don't mean this as a comparison of languages; just casually throwing out a personal preference) Was wondering what, in your opinion, are the largest differences between Java and C#? It's been a long time since I've done any Java, and while I can definitely name a bunch, I thought it'd be interesting to get your take on the most impactful or meaningful differences.
  - Guillaume86 13y ago
    Well, LINQ is probably one of the most impactful differences.
  - aashishkoirala 13y ago
    Yes, I've heard a lot of praise around F# and its power. I've been meaning to get into it. Coming into it cold, though, I found the syntax a bit cryptic, but that's probably just me. I do plan to power through, though. In terms of differences with Java (and limiting this to just the language and the syntax), LINQ is a good example of it :) I guess you could classify a lot of the other differences as synctatic sugar, but those little things add up and make a real difference in terms of code brevity, readability and developer productivity. To name a few (and I know that Java, especially with v8 has started adding support for some of these): Properties (and auto-properties), Delegates, Events, Lambdas/Anonymous Functions/First Class Functions, Extension methods, "using" for IDisposable (although Java 7 has something similar in AutoClosable), the lack of forced checked exceptions, the newly added async/await keywords, object and collection initializers and anonymous types, etc.
rip747 13y ago
LINQ makes moving from CFML to .NET a lot easier. in CFML you're mostly working with queries and using LINQ makes you feel right at home.
aashishkoirala 13y ago
And just as we were talking about .NET in other environments and Mono and Xamarin, we hear the news about Microsoft in talks to acquire Xamarin. Interesting.

Awesome stuff. As a side note, anyone else see a rise in .NET/Microsoft related posts recently?

skrowl 13y ago
I'm actually GLAD to see this rise in .NET stuff. I feel like us enterprise developers are left out on [Y] sometimes. Not everyone rolls python / ruby / node / etc.
- thirsteh 13y ago
  I will take .NET posts over Node.js ones any day of the week. I feel like I am taking crazy pills whenever somebody celebrates discovering "async performance" in Node.js.
  - skrowl 13y ago
    A Node.js post here is how I discovered the excellent http://nancyfx.org http://nancyfx.org framework, but I agree that the node.js performance benefits are overblown quite a bit.
  - gum_ina_package 13y ago
    Well in .NET, C# especially, asynchronous programming is a first class citizen.
    - thesz 13y ago
      Not as much as in Haskell and/or Erlang.
      - bunderbunder 13y ago
        Perhaps, perhaps not. My impression has been that of late the top-tier .NET langauges have better support for asynchronous programming when considered from a pragmatic perspective, because a lot more care has been spent on designing the relevant APIs and language features to be accessible and easy to learn. Async/await really is a great abstraction on top of task parallelism; it's easy to understand without having to wade through a zillion blog posts explaining how it's just like burritos, Lego blocks, the OSI model, or homeobox genes, or underpants. Which means that it's something you could actually get away with using in enterprise software development, rather than something that'll earn you a reputation for developing software that your colleagues wouldn't be able to maintain.
        thesz 13y ago
        I don't know. I still struggle to use async/await for, for example, async reading from file. It is not that easy, actually. I have to disagree to you also on the ground that almost everything in Haskell is (and many important things in Erlang are) async without any annotations. Haskell is lazy and that alone makes many operations "asynchronous", so to say. It's run-time system is heavily threaded and employs work stealing to fit millions of green threads into several system threads. You can write your own scheduler [1] for your purposes, if you please. As fine grained as you want it to. [1] http://hackage.haskell.org/package/meta-par http://hackage.haskell.org/package/meta-par In fact, .Net is years behind of Haskell and Erlang. Just because it borrows features from Haskell (and other languages) libraries and bolts them into language. The difference here is that things in libraries are first-class, you can create them at run-time. That does not often apply to language constructs.
        thirsteh 13y ago
        I'm just being pedantic, but the asynchronous I/O of Haskell isn't really associated with laziness, although it does have lazy I/O (which often is a bad idea.) Go essentially does all the same things (all I/O is asynchronous under the hood using epoll, kqueue, etc.) without being lazy.
    - corresation 13y ago
      Few C# developers actually use asynchronous rudiments, and instead the overwhelming bulk of code is of the classic stop and wait variety (I've developed in .NET, among other platform, from its beginnings). thirsteh's cynicism is misplaced. node.js is effectively predicated on asynchronous implementations, and you have to work hard to do otherwise. The end result tends to be very efficient implementations that can serve large numbers with ease. .NET bolted on asynchronous sugar as it matured, and while that is very good, and you can make efficient implementations, most don't. So it's not really reasonable to dismiss the talk about one because it's possible in another. EDIT: thirsteh is continually editing their posts so assume their commentary is very different from what it originally was.
      - thirsteh 13y ago
        I'll wager that you haven't written much Erlang, Go, Haskell, or any other language with transparently asynchronous I/O but blocking semantics. If you have, I don't understand how you can believe my cynicism is misplaced. Despite what you seem to imply in your comment, I/O does not block an entire thread in any of these languages, however the control flow in a single thread does block, i.e. err = fireTheRockets() does block until fireTheRockets completes, but performance-wise it is equivalent to fireTheRockets(function(err) { ... }). Only now you're saved the callback spaghetti. Node.js advocates are literally peddling callback spaghetti as an advantage because "it lets you write much faster applications with ease", yet Haskell's threads and blocking semantics blow any Node.js out of the water by an order of magnitude. (Check out Mighttp/Warp or Go's net/http vs. Node.js.) I come across as cynical because that is sad. It feels like we're travelling back in time, not forward. The only thing that makes node.js "good" when it comes to threading and async is that it doesn't require synchronization as there is no concurrency. (Same thing for Python with Twisted.) Neverminding that that opens up its own can of worms (I hope you don't do any actual computation in your program, as that's going to block everything): Pretending that it's anything more than that comes across as incredibly ignorant of contemporary language design.
        corresation 13y ago
        I'll wager... And you would lose. This conversation was about .NET, and then you (rather oddly) decided to pull in nodejs. It has nothing, at all, to do with Erlang, Go, Haskell, or any other language, and the tactic of using them as the "big brother" to discount another language is petty and disingenuous.
- mattgreenrocks 13y ago
  It's a shame that .NET is considered 'just' enterprise. C# is a great language, and there are several libraries with fantastic design aesthetic; one that is much better than most of Ruby/JS.
  - UK-AL 13y ago
    Most people will admit they like c# and F#. However they won't like the microsoft tax, and the fact its tied to windows.
    - deleted 13y ago
      [deleted]
    - pjmlp 13y ago
      Yep many rather pay the company X tax, but only Microsoft's tax is evil.
      - mattgreenrocks 13y ago
        Yeah, nobody seems to sweat coupling their entire codebase to Ruby on Rails. #nerdlogic
    - profquail 13y ago
      How are C# and F# tied to Windows? They run quite nicely on Mono, although I'll admit that even with the significant, recent improvements Mono has made it's still not as fast (generally) as the .NET CLR on Windows. Also -- F# is completely open-source, so there's no "Microsoft tax" to be paid. In fact, a large portion of the F# community runs exclusively on non-Windows platforms (e.g., OS X, Linux, FreeBSD, Android).
      - UK-AL 13y ago
        The languages themselves are fine. The frameworks around them on mono are always half incomplete or not the latest version. Although I have noticed its getting better lately. For example its easier to get started with F# with MVC on the Xamarin IDE then it is in VS. Hope it takes off.
- Pxtl 13y ago
  I think the big problem is that MS has a lot of catch-up to do in terms of growing a nice open-source community around the language. .NET suffers from too much "Cathedral" and not enough "Bazaar" so too many developers suffer Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. I mean, C# is a fantastic language, but a lot of the libs MS has bundled into it are absolutely horrible and people use them anyways because they're the blessed first-party product. And rather than fixing the problems, Microsoft simply creates a new replacement lib with a new approach. I mean, how many kicks at the can did they get with remoting? DB access? Serialization? Microsoft has gotten a lot better recently, taking an open-source-style development approach to Entity Framework and MVC, but they're very late to this particular party.
  - mattgreenrocks 13y ago
    This nails it. They should fund the best C# open source projects and promote them as micro replacements for existing monolithic libraries.
  - balls187 13y ago
    This isn't a very fair criticism. .NET has been around for a long time, long enough to have gone through the rise an decline[1] of many open source alternatives: DHTML, PHP, Python, RoR, NodeJs And the language and framework has been thoughtfully improved over that period of time. > Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. Developers have been writing great software with these tools for decades. And rapidly-released libs could just as easily be classified as "not-yet-ready-for-production." > I think the big problem is that MS In my estimation, the biggest problem is that using .NET "requires" the rest of MS along for the ride. Yes you can use mono, yes you can use apache, but everything just works if you use the WINS stack. I like .NET and I really like C# as a language, but I'd rather have my infrastructure be linux. [1] Not all of these have "declined", but popularity has shifted focus.
    - Pxtl 13y ago
      I've been using the MS stack since '05. I didn't say it wasn't ready for prime-time. Just that MS, like any other team, makes missteps - their libraries tend to be a bit overcomplicated and messy, but understandably so since they try to be all things to all people. Sometimes they hit on the wrong design. But where other libraries would have to compete in the open market-place of ideas, Microsoft's failures are still "blessed" by MS and so we still use them. But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. If there's a major flaw in the lib, it will not get fixed. Instead, a completely new library with its own flaws and a whole new learning curve will appear, and the old lib will remain and languish in its "functional but still fundamentally frustrating" state. Like I said, I'm ecstatic to see that MS has moved away from this methodology with Entity Framework - they've de-coupled it from the .NET core and are iterating on it faster than Once Every Major Language Release.
sdegutis 13y ago
Yep, I've noticed more of them. For me at least, it's because I'm beginning to throw out whatever political ideologies are stopping me from being open to using whatever technologies suit my problems best. In this case, it means I'm now open to writing GUI programs for Windows (and I'm even considering using Windows as my new development platform) if it proves to be technologically more innovative and fruitful than its competitors. Same with Windows phones. And since C# with .NET happens to be the language of the platform, I've been toying with that with an open mind. I don't know if other people have the same reason.
- gum_ina_package 13y ago
  That's actually really interesting - what makes you excited about Win Phone? Is it just that the other platforms are getting stale/boring and WP is the "final frontier"?
  - sdegutis 13y ago
    From what I've seen, the UI looks more intuitive and easy to use, and all the iPhones and Androids I've tried are sluggish, so I'm holding out hope that Winphones won't be as sluggish. My contract's up in May though, so it'll be a while before I can really try it.

Nice post, if you plan a writing a full featured provider I recommend using the ReLINQ framework: http://relinq.codeplex.com/ http://relinq.codeplex.com/ I regret I didn't knew about it when I wrote my first LINQ provider.

aashishkoirala 13y ago
Thanks for the info - I just looked at the home page but have yet to try it out. Looks like it cuts down on a lot of the boilerplate associated with it. Nice.
jdaley 13y ago
Although it's quite a bit older than re-linq, I'll throw a recommendation in for IQToolkit: http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.aspx http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-link... I used it to build a LINQ provider for a legacy mainframe database system, abstracting away the incomprehensible table and column naming, weird date systems, EBCDIC, and other nastiness involved in querying that system using straight-up SQL. One thing I found is that implementing a custom LINQ provider gives you a better understanding of how Entity Framework runs your queries. You get to see how queries get split up into the parts executed in the CLR versus the parts that get translated, and how expressions get rearranged and rewritten.
- aashishkoirala 13y ago
  I second the comment about getting a better understanding of how EF, etc. work after writing your own provider. Definitely.

thesz 13y ago

You can get away with providing your own classes and extension methods. I did that, my colleagues did that (floowing my attempt). We needed a LINQ access to a non-SQL (hypergraph) database, so basic LINQ wouldn't do it. You need to know how to parse function bodies and I strongly suggest algebraic types approach, e.g., using SpecificType v = genericTypedVar as SpecificType and checking if v != null. You have to write your own parametrized type supporting Where, Select, etc. And you're good to go. It took me three days to write first LINQ-like thing.

aashishkoirala 13y ago
That is true as well, especially if you need to support operations not part of out-of-the-box LINQ. The real meat there is in the Expressions API. The actual LINQ methods, if you look at them, don't do much except provide a way to delegate to the underlying IQueryProvider. That said, I think for stuff that is supported, better to stay within the "standard approach". But I get your point.

sidmkp96 13y ago

LINQ one of the most beautiful things in C# after extension methods!

corresation 13y ago
I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I do not mean to raise the ire of defensive .NET programmers by saying this: as with most things, used right it is a beautiful thing, and there is nothing fundamentally wrong with LINQ. But what it was used for in practice was almost always grotesquely inefficient. If someone had to make a loop to iterate objects to find a member on every function call, pretty soon they'll realize they should using a System.Collections.Generic.Dictionary for instance, or some other appropriate data structure (e.g. Need sorted data? Then use a sorted tree, for instance). When it's a simple LINQ query, though, it's one seemingly harmless little line, so it tends to get a pass. Pretty soon profiles were just hundreds (if not thousands) of different cases where LINQ was used as a cure-all, destroying performance under any load at all. LINQ is not magical. It is doing the same dirty work that you would be doing yourself if you needed to filter / sort / recast, but provides syntactical sugar to do so. The compiler and runtime will happily generate horrifically inefficient code if you request it, with no warning or complaints. The tldr; is that it is a fantastic set abstraction that is more often than not grossly abused.
- aashishkoirala 13y ago
  I've seen that happen as well, but you can't blame LINQ for that. Shitty developers will make a mess out of any technology.
- louthy 13y ago
  > I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I find it incredible when I see comments like this. What you should have done is instigated a mentoring programme for the programmers who aren't yet up to speed. LINQ is one of the best things to happen to the language and you just go and kill it.

aashishkoirala 13y ago

OP here. I wanted to comment on the discussion around ".NET vs. other things" coversation that has started brewing here. I'm not one to hate on any environment or ecosystem. I do make fun of PHP or Java at times, but it's all good-natured. Not to be too PC, but yes, every thing has its pros and cons. Personally, however, I think C# as a language strikes the right balance in terms of power, ease-of-use, learnability and code readability. Even if you have a problem with Microsoft, I think it is wrong to let your "MS-hate" translate into "C#-hate". It is a beautiful language and the open-source community around it is growing rapidly. The progress made by platform-independent endeavors (case in point Xamarin) is admirable. In the unlikely scenario that all of programming were to converge into one language, I would want it to be an open-source, platform-independent version of C# (with maybe just a tad more constructs borrowed from the functional programming world). P.S. I also think it is a mistake to lump C# and Java in the same bucket. Ten or more years ago, maybe. Today, they are VERY different.

doorhammer 13y ago
I do C# dev in my day to day and I really enjoy it, though my personal preference for a "one language" scenario would probably be F#, if it were to come from the MS camp. (I don't mean this as a comparison of languages; just casually throwing out a personal preference) Was wondering what, in your opinion, are the largest differences between Java and C#? It's been a long time since I've done any Java, and while I can definitely name a bunch, I thought it'd be interesting to get your take on the most impactful or meaningful differences.
- Guillaume86 13y ago
  Well, LINQ is probably one of the most impactful differences.
- aashishkoirala 13y ago
  Yes, I've heard a lot of praise around F# and its power. I've been meaning to get into it. Coming into it cold, though, I found the syntax a bit cryptic, but that's probably just me. I do plan to power through, though. In terms of differences with Java (and limiting this to just the language and the syntax), LINQ is a good example of it :) I guess you could classify a lot of the other differences as synctatic sugar, but those little things add up and make a real difference in terms of code brevity, readability and developer productivity. To name a few (and I know that Java, especially with v8 has started adding support for some of these): Properties (and auto-properties), Delegates, Events, Lambdas/Anonymous Functions/First Class Functions, Extension methods, "using" for IDisposable (although Java 7 has something similar in AutoClosable), the lack of forced checked exceptions, the newly added async/await keywords, object and collection initializers and anonymous types, etc.

rip747 13y ago

LINQ makes moving from CFML to .NET a lot easier. in CFML you're mostly working with queries and using LINQ makes you feel right at home.

aashishkoirala 13y ago

And just as we were talking about .NET in other environments and Mono and Xamarin, we hear the news about Microsoft in talks to acquire Xamarin. Interesting.