Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin 1.0 Released: Pragmatic Language for JVM and Android

blog.jetbrains.com

Post reply on HN
Print view View original

31–40 of 112 posts

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#31

Post by norswap »

mike_hearn wrote: post #25
norswap wrote: post #19

I've been using Kotlin for work (I'm a PhD student, so work is to be understood in a peculiar fashion) and I'm really liking it. It's a much needed upgrade to Java whose fundamental advantage is what I'd call "crispness": you can write terse code that is actually understandable. In particular, the notion of inlining closures allows for efficient functional programming and great DSLs. In comparison to Scala, Kotlin is…

By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-style interfaces? I don't personally understand why people care about that: a simple structural match on names/parameter types doesn't seem like a strong enough signal that someone actually intended to implement such an interface. But ... type classes can be implemented on the JVM relatively efficiently these days. I threw together a simple Ko…

No, not that. I agree with you on structural typing.

What I mean is what the Scala doc calls "context bounds": http://docs.scala-lang.org/tutorials/FAQ/context-and-view-bo... (bit outdated: view bounds are deprecated)

You could think of it as "abstracting over the adapter pattern", i.e. being able to write methods that take as parameter things that can be adapted to an interface.

(And of course the main point of the Adapter pattern is retroactive implementation of interfaces.)

But, and this is important, you get to pass the actual object instead of the adapter. This matters when you need to required multiple adapters, or when you work with object equality. The object type can also flow through the type parameters (although that's sort of doable with adapters only).

Finally, because a typeclass instance is actually a single object per type satisfying an interface, you can use it for things like factory methods (what they call constructor classes in Haskell).

It's close to what I propose here: https://discuss.kotlinlang.org/t/kotlin-and-the-expression-p...

but there are differences. Scala typeclasses are based on implicits, this gives you more control to select the adapter you want depending on where the code runs. But, unlike what I propose, it's dependent on static typing, so it's not possible to select the adapter depending on the run-time type.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#32

Post by mike_hearn »

norswap wrote: post #31
mike_hearn wrote: post #25

Earlier quoted context omitted.

By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-style interfaces? I don't personally understand why people care about that: a simple structural match on names/parameter types doesn't seem like a strong enough signal that someone actually intended to implement such an interface. But ... type classes can be implemented on the JVM relatively efficiently these days. I threw together a simple Ko…

No, not that. I agree with you on structural typing. What I mean is what the Scala doc calls "context bounds": http://docs.scala-lang.org/tutorials/FAQ/context-and-view-bo... (bit outdated: view bounds are deprecated) You could think of it as "abstracting over the adapter pattern", i.e. being able to write methods that take as parameter things that can be adapted to an interface. (And of course the main point of the…

Right, I remember your thread, which is I guess why I'm a bit confused, as you said what you really wanted to do is make a type implement a new interface.

I do understand Haskell type classes but in a language like that, they're almost obligatory as it's not an OO language at all. But in something like Kotlin, you should need it far more rarely, so the automatic/implicit "conversion" (I realise it's not quite "conversion" in Haskell) is less vital. So some convenience for creation of adapters would seem to get you the same practical benefits in much the same way.

With respect to the difference between using a singleton vs a freshly allocated wrapper - is it really worth complicating the Java interop for what seems like an optimisation? Code that works with object identity is rare in all the code I've written and can't even be done at all in a pure functional language. And requiring multiple 'adapters', you mean interfaces I think (?) can be done already by imposing multiple generic type constraints (the where clause). The VM should be able to optimise out the overhead of the wrapper class in many cases.

That leaves implicit conversion. But Kotlin doesn't even auto-convert Int to Long. I doubt that implicit conversion will ever be a part of the language outside of a few special cases like toString().

I guess for my use cases, a wrapper class + an extension method on the existing type that adds a toFoo() is sufficient.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#33

Post by mahmoudimus »

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 wait for an entire ecosystem to develop around it.

The tooling is also incredible and will only get better.

Concurrency support with Quasar and Comsat makes it relatively effortless without reinventing new libraries.

Overall, Kotlin, IMHO, is one of those items in the "Pro"s section on any shop seriously evaluating a JVM stack. Especially with Java9 on its way, it's only going to get better.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#34

Post by meddlepal »

thecupisblue wrote: post #2

Been using it for a while, glad 1.0 is out! This is an amazing replacement for Java on Android and hope it gets more public recognition now that it's officially out.

Been working with it as well since last summer and following it for a lot longer than that. Glad to see they've reached 1.0!

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#35

Post by meddlepal »

Nutomic wrote: post #7
merb wrote: post #5

actually I'm still unsure about kotlin. some things are really great some things are not. I mean i will still use kotlin, especially for libraries since it is great for that. however somehow I still missed something on top of Executors and CompletionStage. And I'm totally unhappy about "So, why doesn’t Kotlin have its own package manager, or its own build system? Because there’s already Maven and Gradle, and re-using…

Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.

The documentation for Gradle is very thorough but man is it a PITA to find answers for stuff, like, for example, how do I GZIP compress the output the application plugins distTar task. The answer is not something you would just arrive at when you do figure it out and it's also not documented anywhere.

Gradle's biggest problem is that it's too flexible.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#36

Post by norswap »

mike_hearn wrote: post #32
norswap wrote: post #31

Earlier quoted context omitted.

No, not that. I agree with you on structural typing. What I mean is what the Scala doc calls "context bounds": http://docs.scala-lang.org/tutorials/FAQ/context-and-view-bo... (bit outdated: view bounds are deprecated) You could think of it as "abstracting over the adapter pattern", i.e. being able to write methods that take as parameter things that can be adapted to an interface. (And of course the main point of the…

Right, I remember your thread, which is I guess why I'm a bit confused, as you said what you really wanted to do is make a type implement a new interface. I do understand Haskell type classes but in a language like that, they're almost obligatory as it's not an OO language at all. But in something like Kotlin, you should need it far more rarely, so the automatic/implicit "conversion" (I realise it's not quite "conver…

The point of the class instance (the "singleton") is not performance, it's that it exists independently of any instance of the type, so it can be used for factories and such.

This however, is not my main concern, and as you remarked, it does not fit very well in OO, which is why it isn't in my proposal.

On to the interesting part.

You want multiple adapters, rather than multiple interfaces, precisely because you want retroactive interface implementation. That's really the crux here. So either you pass two adapters, or you make a class combining the two adapters. I think both solution create too much bloat to be acceptable.

For me, equality isn't so rare. Both identity (==) and structural equality (equals(), done right) pop up with some regularity. Each time you use a map, for instance. And functional languages are perfectly capable of structural equality.

While Scala typeclases are implemented with implicit objects, typeclasses precisely avoid using implicit conversions. You still have the original object, the typeclasses just provides functions to work with it. It's only an implicit conversion in the same sense that passing an ArrayList to a function expecting a List is implicit conversion. This is manifest in Scala where you require a typeclass using some sort of type bound.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#37

Post by norswap »

lmm wrote: post #30
mike_hearn wrote: post #29

Earlier quoted context omitted.

But both Java and Kotlin interfaces can provide default implementations. So when I say "make a class implement an interface even if it doesn't declare it as so", that included interface default methods coming along for the ride. The best explanation of Scala type classes IMO is here: http://danielwestheide.com/blog/2013/02/06/the-neophytes-guide-to-scala-part-12-type-classes.html But as you say, what Scala calls type…

It's not just a default, you can provide an adapter specific to the type: implicit object IntMonoid extends Monoid[Int] { def zero = 0 def plus(a: Int, b: Int) = a + b } implicit def endoMonoid[A] = new Monoid[A => A] { def zero = identity def plus(a: A => A, b: A => A) = a andThen b } You can't do that with a default method.

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.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#38

Post by mike_hearn »

norswap wrote: post #36
mike_hearn wrote: post #32

Earlier quoted context omitted.

Right, I remember your thread, which is I guess why I'm a bit confused, as you said what you really wanted to do is make a type implement a new interface. I do understand Haskell type classes but in a language like that, they're almost obligatory as it's not an OO language at all. But in something like Kotlin, you should need it far more rarely, so the automatic/implicit "conversion" (I realise it's not quite "conver…

The point of the class instance (the "singleton") is not performance, it's that it exists independently of any instance of the type, so it can be used for factories and such. This however, is not my main concern, and as you remarked, it does not fit very well in OO, which is why it isn't in my proposal. On to the interesting part. You want multiple adapters, rather than multiple interfaces, precisely because you want…

Thanks for the explanations. Yes, there seems to be an impedence mismatch when trying to import the concept of Haskell type classes to OOP languages.

WRT a combined adapter class, it'd look like this in Kotlin:

  class FooBarAdapter(val x: Baz, private val y = Foo(x), private val z = Bar(x)) : Foo by y, Bar by z
A bit bloaty, but still a single line of code.

(I know you already know this, I'm writing it here for Kotlin newbies).

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#40

Post by crudbug »

I started looking at Kotlin docs [1]. For higher order functions support,

fun lock(lock: Lock, body: () -> T): T {

}

Is there any technical reasons why normal function declarations are not using '->' as a return operator ?

fun hello(name: String) -> String {

     println(name)
}

Swift [2], Rust & others are using it.

It will just make the experience uniform with consistent Functional Types

[1] https://kotlinlang.org/docs/reference/lambdas.html

[2] http://fuckingswiftblocksyntax.com

Post reply on HN