design

Type systems... We all know they are cool. In a static language, like Kotlin, the type system is the one responsible for early detection of errors. Many tools (e.g. an IDE with its refactoring abilities) also rely on the type system. We also know that type systems are hard: many computer scientists built their entire careers studying type systems. Yet we know rather little about type systems of main-stream languages. (more…)

Kotlin is designed so that there's no such thing as a "static member" in a class. If you have a function in a class, it can only be called on instances of this class. If you need something that is not attached to an instance of any class, you define it in a package, outside any class (we call it package-level functions): package foo fun bar() {} But sometimes you need static constants in your class: for example, to comply with requirements of some framework or to use serialization. How do you do this in Kotlin? (more…)

In Kotlin M5 we have redesigned our ranges a little bit. (more…)

It's been a while since I blogged last time on Kotlin M2. Now, the hot summer has passed, and M3 will be out very soon. In this post I describe two small features added in M3 that make our lives easier and will lead to simplification of the language. How do you traverse a map? Assume you have a map like this: val counts: Map<User, Int> = database.howManyDocumentsEachUserHas() What do you do to traverse it and handle each entry? (more…)

As the first public preview of Kotlin is approaching (it will be announced on Jan 10th, 2012, which is less than a week from now!), we are putting some things in order... In particular, we have reviewed syntactic forms available in the language, and decided to change a few. These changes are incompatible with the old syntax, and we have migrated all our test data, and will update the publicly available documentation soon. I would like to point out that this is not the last change of this sort. Kotlin is not released yet, and until it is we are constantly gathering feedback and sometimes find

A post about good books, language design and JIT compilation, in which one bug turns into another and than back... Recently I started looking through an excellent book "Java™ Puzzlers", where Joshua Bloch and Neal Gafter provide a list of Java's "Traps, Pitfalls, and Corner Cases", i.e. programs that make you think they do what they really don't. My idea is to see how many of the puzzlers are ruled out or fixed by Kotlin. I've looked through the first 24 items, and 15 of them are fixed in Kotlin, which is over 60%. Some of the puzzlers can't be fixed without severe implications on compatibi

If you have a very nice API, it is the fashion nowadays to call it an internal DSL, because the code that uses such an API reads almost like a language inside your language of choice. Fluent interfaces serve as one of the most popular examples. Many modern languages provide some advanced means for creating internal DSLs, and Kotlin is no exception here. In this post I will briefly list the features that are useful for this purpose. (more…)

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;

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 h