Follow

After 5 months developing mainly in in my job, I really start to like the language (and I'm usually very biased against any JVM-based language). But there are a few things that could really be improved to make it better:

- Reflection is a mess. Inspecting the class type is a mess of `::class`, `.javaClass`, `.javaClass.kotlin` and another few hysteric constructs. Casting between `Class` and `KClass`, or between native properties and `KProperty`, is madness. Writing something that in Python would be as simple as `getattr(obj, attr_name)` ends up with several lines of code and workarounds in Kotlin.

- Type covariance and contravariance is poorly implemented. I should be able to have an abstract class with a `fun foo(A a) -> A` that gets overridden in a derived class by `fun foo(B b) -> B`, where `B` is a subclass of `A`, without doing additional casts and type checks in the code. In other words, I should have the ability to narrow down the scope of a function parameter or return type in a derived member. Java supports it, but Kotlin, for some reason, doesn't.

- Proper `Union` type implementation is missing. There are workarounds like `Either`, but they only work with type pairs and they have a cumbersome interface. I understand the challenges of implementing dynamic typing features in a language built on the JVM, but this is really a core feature for someone like me spoiled by languages with more polymorphic typing.

- Interfaces can't be extended, and I don't know why. I definitely see the use case where you define a base interface, and that interface can be extended by a new type that either adds new stuff, or implements default values for some of the upstream stuff. Even Java supports it, why wasn't it implemented in Kotlin?

· · Web · 1 · 0 · 1

@blacklight Which probably means that .NET might have some of the same issues; though not sure how far from Java the .nET languages now are, but C# and Java once looked very alike.

@cambridgeport90 C# in the meantime has made quite some progress in expressivity (and I say it as someone who usually despises Microsoft's decisions), while Java remained stuck on many design decisions. That's why Kotlin and Scala got so successful: they are 100% compatible with the JVM, but they are supposed to provide much more expressive power - especially when it comes to typing inference and functional programming paradigms.

But if Kotlin eventually doesn't proper support reflection, type covariance or interface extension...it feels a bit meh. I mean, that's not to underestimate the steps forward the language has made when compared to vanilla Java, but it feels a bit like a half-baked effort.

@blacklight the thing about Kotlin is how well it works or not with accessible interfaces for blind folks such as myself. It's difficult to do that in Java.

@cambridgeport90 what are your accessibility priorities from a programming language as a blind person? My guess is that the biggest part is played by the UI/editor (i.e. an editor like vim or emacs that provides consistent keyboard commands for navigating and editing the code is much better than something like VSCode/IntelliJ where many things are hidden behind menus), but are there also language-specific features and paradigms that make one more accessible than another?

@blacklight The UI and editor for the language itself is of course a priority, but then there's being able to navigate with text to speech through an interface created with the language itself.

@blacklight If you use Ubiquiti UniFi, for instance, try navigating through the Windows application with something like NVDA or JAWS for Windows. On Linux, try Orca and you'll just get a silent environment.

@blacklight That's because the native controls for JAVA don't expose any information for text to speech interfaces to latch onto. The ones for .NET, however, do. Hence why I leaned towards it even before it became cross platform.

@blacklight the odd thing... Web interfaces for Java don't suffer from this issue, so I'm normally able to solve access issues by running applications as services and then working from a browser. Good examples of that are Openfire, Ubiquiti, and Jenkins.

Sign in to participate in the conversation
Mastodon

A platform about automation, open-source, software development, data science, science and tech.