3 ms·
In LINQ, the extension methods defined on IEnumerable are useful, but not that interesting, because they are standard functionality in most modern languages. I
by bad_user 13y ago
In LINQ, the extension methods defined on IEnumerable are useful, but not that interesting, because they are standard functionality in most modern languages. I also think the naming used (e.g. Where, Select) is unfortunate and it would be better to go with the naming used by other languages/frameworks that are much more standard, like filter() or map(). This implementation is also missing SelectMany (e.g. flatMap or bind), which is much more interesting than Select and Where (i.e. you can implement Select and Where in terms of SelectMany).
What makes LINQ special is IQueryable, e.g. the ability to transform a C# expression at runtime into something else, like a database query. Whenever I see article titles like "LINQ in X", I somehow know that it doesn't refer to IQueryable, which is a pity.
Anyway, these functions should be standard in any modern programming language and because Go is missing such standard functionality is one reason for why I don't like Go. Lack of generics has much to do with it, but also Go's interfaces are weaker than type-classes, combined with Google's disregard for everything we've learned about type-systems in the past 30 years (behold Dart's covariant generics) and so I do have reasons for not holding my breath waiting for a fix. Of course, Go is what many people want, so Go is what many people receive.
- V-2 13y agoHowever, most languages in common use are not "modern" by this definition (if by any) ;) I've switched from C# to Java and the clunkiness of it drives me crazy. I know that Java 8 brought a new LINQ-like API, but it won't be available for Android development for a while (not to mention there's existing codebase to maintain etc.).
- noelwelsh 13y agoThis is very true -- most languages in common use are 20 or more years old and were not cutting edge when they were created. However you don't have to accept the status quo. Scala is viable on the JVM, F# on .Net, and Haskell (and increasingly Rust) if you want to avoid a VM.
- V-2 13y agoC# has enough functional capabilities (for typical development needs like mine), so I never felt the need of using F#. Scala, on the other hand, looked quite neat.
- _random_ 13y agoOr you could pay for Xamarin and avoid having to deal with Java.
- V-2 13y agoIf I was an entrepreneur, I might, but as an individual developer, I couldn't afford it... It's a real pity that Google didn't go with C# as their language of choice for Android development. The world would suck less. And they actually considered it... "If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language - or - 2) Do Java anyway and defend our decision, perhaps making enemies along the way" http://www.fosspatents.com/2011/07/judge-orders-overhaul-of-oracles.html http://www.fosspatents.com/2011/07/judge-orders-overhaul-of-...
- bad_user 13y agoThe problem with Java 8 on Android is JDK 7, as it introduced invokeDynamic that will have to be supported by Dalvik, plus I think the additions to the standard library are also a work in progress. It will happen though. For Android you can use Scala and many people do it. There's a SBT plugin for painless setup and you can work with IntelliJ IDEA as your IDE. Some people even go for Clojure. For iOS, there's RoboVM [1] and you can also use that in combination with Scala - it's very promising. Java the language sucks, but the JVM and the ecosystem are great and you've got mature languages designed to run on top of it, languages with big communities behind them. Of course, learning a new language and finding the best stuff in a huge ecosystem where choices abound takes time and patience, but I think you'll learn to appreciate it - or if you like C# so much, there's always Xamarin, though it's a little pricey. [1] http://www.robovm.org/ http://www.robovm.org/ [2] http://xamarin.com/ http://xamarin.com/
- V-2 13y agoI thought about Scala (+ Android Studio), but from what I googled it's not clear if setting it up is smooth
- aabalkan 13y agoI would not blame Google in particular. Go team operates like they are not part of Google most of the time. You are right about the abilities of other languages to make things easier for LINQ-like scenarios. But in Go, that's as much as I could get. I don't know what else to do. I am planning to add SelectMany, ToDictionary, GroupBy and Zip methods soon. I cannot agree you more, I also am not happy about the result I ended up with. Anyway, this was my first project in Go, I will maintain and keep adding stuff to make things easy for other people who might like to use this. But Go is 'really' not for this, I know.
- bad_user 13y agoSorry for my rant on the language. It's interesting what you did and definitely helpful for other people, especially if you implement the other missing parts you mentioned.
- masklinn 13y ago> much more interesting than Select and Where (i.e. you can implement Select and Where in terms of SelectMany). Well it doesn't provide a folding method either, and just about anything can be implemented using a fold.
- deleted 13y ago[deleted]
- kreeben 13y agoWhat is a folding method?
- bad_user 13y agoTrue, but if you're into FP, then folding is for those cases in which you really need the flexibility of iterating over the collection but without the side-effects. This has consequences. For example you can't distribute a fold over multiple threads. I'm not very keen on parallel extensions to collections, haven't found a concrete usage for them where it matters, but this does tell you something about folding - it's a low-level operation with which you're back to specifying how instead of what you want. And for collections, at least you've got the flexibility of doing a fold or a foreach painlessly, but for other container types you're out of luck. SelectMany/flatMap/bind is the defining operation of a Monad, which is a general purpose design pattern that has many uses (e.g. Option, State, Cont, Future, Iteratee, Rx.Observable, etc). It's cool having it, because then you can painlessly filter and transform the values in those containers without pulling them out of their context. To quote Erik Meijer: "Monads are return types that guide you through the happy path".
- frowaway001 13y agoI think we should invent a term for "LINQ, except for all the interesting parts".