6 ms·

> I really don't see how C# is decent anymore How come it was decent once but not anymore? As others said, you are probably exaggerating by saying new version

by jve 8y ago

> I really don't see how C# is decent anymore How come it was decent once but not anymore? As others said, you are probably exaggerating by saying new version comes with 500 page tome. However it is a joy for me to program in C#. Super-consistent language. And my favorite feature "LINQ" really gets rid of loops and loops and maybe more nested loops. Interfaces, generics - all great features, decently implemented under the hood.

eropple 8y ago
Calling LINQ a "feature" still feels very off to me. It's a set of library functions with some very strange and, at least in my neck of the woods strongly discouraged, SQL-ish syntax that you can use if you like making it harder to understand what your code is actually doing. The library functions are...fine, to be clear, aside from the inconsistent-for-the-sake-of-inconsistent naming (and I know they want to ape SQL, but 'Select' is a map function, sorry). But...they're library functions. You should expect that stuff to exist in a programming language worth a fart. C#'s feature changes over the last few years have been marginal. They nibble at the edges while stuff like record classes--an actually and materially valuable thing that significantly improves the writing of immutable and functional code--have been punted for multiple versions now. C# is Java now, in a way it wasn't when it was younger. It's afraid of change and in being afraid of change has slowed to a crawl. Such is probably the way of most programming languages and ecosystems. But it is a little sad for me to see.
- thrower123 8y ago
  The weird special-case LINQ syntax appears to have receded and I don't recall seeing it in the wild for some time. Hopefully we can just all agree that was a bad idea and it can get officially deprecated and go away in future versions.
  - wvenable 8y ago
    Yeah, I mostly use the methods to do LINQ and rarely use the linq syntax -- but -- it's actually quite powerful and if you have to do a reasonably complex query it's much easier to compose and read in that syntax than the alternative mess of method calls and lambdas.
  - jve 8y ago
    Umm, the special-case LINQ syntax actually it is nothing special on itself, it just calls those methods anyway. You can actually extend LINQ by providing your own Extension methods for IEnumerable or IQueryable
    - thrower123 8y ago
      Right. Which is why it's jarring seeing these blocks of non-idiomatic almost-SQL DSL embedded in otherwise consistent C#. Particularly when you have to materialize a query by calling ToList() or similar - you end up with an extra unsightly mix of query and method syntax with the query wrapped in parentheses. Or else cluttered up with defining intermediate variables that need to be named. Much better in my opinion to just stick with the fluent method chaining style of using LINQ methods.
  - recursive 8y ago
    You'll never get me to agree. I still use it when I need a `let`.
- manigandham 8y ago
  LINQ is not just library functions. It stands for "language integrated query" and is a full data modeling and querying system designed around lambdas and expression trees. It can be easily translated to other query languages (like SQL) or functional paradigms, and is much more advanced than some map/iterate operators on generic types (which languages like Go dont even have). The LINQ query syntax (from x in list select x.a) is syntactic just sugar to easily write complex expressions that the compiler turns into the same standard list.Select(x => x.a) method calls.
  - eropple 8y ago
    I promise you that I understand the idea; I have run in .NET circles, particularly Mono, for a long time. It is an interesting goal, but I prefer to stay somewhat in the land of what is--and so I am talking about what is actually done with it in the wild, not what architects blog about. It's map-reduce-fold in the majority case, and when it's not (getting into the IQueryable minefield) I often have found myself going "oh, no."
- fbarred 8y ago
  You can call it a library, but for LINQ to work at least four major features had to be added to the language or runtime: -anonymous types -implicitly typed variables -object initializers -lambda expressions It's interesting that all of these features are very widely used (except maybe for anonymous types) outside of LINQ, but LINQ was the driving force for adding them to the language. Anonymous types were needed to do the equivalent of "select field1, field2" that are familiar to SQL programmers, or to have intermediate values in a chain of Select/Where/Select operators. Implicitly typed variables (var) were needed to refer to the above types. Object initializers are needed so you could create the anonymous types, and non-anynymous ones too without breaking the LINQ chain. Lambda expressions of course were needed. All of the above are used outside of LINQ. This was done in 2007. Java got streams and lambda expressions in 2014. JavaScript got it in 2015. The SQL like syntax - well it exists. I think many people don't realize it's there. Everyone uses the method/lambda syntax.
  - wvenable 8y ago
    It's not lambda expressions necessary for LINQ but the ability to access the expression tree and translate C# code into other languages (like SQL). There are not many languages with that feature.
  - eropple 8y ago
    All true! But, as you note, they're prerequisites for LINQ, not LINQ. Thing is, though? These days, I would say that all four of the features you describe are barely table stakes. Having lambdas made C# cool in 2007, but it's not 2007 anymore and that the four features you listed are probably the important new features I can think of since 2007 is why I like C# a lot less today. As is probably obvious from my reference to them, I believe that record types would be a contender for "most important new feature"--even moreso than async/await--after spending a lot of time with Kotlin and data classes, it is nearly impossible to go back. C# provides you with the choice of manually-updated boilerplate or mutable objects through your whole stack. That's what has generally kept me away from C# since exposure to first Scala, later Kotlin, and most recently TypeScript. And, while I now work at a C#-first company (not on the C# backend), I don't see a real reason to change that for me personally until they make writing correct code easier. In many ways, TypeScript seems to me to be a wiser future than what C# is presenting, but that's a whole other kettle of fish.
- jve 8y ago
  When I mean LINQ, i don't necessarily mean querying SQL. Working, filtering, grouping, selecting from collections in memory works very well. And i don't necessariliy also mean LINQ query syntax, but it can also be method syntax: .Where().Select()... And the power of ExpressionTrees that allows you to interpret code your own way. For example, substituting SharePoint CSOM library .IsPropertyAvailable(string) with IsPropertyAvailable<T>(this T clientObject, Expression<Func<T, object>> propertySelector) [0] is neat. Instead of magic strings you now have compile-time checking. Now you write .IsPropertyAvailable(s => s.ServerRelativeUrl) instead of .IsPropertyAvailable("ServerRelativeUrl") As for SQL, it may sometimes be a blocker, yes. But EF Core, for example, provides a FromSql method to use for complex queries. [0]: https://github.com/SharePoint/PnP-Sites-Core/blob/206ee97d4b0a418614629c2ef39ebd23c3e75cb0/Core/OfficeDevPnP.Core/Extensions/ClientObjectExtensions.cs#L34 https://github.com/SharePoint/PnP-Sites-Core/blob/206ee97d4b...
- MarkSweep 8y ago
  LINQ is pretty basic if you are just using the IEnumerable overloads. It get's more interesting when you use the IQueryable versions of things. LINQ to SQL and Entry Framework provide IQueryable implementations that turn C# code in to SQL. This code snippet demonstrates the C# feature these frameworks relies on: using System; using System.Linq.Expressions; class Program { static void Main(string[] args) { Expression<Func<int, int, int>> expr = (a, b) => a + b; Console.WriteLine(expr); Func<int, int, int> fun = expr.Compile(); Console.WriteLine(fun(1, 2)); } } When run, this outputs: (a, b) => (a + b) 3 When a Expression<T> variable is assigned to or a method taking an Expression<T> parameter, the C# code is not translated into MSIL (normal C# is compiled to MSIL). Rather it is translated into an AST. In my example I just compiled it to MSIL, however LINQ-to-SQL and Entity Framework translate the AST to SQL. This macro-like capability is the true power of LINQ. The rest is syntactic sugar (though very delicious sugar). If I were to try to critique LINQ, it would the normal ORM complaints. Sometimes you have to care about what is going on underneath in the C#-to-SQL translation. Your code may compile, but at runtime the generated SQL might have terrible performance.

by jve 8y ago

eropple 8y ago

Calling LINQ a "feature" still feels very off to me. It's a set of library functions with some very strange and, at least in my neck of the woods strongly discouraged, SQL-ish syntax that you can use if you like making it harder to understand what your code is actually doing. The library functions are...fine, to be clear, aside from the inconsistent-for-the-sake-of-inconsistent naming (and I know they want to ape SQL, but 'Select' is a map function, sorry). But...they're library functions. You should expect that stuff to exist in a programming language worth a fart. C#'s feature changes over the last few years have been marginal. They nibble at the edges while stuff like record classes--an actually and materially valuable thing that significantly improves the writing of immutable and functional code--have been punted for multiple versions now. C# is Java now, in a way it wasn't when it was younger. It's afraid of change and in being afraid of change has slowed to a crawl. Such is probably the way of most programming languages and ecosystems. But it is a little sad for me to see.

thrower123 8y ago
The weird special-case LINQ syntax appears to have receded and I don't recall seeing it in the wild for some time. Hopefully we can just all agree that was a bad idea and it can get officially deprecated and go away in future versions.
- wvenable 8y ago
  Yeah, I mostly use the methods to do LINQ and rarely use the linq syntax -- but -- it's actually quite powerful and if you have to do a reasonably complex query it's much easier to compose and read in that syntax than the alternative mess of method calls and lambdas.
- jve 8y ago
  Umm, the special-case LINQ syntax actually it is nothing special on itself, it just calls those methods anyway. You can actually extend LINQ by providing your own Extension methods for IEnumerable or IQueryable
  - thrower123 8y ago
    Right. Which is why it's jarring seeing these blocks of non-idiomatic almost-SQL DSL embedded in otherwise consistent C#. Particularly when you have to materialize a query by calling ToList() or similar - you end up with an extra unsightly mix of query and method syntax with the query wrapped in parentheses. Or else cluttered up with defining intermediate variables that need to be named. Much better in my opinion to just stick with the fluent method chaining style of using LINQ methods.
- recursive 8y ago
  You'll never get me to agree. I still use it when I need a `let`.
manigandham 8y ago
LINQ is not just library functions. It stands for "language integrated query" and is a full data modeling and querying system designed around lambdas and expression trees. It can be easily translated to other query languages (like SQL) or functional paradigms, and is much more advanced than some map/iterate operators on generic types (which languages like Go dont even have). The LINQ query syntax (from x in list select x.a) is syntactic just sugar to easily write complex expressions that the compiler turns into the same standard list.Select(x => x.a) method calls.
- eropple 8y ago
  I promise you that I understand the idea; I have run in .NET circles, particularly Mono, for a long time. It is an interesting goal, but I prefer to stay somewhat in the land of what is--and so I am talking about what is actually done with it in the wild, not what architects blog about. It's map-reduce-fold in the majority case, and when it's not (getting into the IQueryable minefield) I often have found myself going "oh, no."
fbarred 8y ago
You can call it a library, but for LINQ to work at least four major features had to be added to the language or runtime: -anonymous types -implicitly typed variables -object initializers -lambda expressions It's interesting that all of these features are very widely used (except maybe for anonymous types) outside of LINQ, but LINQ was the driving force for adding them to the language. Anonymous types were needed to do the equivalent of "select field1, field2" that are familiar to SQL programmers, or to have intermediate values in a chain of Select/Where/Select operators. Implicitly typed variables (var) were needed to refer to the above types. Object initializers are needed so you could create the anonymous types, and non-anynymous ones too without breaking the LINQ chain. Lambda expressions of course were needed. All of the above are used outside of LINQ. This was done in 2007. Java got streams and lambda expressions in 2014. JavaScript got it in 2015. The SQL like syntax - well it exists. I think many people don't realize it's there. Everyone uses the method/lambda syntax.
- wvenable 8y ago
  It's not lambda expressions necessary for LINQ but the ability to access the expression tree and translate C# code into other languages (like SQL). There are not many languages with that feature.
- eropple 8y ago
  All true! But, as you note, they're prerequisites for LINQ, not LINQ. Thing is, though? These days, I would say that all four of the features you describe are barely table stakes. Having lambdas made C# cool in 2007, but it's not 2007 anymore and that the four features you listed are probably the important new features I can think of since 2007 is why I like C# a lot less today. As is probably obvious from my reference to them, I believe that record types would be a contender for "most important new feature"--even moreso than async/await--after spending a lot of time with Kotlin and data classes, it is nearly impossible to go back. C# provides you with the choice of manually-updated boilerplate or mutable objects through your whole stack. That's what has generally kept me away from C# since exposure to first Scala, later Kotlin, and most recently TypeScript. And, while I now work at a C#-first company (not on the C# backend), I don't see a real reason to change that for me personally until they make writing correct code easier. In many ways, TypeScript seems to me to be a wiser future than what C# is presenting, but that's a whole other kettle of fish.
jve 8y ago
When I mean LINQ, i don't necessarily mean querying SQL. Working, filtering, grouping, selecting from collections in memory works very well. And i don't necessariliy also mean LINQ query syntax, but it can also be method syntax: .Where().Select()... And the power of ExpressionTrees that allows you to interpret code your own way. For example, substituting SharePoint CSOM library .IsPropertyAvailable(string) with IsPropertyAvailable<T>(this T clientObject, Expression<Func<T, object>> propertySelector) [0] is neat. Instead of magic strings you now have compile-time checking. Now you write .IsPropertyAvailable(s => s.ServerRelativeUrl) instead of .IsPropertyAvailable("ServerRelativeUrl") As for SQL, it may sometimes be a blocker, yes. But EF Core, for example, provides a FromSql method to use for complex queries. [0]: https://github.com/SharePoint/PnP-Sites-Core/blob/206ee97d4b0a418614629c2ef39ebd23c3e75cb0/Core/OfficeDevPnP.Core/Extensions/ClientObjectExtensions.cs#L34 https://github.com/SharePoint/PnP-Sites-Core/blob/206ee97d4b...
MarkSweep 8y ago
LINQ is pretty basic if you are just using the IEnumerable overloads. It get's more interesting when you use the IQueryable versions of things. LINQ to SQL and Entry Framework provide IQueryable implementations that turn C# code in to SQL. This code snippet demonstrates the C# feature these frameworks relies on: using System; using System.Linq.Expressions; class Program { static void Main(string[] args) { Expression<Func<int, int, int>> expr = (a, b) => a + b; Console.WriteLine(expr); Func<int, int, int> fun = expr.Compile(); Console.WriteLine(fun(1, 2)); } } When run, this outputs: (a, b) => (a + b) 3 When a Expression<T> variable is assigned to or a method taking an Expression<T> parameter, the C# code is not translated into MSIL (normal C# is compiled to MSIL). Rather it is translated into an AST. In my example I just compiled it to MSIL, however LINQ-to-SQL and Entity Framework translate the AST to SQL. This macro-like capability is the true power of LINQ. The rest is syntactic sugar (though very delicious sugar). If I were to try to critique LINQ, it would the normal ORM complaints. Sometimes you have to care about what is going on underneath in the C#-to-SQL translation. Your code may compile, but at runtime the generated SQL might have terrible performance.