6 ms·

As LINQ has been positioned as one of C#/.NET's biggest strengths their 101 LINQ Examples are a nice set of simple code examples to compare how well different l

• bob1029 7y ago
  If you have the patience to dive really deep into the Expression Tree pool, you can build some incredibly powerful tools. See: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... http://twistedoakstudios.com/blog/Post2540_optimizing-just-in-time-with-expression-trees http://twistedoakstudios.com/blog/Post2540_optimizing-just-i...
  • mythz 7y ago
    I'm the author of 2 such LINQ providers that rewrite expression trees for execution in different remote persistent providers: - OrmLite https://github.com/ServiceStack/ServiceStack.OrmLite https://github.com/ServiceStack/ServiceStack.OrmLite (C# POCO ORM) - PocoDynamo https://github.com/ServiceStack/PocoDynamo https://github.com/ServiceStack/PocoDynamo (C# DynamoDB Client)
• fiddlerwoaroof 7y ago
  It’d be interested to see the Clojure examples redone with transducers and/or https://github.com/redplanetlabs/specter https://github.com/redplanetlabs/specter
  • mythz 7y ago
    PR's are welcome! I wrote the Clojure examples 6 years ago as a beginner whilst I was learning Clojure but I thought its built in functions were already well suited for LINQ examples. Do you have an example where transducers would help with verbosity or readability?
    • fiddlerwoaroof 7y ago
      I need to think about it, but they are more generic because they don’t make assumptions about the input sequence type and/or the resulting type. They are also more efficient because they don’t create any intermediate sequences.
    • jeswin 7y ago
      I haven't dealt with LINQ lately, but IIRC there was no way to do early termination on a sequence. // Not ideal list.Select(x => ExpensiveFunc(x)).Take(5); Transducers can be terminated early - https://dev.to/greencoder/build-your-own-transducer-and-impress-your-cat---part-4-2bp8 https://dev.to/greencoder/build-your-own-transducer-and-impr...
      • kevingadd 7y ago
        IEnumerable implicitly offers early termination. LINQ expressions are always implicit by default, so .Select(...).Take(n) will stop after taking N items. It's just like a foreach loop (same interface/API). For the same reason, if you 'foreach' over the result of a linq query multiple times, it will evaluate the whole sequence again, which often isn't what you want - so people tend to call .ToArray() or .ToList() at the end to fully evaluate it once.
        • 7y ago
• kccqzy 7y ago
  Isn't the point of LINQ to get monads into the language so that it can be used by a lot of different things (seemingly having no relations to data processing), rather than just data processing tasks?
  • mythz 7y ago
    I've no idea what you mean? LINQ is a "Language-Integrated Query" for the C# and VB.NET languages which built upon a number of features in .NET Framework v3.5 to make possible. It shipped with a "LINQ to Objects", "LINQ to SQL" and a "LINQ to XML" provider. Of the features that differentiates it from querying functionality in other languages is its Expression Trees support that I've highlighted in my last paragraph which is essential for being able to implement alternative LINQ providers.
  • goto11 7y ago
    Not really. You can have monads without Linq, but there is a particular use of the 'from' syntax which can be used as a cleaner syntax for monadic operations. But this seem more like a hack than an intended use case. It is rumored that Linq was initially implemented using monads, but that approach was abandoned due to performance reasons.
    • contravariant 7y ago
      That rumour seems like it's false, because not only is "implemented using monads" a rather vague qualification, Linq has currently been implemented by requiring objects to implement the SelectMany function, which has signature: MyObject<B> SelectMany(MyObject<A>, Func<A, MyObject<B>>) or perhaps more familiar to the Haskell folks: SelectMany :: M a -> (a -> M b) -> M b i.e. exactly the 'bind' operator for Monads. I think you also need to implement a 'Select :: M a -> M b' operator, rather than a 'return :: a -> M a' operator, which would be closer to a true Monad, but the 'bind' operator is the one that really matters anyway.
      • goto11 7y ago
        The rumor was that the standard extension methods on IEnumerable<T> like Join, Select, Where, Group were all implemented on top of SelectMany. I call it a rumor because I cannot remember where I read it, so it is quite possible I have misunderstood it.
• dmitriid 7y ago
  I briefly looked at Swift. C# examples can be just as short if you use the underlying .select, .where etc. instead of the Linq DSL
  • apetrovic 7y ago
    If I'm not mistaken (I didn't worked in Swift for a while) Swift doesn't have proper generators. For each projection or filtering Swift will create a new array, while C#/Linq will use generators to make one really long state machine that saves memory.
• BoiledCabbage 7y ago
  It's a nice list, but I believe there are two major faults in your comparison. The first is that LINQ supports "transducers" completely and by default for all enumerable collections. Its built in to the language and has been there from the start (almost 8 years before they were added to Clojure). Taking for example the top language from the list, Swift, as far as I know Swift doesn't support them. And my intuition is that many to most languages on the list there don't support that behavior by default. That's a fairly large difference. The second is, if you're going to compare languages based on compactness of syntax, you can't write other languages using a compact fluent syntax, and then write c# with SQL and say the other languages are more compact. LINQ comes with a compact fluent syntax and a verbose (but more familiar at the time and thus easier ramp) SQL syntax. The documentation when introducing concepts it used the SQL syntax. As anyone who has familiarity with the tools uses the fluent syntax. Yes you can say you used samples from the docs, but those are for teaching. You can't compare them to hand written code using a compact syntax. Use the flutent syntax for all both langs to do an accurate comparison. I applaud the effort, but it's not an accurate comparison in it's current form.
  • mythz 7y ago
    Your entire comment suggests you didn't bother to read the project docs? These are Microsoft's MSDN C# 101 LINQ Examples, I did not write the C# LINQ Examples, Microsoft did, to show how to use LINQ. The languages are a comparison to their docs, I'm not rewriting their C# examples, otherwise it couldn't be called "C#'s 101 LINQ Examples in ....". LINQ is the query language that's used in the 101 LINQ Examples, it's not the "compact fluent syntax" you're referring to of calling IEnumerable<T> extension methods directly, that's not the "Language-Integrated Query" that LINQ stands for, the purpose of Microsoft LINQ Examples was to showcase how to use LINQ. The purpose of each language comparison was to achieve the same result of each example, but in the idiomatic style of that language.
    • thrower123 7y ago
      The extension method syntax is the de facto idiomatic standard. The idiosyncratic special syntax was misguided and fortunately is largely abandoned. Alas we are stuck with the reserved keywords forever.