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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
[+] [-] aashishkoirala|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
I regret I didn't knew about it when I wrote my first LINQ provider.
[+] [-] jdaley|12 years ago|reply
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|12 years ago|reply
[+] [-] gum_ina_package|12 years ago|reply
[+] [-] skrowl|12 years ago|reply
[+] [-] sdegutis|12 years ago|reply
[+] [-] sidmkp96|12 years ago|reply
[+] [-] platz|12 years ago|reply
[+] [-] corresation|12 years ago|reply
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.
[+] [-] thesz|12 years ago|reply
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|12 years ago|reply
That said, I think for stuff that is supported, better to stay within the "standard approach".
But I get your point.
[+] [-] aashishkoirala|12 years ago|reply
[+] [-] rip747|12 years ago|reply