Will Java always be a prerequisite to learning Kotlin and other JVM languages?

21

This particular class was a more-or-less straight port of what I’ve done with my students in Java8, so there are no extension methods and the best you can do are default methods on interfaces. If you were engineering this thing specifically for Kotlin, then you’ve got an interesting design case to be made for extension methods vs. default methods on the interface. The benefit of extension methods is that they keep the interface slim. The benefit of default methods on interfaces is that you can specialize them, when appropriate, to improve performance.

Another purely stylistic question, of course, is how much you care about interoperating with Iterator<T> and other such things, versus having all the usual functional methods on lists (map, filter, foreach, fold, etc.). From an educational perspective, you want the students to build everything up from scratch themselves, thus they know how it works because they wrote it. That’s totally different from what you’d want in a production environment.

As to the argument in favor of having an IList interface (which we don’t bring up until a few weeks into the class): this allows for lazy lists and eager lists to coexist without most clients having to know or care which one they’re dealing with. In my class, for next year, I’m planning to take the somewhat weird tactic of initially doing no class inheritance whatsoever. Just interface implementation and you can share code with default methods. I’ll bring class inheritance in later in the semester. This makes for another argument in favor of having default methods in the interface, namely that they’re forced to be implemented in terms of the public-facing methods, since they cannot see the private implementation.

Anyway, the “wart” in this case was the type erasure aspect of Java, which Kotlin inherits. The idea that the JDK libraries represent another wart really depends on your perspective. Nobody says you have to use them, unless you’re trying to interoperate with some other library that requires them. Kotlin tries to strike a balance by giving you a shiny functional veneer on top of the traditional Java list classes. This seems reasonable for many things.

22

I’m going to pop my 2p / 2c into the conversation as well.

I;ve been saying for sometime that it is possible to teach someone to program in Groovy without having to know Java first. I have seen this work in at least one company I worked it and through workshops. From my point of view, the same is possible with Kotlin. I think it is ineventable that one would eventually have to learn some Java, but that would not be a bad thing.

In earlier years people said you should learn C before C++. That eventually became a detractor and led to some bad C++ code (or C with classes as it wa mockingly called). I am sure in some situations knowing too much Java, could actually lead to writing bad Kotlin or Groovy.

23

I did the same thing in a recent project. We built a DSL that was basically an extension to Groovy. The users had very little or even no prior knowledge of Java or programming.

For isolated use cases that works quite well. But sooner or later, you’ll reach the limits:

Kotlin only developers

  • need to understand the Java collections API (because they will want to use those in their code)
  • need to understand Java visibilities
  • need to understand Java’s idea of Boxing and Generics
  • need to understand Java specific concepts (static comes to mind)
  • need to understand how arrays happened in Java (and how to deal with them)

From a language point of view, I would rather start out with Kotlin. I would not start out with Groovy. There simply is too much magic going on in Groovy that is really hard to understand for beginners. Especially, as I have found that doing the same thing in Groovy in two similar ways may result in two very different outcomes. The reason for this usually is not obvious to a beginner.

24

I think we can agree that with a number of wonderful languages on the JVM you can get some way before having to learn Java and even then you might only need to know the basics (as you have listed). It can happily be debated which language is the best to start with (to which there is probably no ONE and ONLY answer).

From what my experience of Kotlin is so far, I think that it is definitely a candiates for a first lanaguage on the JVM. It’s readable, concise and does not clutter the screen with unnecesary punctuation of keywords. That is already a big plus for me.

25

I think I agree with the general sentiments here. Kotlin would make a great first language if learning resources are positioned for beginners. There will come a point as a beginner progresses they will need to learn Java to advance their knowledge. Navigating Java libraries and their documentation, the nuances of the JVM environment, and getting help from a broader Java community all would warrant a need to learn Java.

What will be especially interesting is to see what happens on Android. I see a growing number of Android articles covering Kotlin instead of Java. When new Android developers are faced with a choice of learning Kotlin vs Java, that will be a major shift and we should start seeing Kotlin books for beginners. And yeah, some argue Java 8 coming to Android will marginalize Kotlin. But I switched to Kotlin after being a fan of Java 8 for a year. As some people said about Scala, Java 8 might actually help Kotlin as people are introduced to functional concepts.

26

I’ll go out on a limb and say no, you don’t need to learn Java to learn Kotlin. I base this on a technicality: Java’s just a language, as is Kotlin or C or Pascal or whatever. It’d help in understanding why some things are the way they are, but I wouldn’t say it’s a pre-requisite by any stretch.

I’ve been writing Java for over 15 years now, so it’s kinda hard for me to separate the language from the JVM platform or the JDK libraries, but they are still separate entities. You can write a compiler that takes Java source code and compiles it to straight x86 machine code. It’d be mostly useless unless you translate all of the jars out there, but those are still separate from the language itself.

The ecosystem of the language has no bearing on learning to program with it. Yes, Boost makes C++ much nicer (so I’m told, at least), but you can still learn a lot of C++ before it’s something to concern yourself with. You also don’t have to worry too much about the hardware side of things when you’re learning; you’re not writing device drivers on your first day, so it doesn’t matter if you’re targeting x86 or PPC or ARM or whatever. Likewise, the fact that you’re learning to program in a language with access to the full Maven repo of libraries and running on the JVM is pretty inconsequential.

While these are definitely things that would help someone understand a lot of the “why’s” behind the scenes, I don’t think they have to be framed under Java itself in order for someone to learn how to program in Kotlin.

The collections API is definitely nice to have, but it isn’t a language feature, it’s part of the library. It can be introduced in terms of Kotlin instead of Java - i.e. using mutableListOf<String>() instead of new ArrayList<String>().

Visibilities are an aspect of pretty much every OO language I’ve come across; if you’re developing in an OO language, you’ll end up learning the different visibilities. Java does some things with visibilities a little differently than other languages, but you can still teach someone how they work without focusing on Java. (Or Kotlin, or any other specific language).

Boxing and Generics are also general concepts - C# has them as well. They can be taught in a language-agnostic manner, or a Kotlin-specific manner, or a Kotlin/Java mix.

Aside from statics, not sure what Java-specific concepts would apply; even statics, though, are common across languages. Instead of calling them statics, you teach the student that they’re companion objects and now it’s Kotlin-ized :slight_smile:

The only issue I see with arrays in Java vs. other languages is when generics get introduced into the mix (aside from stuff like locality of reference, but that’s a whole other bag of worms in itself and way beyond intro-to-programming level details). That’s a platform issue, not Java per-se, and while my .NET-fu is rusty, I’d imagine they have similar issues with generic arrays there (I’m running late to get out of work so don’t really have time to take a few seconds and google it).