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

Kotlin Compiler Crash Course

github.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Kotlin Compiler Crash Course

#41

Post by The_rationalist »

blacktriangle wrote: post #28
jpgvm wrote: post #6

Earlier quoted context omitted.

Java developers are rightfully conservative and sceptical of "new things". That said I believe Kotlin really provides a strong value proposition over Java. You also don't sacrifice much, there is less tools ofc but enough to get by, performance is equal for the most part etc. Also unlike stuff like CS it has a very strong future with Android backing.

I'm not sure how well "less tools" holds up when Jetbrains has done an awesome job of supporting Kotlin in their Java IDEs. There's something to be said for a dev tool shop developing a language.

To have used both, Kotlin is probably the #2 language with best IDE support, and the gap between the #2 and the others is as huge as the gap between #2 and #1 (Java)!

Java has much more inspections, more intentions and some next generation inlay hints such as the "related problems" view. Thankfully Kotlin is catching up (and is e.g currently getting support for code vision)

On the other side Kotlin is THE language optimized for developper Happiness/ergonomics and its shows that it has been designed by IDE developers.

Re: Kotlin Compiler Crash Course

#42

Post by The_rationalist »

mumblemumble wrote: post #32
pdpi wrote: post #14

Earlier quoted context omitted.

Oracle is doing a good job adding features to Java to keep up with modern languages, but it’s not just about adding — some things need to be removed or changed. By way of example: Final classes by default with an open keyword instead of open by default with a final keyword. Inheritance is a very tricky thing to get right and it’s better to explicitly say “I thought about this and put in the effort to make it work”. C…

I can see checked exceptions being a good option for a pre-Java8 world, but they interact horribly with functional interfaces, which are fundamental to a bunch of other newer Java features. A lot of those are almost philosophical differences, though. A Java feature that is unambiguously bad, but probably impossible to remove, is the different equality semantics between atomic types and their boxed versions.

How is Valhalla affecting those semantics?

Re: Kotlin Compiler Crash Course

#43

Post by The_rationalist »

cutler wrote: post #22
olavgg wrote: post #12

Earlier quoted context omitted.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

Yeah, right, so why do I still have to escape regex metacharacters in Java in 2021? That's just so 1988.

You don't have to, java support raw strings. But yeah Kotlin is far superior, denying it is only proof of partial knowledge/ignorance.

Re: Kotlin Compiler Crash Course

#45

Post by The_rationalist »

jillesvangurp wrote: post #38
christiansakai wrote: post #27

How's Kotlin compilation story to JavaScript? Can we do frontend in Kotlin?

Yes you can. I'm using the Fritz2 framework, which is pretty nice. There's another one called KVision. There are also some people doing react in Kotlin. You can also just program straight against the browser APIs as they have nice Kotlin DSLs for large parts of that. Basically, to stay on topic, there are currently multiple kotlin compilers, including one that transpiles to Javascript. There is also tooling to interf…

How is the javascript interop? Can I use Angular/Vue and make kotlin components? Can I use any js/ts library from my kotlin code?

Re: Kotlin Compiler Crash Course

#46

Post by mpweiher »

pdpi wrote: post #25
mpweiher wrote: post #16

Earlier quoted context omitted.

> Final classes by default with an open keyword ...is exactly the wrong way around. Inheritance is very much about unplanned reuse and programming by difference. That is: there is something that almost works the way you want, but not quite. If you are actually planning this ahead, then typically inheritance is the wrong approach and you're better off using composition.

The whole point of OOP is that each object is responsible for maintaining its own invariants. Open classes are useless without open methods, and open methods are a weak point in terms of letting your child classes mess up those invariants. Interfaces are completely free of this burden. Abstract classes signal that you're working with an incomplete implementation and you're expected to cooperate with the base case to…

> The whole point of OOP is that each object is responsible for maintaining its own invariants.

I think there are a whole lot of people who might disagree with the assertion that this is "the whole point" of OOP. Including one Alan Curtis Kay.

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

> Open classes are useless without open methods

You seem to mix "class" and "object" rather freely. They are quite different things. Also, not sure what you mean with "open methods". I can add methods to something in a subclass. I can override methods in a subclass.

> letting your child classes mess up those invariants.

Who is the "you" of the "your" in this context? A class? But a class is not a really a thing, objects are. And it is the objects that are the units of encapsulation in OOP. Not classes. Classes are just convenient bundles of behaviour and templates for state that is attached to objects.

You might think this is silly nitpicking, but it's actually a really, really important distinction:

As a teacher of object-oriented programming, I know that I have succeeded when students anthropomorphise their objects, that is, when they turn to their partners and speak of one object asking another object to do something. I have found that this happens more often, and more quickly, when I teach with Smalltalk than when I teach with Java: Smalltalk programmers tend to talk about objects, while Java programmers tend to talk about classes. I suspect that this is because Smalltalk is the more dynamic language: the language and the programming environment are designed to help programmers interact with objects, as well as with code. Indeed, I am tempted to define a “Dynamic Programming Language” as one designed to help the programmer learn from the run-time behaviour of the program.

http://web.cecs.pdx.edu/~black/publications/O-JDahl.pdf

And the object in question is an instance of the subclass, and if you are going to involve classes, it is the subclass that is responsible for maintaining invariants. The superclass no longer has that responsibility for instances of the subclass. So nobody is messing with anyone's invariants.

Re: Kotlin Compiler Crash Course

#47

Post by jillesvangurp »

The_rationalist wrote: post #45
jillesvangurp wrote: post #38

Earlier quoted context omitted.

Yes you can. I'm using the Fritz2 framework, which is pretty nice. There's another one called KVision. There are also some people doing react in Kotlin. You can also just program straight against the browser APIs as they have nice Kotlin DSLs for large parts of that. Basically, to stay on topic, there are currently multiple kotlin compilers, including one that transpiles to Javascript. There is also tooling to interf…

How is the javascript interop? Can I use Angular/Vue and make kotlin components? Can I use any js/ts library from my kotlin code?

Pretty much yes to all of that. You can add npms as dependencies. Some typescript type annotations can be adapted to Kotlin type annotations. And if not, you can write your own. There's a dynamic keyword to deal with untyped javascript objects. Also you can define external interfaces for things. So, interop is pretty good and you have plenty of tools to integrate whatever. With Fritz2 you can create or integrate web components pretty easily as well.

That being said, it doesn't really make sense to try to use mainstream javascript frameworks as they are a poor fit for a strongly typed language like Kotlin. And in general, there aren't a lot of npms that are worth integrating. We made an exception for leaflet and that was pretty easy to integrate in the end. Otherwise we mostly use multiplatform kotlin libraries.

Re: Kotlin Compiler Crash Course

#48

Post by cutler »

The_rationalist wrote: post #43
cutler wrote: post #22

Earlier quoted context omitted.

Yeah, right, so why do I still have to escape regex metacharacters in Java in 2021? That's just so 1988.

You don't have to, java support raw strings. But yeah Kotlin is far superior, denying it is only proof of partial knowledge/ignorance.

Raw strings don't apply to regexen. You still have to escape the metacharacaters.

Re: Kotlin Compiler Crash Course

#49

Post by fulafel »

blacktriangle wrote: post #29
cutler wrote: post #21

Earlier quoted context omitted.

Try Clojure after which there's definitely no going back.

Completely different motivations, and I suspect Kotlin is a reason that Clojure and Scala seem to be losing much of their initial steam. Clojure offers Lisp on the JVM, but what most people really wanted was a fixed Java. That's exactly what Kotlin delivers. Clojure has decent Java interop, but there's a serious impedance mismatch working with native Clojure and Java libs. Kotlin otoh dogmatically sticks to Java's mo…

IME many Clojure programmers come from non-Java backgrounds and aren't looking for a Java like experience. So I can believe the "more better Java" audience probably heads for Kotlin today. I think this is a win for both the Clojure and Kotlin communities and developer cultures.

To inject some time perspective, Clojure is 14 years old, so it's not too bad to be moving from initial steam to young-adulthood steam now :)

Re: Kotlin Compiler Crash Course

#50

Post by specialist »

The_rationalist wrote: post #15

Kotlin has this amazing concept called compiler plugins where you can extend, intercept and alter the compiler at any stage of the compilation pipeline (ast, psi, ir) through an API. There even are frameworks that make writing such plugins easier such as https://github.com/arrow-kt/arrow-meta (which enable to bring union type, higher kinded types, pattern matching, etc) Or https://github.com/google/ksp

Thanks for mentioning this. Not knowing Kotlin, I'll read the links you provided.

Guessing this is a bit like Java's annotations. FWIW, I'm not a fan Java's annotation processing plugin stuff. It's fun for personal projects, cuz metaprogramming FTW. But debugging someone else's custom annotation stuff really sucks.

Post reply on HN