7 ms·

You're really comparing a small subset of what "LINQ-like functional programming" is to the (small) pieces that Kotlin can do. LINQ is not (just) an interface

by runT1ME 11y ago

You're really comparing a small subset of what "LINQ-like functional programming" is to the (small) pieces that Kotlin can do. LINQ is not (just) an interface over some collections. It is a comprehension syntax (that kotlin doesn't have) that works on any types that have Select/SelectMany/Where. This gives you a lot more power than what Kotlin gives you, as you can 'extend' other things that don't inherit from an IEnumerable<T>; for instance Task or a custom data type that has its own inheritance hierarchy. The 'comprehension' part means you can deeply nest things (similar to scala's for compehension) without building up a stack of {}. This is quite common when doing asynchronous programming, and Kotlin doesn't really help you out at all here.

mythz 11y ago
It's not a small subset, it's the most popular subset that .NET developers use LINQ for everyday as identified by C#'s 101 LINQ Examples and compares them against the equivalent code in Kotlin. The C# examples does use the LINQ SQL-like DSL whereas other languages get by with a more readable and less indirection version using functional API's available on collections. It's up to the developer which they prefer however the LINQ DSL is no more powerful than regular function chaining with lambdas. LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression. None of these examples are in the published LINQ 101 examples as they're usefulness is limited to a small niche of use-cases.
- runT1ME 11y ago
  >languages get by with a more readable I'd love to see how you think the kotlin (or java) version of the following would be more 'readable' var result = from a in taska from b in taskb from c in taskc(b) where c.Contains("blah") select c + a;
  - mythz 11y ago
    Again you're just cherry picking a rarely used niche example that benefits from a SQL-like cross join, that you couldn't even map to a real-world example. What's the point, to show it has terse syntax for rare use-cases? Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent.
    - runT1ME 11y ago
      >Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent. It has nothing to do with SQL cross joins across multiple collections. LINQ is useful for things that aren't even collections! In my example I was using them on a Task<T> to represent an asynchronous computation. This is common code we would write in a large C# application I was on at my previous job.
      - ufmace 11y ago
        It's not exactly helping your case that it isn't at all clear what that sample is actually doing and what kind of practical task it might be used for. I've been doing C# for years, use and enjoy Linq, and I can't remember the last time I touched the comprehension syntax. IIRC, it does make a few relatively obscure things easier than they would be with method and lambda syntax, while there are a few different obscure things that are easier without it. On balance, I lean against it as being yet another sub-language for you and the rest of your team to learn and understand what it's really doing under the hood.
        random314 11y ago
        The sample is not clear?! How would you write the same asynchronous code in C# without the LINQ syntax? Can you give an example? All the code does is get a from async taska, b from async task b, feed the result of b into task c to get c, and if c contains blah return c+a asynchronously.
- ZenoArrow 11y ago
  > "LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression." As far as I know, LINQ to SQL uses Expression Trees under the hood, I'd argue that even if you're not using them directly, LINQ to SQL is a pretty useful application of LINQ. Effectively, Expression Trees are what enables custom macros for LINQ. Even if not everyone writes macros, the number of users of those macros is much more widespread.

by runT1ME 11y ago

mythz 11y ago

It's not a small subset, it's the most popular subset that .NET developers use LINQ for everyday as identified by C#'s 101 LINQ Examples and compares them against the equivalent code in Kotlin. The C# examples does use the LINQ SQL-like DSL whereas other languages get by with a more readable and less indirection version using functional API's available on collections. It's up to the developer which they prefer however the LINQ DSL is no more powerful than regular function chaining with lambdas. LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression. None of these examples are in the published LINQ 101 examples as they're usefulness is limited to a small niche of use-cases.

runT1ME 11y ago
>languages get by with a more readable I'd love to see how you think the kotlin (or java) version of the following would be more 'readable' var result = from a in taska from b in taskb from c in taskc(b) where c.Contains("blah") select c + a;
- mythz 11y ago
  Again you're just cherry picking a rarely used niche example that benefits from a SQL-like cross join, that you couldn't even map to a real-world example. What's the point, to show it has terse syntax for rare use-cases? Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent.
  - runT1ME 11y ago
    >Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent. It has nothing to do with SQL cross joins across multiple collections. LINQ is useful for things that aren't even collections! In my example I was using them on a Task<T> to represent an asynchronous computation. This is common code we would write in a large C# application I was on at my previous job.
    - ufmace 11y ago
      It's not exactly helping your case that it isn't at all clear what that sample is actually doing and what kind of practical task it might be used for. I've been doing C# for years, use and enjoy Linq, and I can't remember the last time I touched the comprehension syntax. IIRC, it does make a few relatively obscure things easier than they would be with method and lambda syntax, while there are a few different obscure things that are easier without it. On balance, I lean against it as being yet another sub-language for you and the rest of your team to learn and understand what it's really doing under the hood.
      - random314 11y ago
        The sample is not clear?! How would you write the same asynchronous code in C# without the LINQ syntax? Can you give an example? All the code does is get a from async taska, b from async task b, feed the result of b into task c to get c, and if c contains blah return c+a asynchronously.
ZenoArrow 11y ago
> "LINQ also allows capturing Expression Trees however that's only useful for developers creating LINQ providers or where they need to capture and rewrite/reproject the expression." As far as I know, LINQ to SQL uses Expression Trees under the hood, I'd argue that even if you're not using them directly, LINQ to SQL is a pretty useful application of LINQ. Effectively, Expression Trees are what enables custom macros for LINQ. Even if not everyone writes macros, the number of users of those macros is much more widespread.