Multiple Inheritance Part 2: Possible directions

In the previous post in this series we discussed the disadvantages of the inheritance model we initially planned for Kotlin. Today we will talk about alternative designs.

Note that these posts are intended to provoke a discussion, so that we can benefit from your feedback and come up with a better design.

What’s out there

The previous post concluded with the following (incomplete) list of solutions to the problem of multiple inheritance available in other languages:

  • Java and C# have classes and interfaces, i.e. multiple interface inheritance and single implementation inheritance;
  • Scala has classes and traits that may implement methods and even have state, but their constructors can not have parameters;
  • Some other languages, like Fortress, do not allow state in traits;
  • <Your favorite language here>

We all know that Java’s approach is rock-solid, but imposes severe limitations on code reuse, so we would like to relax these limitations, but without getting ourselves into trouble. “First degree” of relaxing the limitations would be stateless traits (like in Fortress, and in [1]): no state in traits, no implicit overrides. Or we can trade inheritance of traits off for state and get mixins (like in Ruby). Relaxing the limitations even more we get to Scala’s traits that have state but no parameters for constructors, and one trait may override functions of another. Then we get to CZ’s classes with requires (as presented in [2]). The next step, I guess, would already be unrestricted multiple inheritance, like in C++.

We will skip a thorough analysis of each of these solutions, and just make a remark about state.
Continue reading

Posted in Uncategorized | 55 Comments

Multiple Inheritance Part 1: Problems with the existing design

I’m back from my vacation, and it’s time to get to one one the biggest issues pointed out in the feedback we received during conference presentations and in the comments to the docs. I’m talking about inheritance.

I plan to write a series of posts on this topic. These posts are intended to provoke a discussion, so that we can benefit from your feedback and come up with a better design.

This is the first post in the series, and I discuss the design we presented in July 2011. It features the following approach to inheritance:

  • there were no interfaces, only classes;
  • each class could have multiple superclasses;
  • if some non-abstract member (property or method) was inherited from two of the supertypes, the compiler required the user to override it and specify manually what code to run.

(For more details, see our wiki as of July 20th 2011.)

This is, basically, the infamous multiple inheritance story, and we remember from the C++ times that it is sort of bad. Let’s look closer.

It’s all about initialization

Let’s a look at the following example:

abstract class Base(x : Int) { ... }

open class Left(x : Int) : Base(x) { ... }
open class Right(x : Int) : Base(x) { ... }

class Child : Left(3), Right(4) { ... }

So, we have a diamond: Base at the top, Left and Right on the sides, and Child at the bottom. One thing looks suspicious here: Child initializes its superclasses passing different numbers two them: 3 to Left and 4 to right. Now, they, in turn, initialize Base with those numbers… What is Base initialized with?

Continue reading

Posted in Language design | Tagged , | 17 Comments

The Kotlin issue tracker is now public

Following the tradition of other JetBrains projects, we’ve opened up the issue tracker for Kotlin to the public. In the issue tracker, you can see some of our thinking and things we’re working on, and you can also file issues asking for new features in the language or changes in the current design. We hope that the tracker will let us keep the discussion more structured than the comments in the blog and on Confluence pages.

The URL for the tracker is: http://youtrack.jetbrains.net/issues/KT

Posted in Uncategorized | Leave a comment

Why JetBrains needs Kotlin

The question of motivation is one of the first asked when someone learns that someone else is working on a new programming language. Kotlin documentation offers a fairly detailed overview of why the language exists. Still, we would like to make it clearer what exactly JetBrains expects to gain from the whole endeavor. We’re obviously in it for the long run, and yes, we realize it will take years to reach our goals. And here’s why we are willing to make this investment.

First and foremost, it’s about our own productivity. Although we’ve developed support for several JVM-targeted programming languages, we are still writing all of our IntelliJ-based IDEs almost entirely in Java. The IntelliJ build system is based on Groovy and Gant, some Groovy is also used for tests, there is some JRuby code in RubyMine, and that’s it. We want to become more productive by switching to a more expressive language. At the same time, we cannot accept compromises in terms of either Java interoperability (the new language is going to be introduced gradually, and needs to interoperate smoothly with the existing code base) or compilation speed (our code base takes long enough to compile with javac, and we cannot afford making it any slower).

The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.

The final point is less obvious but still important: new programming languages is a topic that many people really enjoy talking about, and the first days that have passed since we’ve unveiled Kotlin prove that. We see that people who are already familiar with JetBrains trust the company to be able to do a good job with this project. Thus, we believe that this trust and the increasing community awareness of JetBrains will not only drive the company’s business, but will attract even more people to our approach to building development tools, and let them Develop with Pleasure.

And we’d like to reiterate that our work on Kotlin does not in any way affect our investment into other development tools, and in particular the Scala plugin. If you’re already happy with Scala and have no need for another new language, we’ll continue to do our best providing you with first-class Scala development tooling.

Posted in Uncategorized | 29 Comments

Slides from the JVM Language Summit presentations

Just a quick note: we’ve published the slides from the presentation and workshop that we gave on the JVM Language Summit.
The presentation covers higher-order functions and typesafe builders, and the workshop covers classes, multiple inheritance, generics and class objects.

Posted in Uncategorized | Leave a comment

Hello World

Today at the JVM Language Summit, JetBrains is unveiling the new project we’ve been working on for almost a year now. The project is Kotlin, a new statically typed programming language for the JVM.

With Kotlin, we’re building upon the many years of experience creating development tools for different languages, and hoping to provide a language which is productive enough for today’s environment and at the same time simple enough for the ordinary programmer to learn.

Right now Kotlin is under active development and nowhere near mature enough to be used by anyone outside of the development team. What you can do today is read the language documentation and leave feedback on the design of the language — what features you like, which ones are missing, what’s confusing and so on.

One thing to note: since we’re a development tools company, we’re building first-class IDE support for Kotlin in parallel with the language itself. And as soon as the language reaches its beta stage (currently planned for the end of 2011), we’ll release both the compiler and the development tools as open-source under the Apache 2 license.

There’s still a huge amount of work ahead of us, and we’re excited to hear what you guys think about our latest endeavor. So let the discussions begin!

Posted in Uncategorized | 10 Comments