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

41–50 of 112 posts

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

#41

Post by bad_user »

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…

Go's interfaces are not type-classes and type-classes aren't about structural typing.

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

#42

Post by jacques_chester »

pswenson wrote: post #15
lmm wrote: post #11

Earlier quoted context omitted.

Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plug…

how do you do conditionals or loops in maven?

> how do you do conditionals or loops in maven?

What you're asking for is Turing-complete XML.

History has shown that this is usually a mistake.

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

#43

Post by bad_user »

lmm wrote: post #26
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. 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 get duplicate functions with different names, duplicate code, duplicate tests, etc.

Another advantage is that in Scala type-class instances are actual values that you can pass around. And because type-class instances are actual values, along with implicits which are lexically scoped, you can always provide another instance of a type-class, depending on context. You do not have the modularity problems arising from usage of type-classes in Haskell.

"The best implementation" is entirely subjective IMHO.

EDIT: got down-votes, not complaining, but I'd like to know where I'm mistaken. Thanks.

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

#44

Post by nirvdrum »

pswenson wrote: post #15
lmm wrote: post #11

Earlier quoted context omitted.

Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plug…

how do you do conditionals or loops in maven?

You can use the maven polyglot plugin [1] to write your POM in something other than XML. It's fairly new, but it's there. We use it in JRuby to write our POMs in Ruby. As an example of a loop:

https://github.com/jruby/jruby/blob/8e29ae1302e7aa989b8808f7...

[1] -- https://github.com/takari/polyglot-maven

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

#45

Post by bad_user »

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…

Both OOP and type-classes are a form of ad-hoc polymorphism, but OOP is not a replacement for type-classes. The scope overlaps and personally I find both useful, but you're making the mistake to think that type-classes are about subtyping. They are not.

Also, type-classes in Scala are not implemented by means of "implicit conversions". It has nothing to do with it. Type-classes in Scala are implemented by means of implicit parameters, also called context bounds, but that's different.

Of course, you don't really need implicit parameters to work with type-classes. That's just syntactic sugar, because you can just pass dictionaries (type-class instances) around manually.

No, the far bigger problem that Kotlin has is that it doesn't support higher-kinded types. Without higher-kinded types you can't express generic code for containers (e.g. M[T]). And without that, you can't do do type-classes and you can kiss most FP abstractions goodbye.

If you don't believe me, try coming up with an interface for things that have "map", "filter" or "flatMap.

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

#46

Post by herval »

winterbe wrote: post #20

Kotlin 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-... :-)

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

#47

Post by azth »

mahmoudimus wrote: post #33

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?

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

#48

Post by lmm »

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…

I find typeclasses are vital when you want to give your classes secondary functionality e.g. serialization, database persistance. You need only look at the modules, mixin annotations, reflection and XML configs that Jackson or Hibernate have implemented - for good reason! - to see that traditional OO is inadequate for that kind of use case (particularly when you have a generally usable library datatype e.g. joda-time - no-one would want to have joda-time depend on Hibernate or Jackson, but at the same time the code to use it with those things should be in some library, so how do you safely connect them up?)

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

#50

Post by lmm »

norswap wrote: post #37
lmm wrote: post #30

Earlier quoted context omitted.

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.

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"?
Post reply on HN