Congratulations to Andrey and the rest of the JetBrains team. This really has been a long time coming. I've been following and experimenting with Kotlin now for the past year or so and it definitely solves a lot of Java's pain points without having to reinvent the way one thinks about programming languages. The interoperability and backward compatibility is one of the most useful features, meaning I don't have to wai…
> Especially with Java9 on its way, it's only going to get better. What's Java 9 going to add that Kotlin can benefit from?
Kotlin 1.0 Released: Pragmatic Language for JVM and Android
71–80 of 112 posts
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#72Earlier quoted context omitted.
While it's an excellent example, I wonder if people don't see "endoMonoid" and run away screaming. I really wonder if people would have different reactions if this was presented as "Addable" instead.
Yeah, I wonder about calling it "addable" or "mergeable". But neither of those really captures the full generality of it - would you expect composing functions to count as "adding" or "merging"?
Integers can also be combined with other operations, like multiplication, min or max. None of those sound like "adding" or "merging" them to me.
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#73Earlier quoted context omitted.
No. Structural types are called structural types. The best known typeclass implementation is that of Haskell where they're built into the language, but Scala has them as a pattern implemented with implicits; I can try to explain the concept here if you like but honestly there are probably better explanations out there. Typeclasses are more powerful than structural types in that the implementation doesn't have to be t…
> The best known typeclass implementation is that of Haskell Oh, I don't know about that one. In Scala type-classes are interfaces and you can put that OOP to good use. For example in the Cats library, you get an Applicative type-class inheriting from Apply, a FlatMap inheriting from Apply and a Monad inheriting from FlatMap and Applicative. By comparison in Haskell a Monad is not automatically an Applicative and you…
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#74Kotlin is a beautifully designed language: small, modern + statically typed that's naturally terse and elegant - ideal for both OOP and LINQ-like/functional programming: https://github.com/mythz/kotlin-linq-examples Thanks to JetBrain's tooling prowess it also has great integration with Android Studio - Light years better for functional programming than Java 1.7: https://github.com/mythz/java-linq-examples Which can…
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 IEn…
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.
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#75Kotlin sort of feels like Groovy "done properly" (with no disrespect to the authors of Groovy). Groovy kind of evolved in an opportunistic, unplanned manner and ended up with millions of features, cool whiz bang aspects that look awesome that don't always turn out well when you use them on a large scale. Kotlin seems to capture the same ideas (highly pragmatic, maintain perfect bidirectional compatibility with Java),…
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#76Earlier quoted context omitted.
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 IEn…
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 howeve…
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;Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#77Earlier quoted context omitted.
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 howeve…
>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;
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.
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#78Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#79Earlier quoted context omitted.
>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;
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 readabl…
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 to represent an asynchronous computation. This is common code we would write in a large C# application I was on at my previous job.
Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
#80Kotlin is currently my favorite alternative JVM language. Kudos to all collaborators for the great work. After 5 years of hard work, you finally made it! Here's a little starter project for Kotlin webapps using Spring Boot and React.js, I made a while ago: https://github.com/winterbe/spring-kotlin-react-demo
My humble contribution to the hipster-stack-starter-pack: https://github.com/herval/gradle-kotlin-docker-multiproject-... :-)
I want to cry.