Skip to end of metadata
Go to start of metadata

Welcome to Kotlin documentation page. Please consult the menu on the left.

Some quick links:

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 20, 2011

    Anonymous

    It likes Groovy. What's difference?

    1. Jul 20, 2011

      Anonymous

      It looks like groovy, while remaining strongly typed. Big difference!

      1. Jul 20, 2011

        Anonymous

        Groovy is strongly typed. Perhaps you meant statically typed?

        1. Jul 20, 2011

          Yes, I believe they did.

  2. Jul 20, 2011

    Anonymous

    The kotlin code examples are not very readable in IE. They appear on one long line.

    1. Jul 20, 2011

      Anonymous

      stop using IE 

    2. Jul 22, 2011

      Anonymous

      Love the new feature.

    3. Feb 29, 2012

      After spending a whole day implementing workarounds & quirks for IE6 (yes, there are still dinosaurs using IE6 in 2012!) I just want to peacefully shot people who are using IE — in any version.

  3. Jul 20, 2011

    Anonymous

    Why, if there is Scala already, right with IntelliJ IDEA plugin for it?

  4. Jul 20, 2011

    Anonymous

    There are a lot of computer languages in the world already, I think it would be better for IntelliJ to concentrate its efforts for the current products (IDEA for instance) because they have got still not ideal quality

  5. Jul 20, 2011

    Anonymous

    It seems like Kotlin hasn't been designed with concurrency in mind. Do you guys have plans to address this issue in later revisions of the language?

    1. Jul 20, 2011

      For now, Kotlin inherits Java's concurrency infrastructure, and we are planning on having an actor library, and maybe something like C#'s async-await in future versions.

      1. Jul 20, 2011

        Anonymous

        C#'s async-await is loosly based on F# asynchronous workflow, which is far superior to C#'s async-await.

        In other words, if you're looking for inspiration, look at the way F# does it rather than C#.

      2. Jul 20, 2011

        Anonymous

        What about support for STM on a language level?

        1. Jul 20, 2011

          Not until one manages to implement that effectively over JVM

        2. Jul 20, 2011

          Sounds pretty scary. Could you point me to some source that explains how this can be done efficiently on the JVM?

          1. Jul 20, 2011

            Anonymous

            Clojure has STM support: http://clojure.org/refs

            1. Jul 21, 2011

              Thanks.

              That's a library, not a language feature. You can use Closure STM inside Kotlin, if you like.

  6. Jul 20, 2011

    Anonymous

    Why not "def" or "function", but "fun"? Don't you think it's a weird keyword name?

    1. Jul 20, 2011

      We'd like people to have fun while programming

      1. Jul 20, 2011

        Anonymous

        I'm afraid it's not fun anymore iif it's a keyword

      2. Jul 23, 2011

        +1 for fun.

      3. Jul 25, 2011

        Anonymous

        With operator overloading it certainly becomes fun times

        I'll get me coat...

      4. Nov 23, 2011

        Anonymous

        +1 for "def"

    2. Jul 20, 2011

      Anonymous

      I always that it is good to give my variables and properties descriptive names.

      Why would you use the shorthand fun?

    3. Jul 21, 2011

      Anonymous

      Au contraire, I'm so glad that it's "fun" - finally someone did it right for a change. Using "def" for functions always sounded silly to me - it would make some sense if it was for all definitions (as "define" is in Scheme), but ever since Python misappropriated it for functions only, it has been spreading in that role all over the place like cancer. Meanwhile, if you use "var" to declare variables (which makes perfect sense!), then surely the obvious counterpart for functions is "fun"! ~

      1. Jul 21, 2011

        Anonymous

        I don't think "fun" is a good keyword. "func" is better, "def" is the best.

        1. Jul 21, 2011

          Anonymous

          "def" (short for "definition") is overly generic compared to "fun". I'm in favor of "fun" as a mnemonic (as opposed to spelling out "function") because (a) There is no real chance that a developer is going to misunderstand what "fun" is (as opposed to, say, naming your variables "str_cr_wrth", yet (b) fun is nice and compact where it counts. Less typing with clarity retained.

        2. Nov 18, 2011

          Anonymous

          How about "fn" like Clojure?

    4. Jul 22, 2011

      Anonymous

      +1 for fun.

    5. Aug 01, 2011

      Anonymous

      `fun` is really strange. I like all the other features except this.

      +1 for `def`

    6. Nov 18, 2011

      Anonymous

      -1 fun

  7. Jul 20, 2011

    Are there any plans to add support for immutable objects?  e.g. something like Scala's copy() method on case classes?

    1. Jul 20, 2011

      Yes, we are considering something like this, but the decision on these things will be postponed a little as it falls more into the category of library development, and we are not exactly there yet.

  8. Jul 20, 2011

    Anonymous

    Another language, really? Don't you guys have anything to do?

    1. Jul 20, 2011

      Anonymous

      +1

      Why don't you continue to invest your resources in being the best tools / IDE maker on the planet?!  Seems like a waste.

      IntelliJ is still the best out there, but isn't nearly as snappy as 3, 4.5, or 5.x days :(

      Eclipse is certainly catching up and offers many things that were once core IntelliJ features like intentions and intelligent refactoring

      1. Sep 16, 2011

        Drifting OT from Kotlin, but I find current IntelliJ as snappy as the old days.  I work with hugely larger codebases now, with much more tools integration (Spring, Maven, etc.) so I'm asking a lot more of my editor than I use to.

      2. Sep 17, 2011

        Catching up, funny how they have been saying that for years.

  9. Jul 20, 2011

    Anonymous

    You guys should help to improve Scala instead of creating a Java 2.0.

    1. Jul 21, 2011

      Anonymous

      Scala is very overcomplicated already, and gets more and more so. No sane person should have to contemplate the semantics of things like path-dependent types, IMO. I don't think it stands a chance at becoming a mainstream language given these things.

      Kotlin, now - I can see this work. It takes the nice and _simple _stuff from Scala without overdoing the features, and the result is somewhat more extensive than C#, but not by so much as to make it overcomplicated. That, and - unlike Scala - I'd expect that release 1.0 of the language would have complete IDE support for all language structures - whereas with Scala, all plugins for all IDEs out there still struggle to get it right (which, by the way, does tell something about the complexity of the language... wonder if it takes as long for Scala as it did for C++ in the end).

      So, bring it on!

      1. Jul 21, 2011

        You are saying that Scala has complicated features. That might be true, but you don't have to use them! If you think that path-dependent types are hard to use - just don't use them, use only the simple Scala features. I don't really see any reasons why Kotlin was invented.

        1. Jul 22, 2011

          Anonymous

          Oleg, that is impossible in the real world. When you're coming to a project of legacy code (that hundreds different people written several yyears), you have no chanses ignore all scala overcomplicated features. You'll have to understand all of them.

          1. Jul 23, 2011

            There are coding standards for that. At the build time post-processing parser can make sure that there are no advanced scala features used in the code and fail the  build if it finds some. By doing this you ensure that none of those hundreds of people have any chance of introducing scala complexity into the code.

            1. Jul 25, 2011

              Anonymous

              Which, while a nice thought, leaves you with same problem as C++'s abundancy of features. Every team and project uses a different subset of Scala and you're back where you started.

          2. Jul 25, 2011

            Anonymous

            Personally, I think that raising the entry standard for programming is a good thing. There are too many lazy incompetent programmers out there already without making it even easier for them.

    2. Jul 21, 2011

      Anonymous

      Absolutely right.

  10. Jul 20, 2011

    Anonymous

    This looks absolutely wicked - I'll be checking it out as soon as it hits the streets. Scala is overly complex and the features you've outlined here would make Kotlin a real contender for industrial use. Open source licensing is also a plus point - nice work guys. 

    1. Jul 20, 2011

      Anonymous

      In which areas do you think Scala is more complex?

  11. Jul 20, 2011

    Anonymous

    I've got a couple of questions regarding reification of generics:

    1) Do you compile Kotlin to plain old JVM bytecodes? 

    2) Does Kotlin reification achieve feature parity with .NET?

    3) Could you, please, describe the way you reify the generics? Do you attach a reified type to every single object or it's something else?

    1. Jul 20, 2011

      1) Yes, absolutely
      2) Depends on what you mean by feature parity. For example, .NET's JIT specializes generic classes upon instantiation, and Kotlin does not do that (at least, for now).
      3) For now, we attach a field with a TypeInfo object to every instance of a generic class. I'm not aware of any other reliable ways to reify the type information.

      1. Jul 20, 2011

        Anonymous

        You can use name mangling, like in good old C++ so List<Int> becomes List__Int.class. We've used this loooong ago in 2002 in our toy JVM language.

        Scala also does this with @specialized annotation.

        1. Jul 20, 2011

          Yes, there're other solutions, too. But for now we decided to refrain from implementing them.

          1. Jul 20, 2011

            Anonymous

            I'd really like to take a stub at this problem once the compiler arrives.

            1. Jul 21, 2011

              Glad to hear this!

  12. Jul 20, 2011

    Anonymous

    I absoluteley _love_ Kotlin. It seems to be the JVM language of my dream. I've listed some things I love here: http://rsdn.ru/forum/philosophy/4349959.1.aspx

    A few questions though:

    1) Are tail calls optimized? If yes, then @tailrec annotation from Scala will be needed.

    2) Collections library. You should steal it from Scala, probably.

    3) Lists and pattern matching. It would be nice to be able to do something like:

    Also, is it possible to receive access to Kotlin compiler? I _really_ want to play with it.

    1. Jul 20, 2011

      1) They will be, and the annotation will be there
      2) There will be a collections library, and we will definitely look at Scala's one and consider other designes as well
      3) Something like this is possible, not with the infix ::, but still

      The compiler is a little bit too early stage to be played with, but we'll fix that soon

      1. Jul 23, 2011

        Good grief, TCO!?  This is fantastic news.

  13. Jul 21, 2011

    Anonymous

    Could I ask in what language are you developing compiler? Is there plan to have Kotlin Compiler in Kotlin itself?

    1. Jul 21, 2011

      The Kotlin compiler is currently developed in Java. We'd like to rewrite it in Kotlin some day, but it's not a very high priority; it will definitely not happen before the beta release.

      1. Jul 21, 2011

        Anonymous

        It sounds like Kotlin is mostly a superset of Java (excepting a few things such as raw types?). So it should be possible to do direct automatic code translation from Java to Kotlin eventually.

        1. Jul 21, 2011

          We do plan to implement an automatic conversion tool, but obviously it will just provide a straightforward translation. To have code written in an idiomatic way, you have to write it in Kotlin, not convert it automatically.

  14. Jul 21, 2011

    Anonymous

    Why not to get Kotlin free of curly braces?

    1. Jul 22, 2011

      Anonymous

      Completely agreed. This should be an array language.

    2. Jul 22, 2011

      Anonymous

      I think the biggest problem with your proposal is that it then wouldn't look almost exactly like scala.

  15. Jul 21, 2011

    Anonymous

    1. Will there be a REPL?
    2. What's your preferred way of getting comments? On this wiki? On the blog? Is there a mailing list? 
    1. Jul 21, 2011

      1. Yes
      2. This wiki so far. Indeed, we're receiving somewhat more feedback that we expected and thinking of setting up forums and mailing lists. What platform would suit best, what do you think?

      1. Jul 21, 2011

        Anonymous

        1. Cool! :)
        2. I don't know about forum/mailing list platforms. You already have Confluence, maybe you just need to set up a discussion page for each major topic.
      2. Jul 22, 2011

        Wiki is best but does not scale, as you imply.  My mild preference is for Google groups: public record, reader can get mails if they choose, JetBrains can set up special interest subgroups as warranted.

  16. Jul 22, 2011

    Anonymous

    cool story, bro

  17. Jul 22, 2011

    Anonymous

    Nice. But why make the same syntactic mistake that Scala and Mira made (and Ceylon seems to avoid)?

    Example (in Java):

    Cust<enter Ctrl-Space>
    Customer firstTime<enter Ctr-Space> 
    Customer firstTimeCustomer; 
    Cus<Ctrl-Space> 
    Customer recurring<Ctr-Space> 
    Customer recurringCustomer; 

    How could you possibly do that when you have to type the name of the variable first?

    firstTimeCustomer : Customer

    ???

    -- Bob Lauer

    Warum sie aber den selben Quatsch wie Mira und Scala machen, den Variablennamen vor den Typ zu schreiben, habe ich noch nicht verstanden. Wie soll man da Code Completion einsetzen?
    z.B. in Java:
    Cust<Ctrl-Space>
    Customer firstTime<Ctr-Space>
    Customer firstTimeCustomer;
    Cus<Ctrl-Space>
    Customer recurringCustomer;

    1. Jul 22, 2011

      With type inference you normally wouldn't have the type name at all.  So it would be

      val firstTimeCustomer = Customer(...)

      You can always use introduce variable and let IDEA create the variable for you:

      Customer(...)<ctrl-alt-v>

      val <caret>customer = Customer(...)

      It works beautifully in Java and you don't even have to start typing the type name.

      1. Jul 25, 2011

        Anonymous

        Well, it *works* in Java (Strg-W is your friend, or Shift-Alt-V in Eclipse), but it's not really what I would call beautiful.

        A *really* cool thing would be a language that does away with all the naming redundancy and allows you to define an onthology of names (some generic, some domain specific). For example: Why should you be allowed to write

        String number = "hello";

        Integer text = 2;

        That's syntactically valid Java code, but semantically it's complete nonsense. An onthology would clean up the naming mess, improve project communication, *and* require less typing (just dreaming, it'll come one day).

        So you'd write:

        isbn<purpose> is number;

        new, bought is purpose;

        ...

        isbnNew = "1234";

        isbnBought = "3498";

        (static typing, (almost) without the typing part!)

        -- Bob

  18. Jul 23, 2011

    Anonymous

    Looks cool.  One thought. What about exploring the idea of adding fancier type checking.  For example if we have a method (in Java):

    void f(double x);

    We know that x must be a double, but if have to look at the documentation to see that it must be between [0,1] ... etc.  I don't know what would be appropriate syntax, but this is a whole new language, can try out new things!

    void f(double[0..1] x);

    1. Jul 23, 2011

      Though not absolutely impossible, that's a little hard to do )

      1. Jul 23, 2011

        Anonymous

        What about a syntax that is readable .. good documentation, but instead of static type checking, it would generate the appropriate asserts.  So ya, the fancier stuff would be a runtime error, but still you would have the documentation and also a nice layer to ensure proper ranges/values during development.

        1. Jul 23, 2011

          I think, this might be doable in the form of a language extension.

          1. Jul 31, 2011

            Anonymous

            How about Design by Contract support?  At least for pre-conditions and post-?

            1. Aug 02, 2011

              We plan to have a language extension for this as well

              1. Aug 16, 2012

                +1 vote for DbC

    2. Jul 25, 2011

      Anonymous

      Right now, I don't know of any usable/industrial-grade type system that would implement what you want (partial/restricted types) without resorting to heavy use of assertions.

      And if assertions are okay, it would seem best to me to take directly the route of including full Design by Contract.

  19. Jul 23, 2011

    Anonymous

    Oh also possibly something for array restriction

    f(int[] x)   (how can we indicate that this array must have 8 values, or be a multiple of 8, etc

    Support for multidimensional arrays

    m[0,5]

    support for complex, long long, double double ... would be awesome to.

  20. Jul 23, 2011

    Anonymous

    Hi,

    Could you please publish a PDF/ePub version of this guide as well?

    Thanks in advance,

    Behrang

    1. Jul 23, 2011

      Currently it's difficult to have a publishable quality document out of this wiki. But if you like, I can send you HTML that's more or less OK, and you can convert it as you like. Drop me an email at andrey.breslav[]jetbrains.com

      1. Dec 19, 2011

        It's not too difficult actually. You just need to create one-page version of documentation using "{include}" wiki syntax (see MPS User's Guide (one page) for example). And on that page you need to invoke Tools -> Export to PDF.

        1. Dec 19, 2011

          I'll try this. Thanks!

  21. Jul 23, 2011

    Anonymous

    Hello JetBrains-Team!

    At work I develop in C# with Visual Studio and ReSharper and at home in Java and Scala with IntelliJ IDEA. Each of these programming languages has great features, but none unfortunately contains all.

    It's not that long ago that I said: "There should be someone who takes the best things of the current programming languages (C #, Java, Vala, Scala, etc.) and creates a new language which contains all great features of them."

    And now I've come across Kotlin. The language is gigantic! It has everything one need – especially the long awaited null-safety.

    With this language you do not longer simply write sourcecode – with this language you compose a symphony!

    I can hardly wait for the public beta.

    You are great! Keep it up!

    Best regards,
    JMP

  22. Jul 23, 2011

    Anonymous

    Whats the GUI library going to look like?

    1. Jul 25, 2011

      No particular work have been done on this yet. One is supposed to code against existing APIs like Swing, SWT etc.

  23. Jul 24, 2011

    Anonymous

    Kotlin looks really nice -- thank goodness someone is trying to create
    a humane compiled language for the JVM. I love that control structures
    are expressions and it's interesting to see the influence that dynamic
    languages are having on modern compiled languages.

    What I would love to see in Kotlin is some syntactic sugar:

    1. Regular expression literals and operators (Ruby) and "hereregexes"
       (CoffeeScript: http://jashkenas.github.com/coffee-script/#regexes).

    2. Single quoted string literals that don't do any interpolation or
       escaping (Ruby, CoffeeScript).

    3. Indentable Heredoc strings (CoffeeScript:
       http://jashkenas.github.com/coffee-script/#strings)

    4. Comprehensions (Python, CoffeeScript).

    Disclaimer: This stuff is off the top of my head, please excuse any
    gaffs -- dynamic languages are my thing (my language de jour is
    CoffeeScript). Would love to program for Android but can't face
    returning to Java and haven't got enough brain cells for Scala.

    Looking forward to the first public release.

    Cheers, Stuart
    --
    Stuart Rackham

  24. Jul 24, 2011

    Anonymous

    "Industrial Use."

    What does that mean specifically?

    1. Jul 25, 2011

      Anonymous

      Not to put words in their mouths but as I understand it I think this comment from Hermann Schmidt on Infoq nails it:

      http://www.infoq.com/news/2011/07/kotlin#view_71626

      1. Jul 25, 2011

        Anonymous

        Yes, that seems about right, and leads to a worthy set of design principles that I would sum up like this :

        1. Consolidation rather than innovation: following identified best practices; eliminating failed features; taking inspiration from the good parts of a variety of other languages.
        2. Making developers' life easier/more fun: reducing boilerplate code while staying close to the Java syntax; making hairy features understandable and usable; reducing easily avoidable mistakes; and maybe later improving of the dubious parts of the Java library.

        I commend them for such a lofty project, but I wish they'd take cues from another language that had "industrial use" as its main goal: Eiffel. (Even if it didn't make as big an impact as its creator Bertrand Meyer would have wished, its influence can be felt today-viz. properties-, and IMHO Design by Contract is an idea still waiting to make its big splash).

        Anyway, I cannot wait to see how it will finally turn out. Thanks, JetBrains!

  25. Jul 24, 2011

    Anonymous

    Will Kotlin support Android right away? 

    1. Jul 25, 2011

      AFAIK any language that compiles to JVM bytecodes does

      1. Sep 10, 2011

        Anonymous

        Yes, that's true, but the thing needed is build support.  Right now if I want to build an Android app I have to either use Eclipse or Intellij which will build the APK, or I have to write an Ant build.  Either way, some build tool is needed.  For Scala there's an eclipse plugin: http://code.google.com/p/treeshaker/  

        1. Sep 10, 2011

          I see what you mean. We will provide something like this, but probably not in the first public beta. I created an issue in our tracker: http://youtrack.jetbrains.net/issue/KT-296

  26. Jul 25, 2011

    Anonymous

    What is JetBrains' primary motivation to start develop this? At first glance, this looks like a long-running, expensive project. What's the intended trade-off?

  27. Jul 26, 2011

    Kotlin looks nice so far. Thank you for doing this.

    A few observations/requests...

    1. I would love to see a "Java 2.0" language (like Kotlin) implement 64-bit indexable arrays (and thus implicitly 64-bit size support for collections, etc). I know that this more a JVM limitation, but the JVM has lacked this feature mostly because its language (Java) can't implement this feature without breaking backwards-compatibility, so why bother supporting it in the JVM? However, if our goal is to migrate away from Java and move the JVM forward (by creating a new JVM language like Kotlin), I think it would be nice to bake in this feature from the start. Perhaps, as a segue, the Kotlin collections package could support 64-bit sizes, even though the underlying implementation would only support 32-bit sizes. Or perhaps the Kotlin collections package could use multiplexed 32-bit indexable arrays to implement 64-bit indexable arrays. In any case, with current server hardware, it is not uncommon to see 64GB-128GB of RAM on one machine. I have certainly run into situations (actually, quite often these days), where I would like to have more than ~2 billion elements in, say, a HashMap, but need to resort to either multiplexing tricks, or multiple JVMs (either on the same machine or distributed across a cluster of machines). The point is, the 32-bit array indexing limitation seems rather old-fashioned these days, and if it weren't for Java's legacy issues, I would have no doubt that the JVM would fix this. Perhaps Kotlin could help to push this feature into the JVM. See fastutil for an excellent, highly optimized (performance and space) primitive collections library, including library support for 64-bit indexable arrays/collections (albeit generally slower because of multiplexing).

    2. Another thing I would love to see is support for optimized collections when the parameterized types are primitives. I know that Kotlin abandons the notion of primitives as a language construct, however, nothing prevents the compiler from using optimized versions of the collections classes when the parameterized type is analogous to a Java primitive type. For example, nothing prevents a HashMap<Long, Boolean> from actually using something like a LongToBooleanHashMap behind the scenes. Again, see fastutil for an excellent, highly optimized (performance and space) primitive collections library. I know that there has been some work in Scala using @specialized and fastutil.

    3. I know this might be "opening a can of worms", but has there been any consideration for a language construct like C++ "const"? I would love it if we could have immutable objects without having to resort to class pairs like List/ImmutableList, etc. This isn't to be confused with Kotlin's/Scala's "val" and Java's "final", which only make references "immutable" (set-once).

    1. Jul 26, 2011

      +1 for const.

      I really like Fantom's approach.  Immutability is baked into the type system and thread safety is enforced by only allowing immutable objects to be passed between threads.

      http://fantom.org/doc/docLang/Concurrency.html#immutability

      Also +1 for something like Scala's @specialized annotation.  Although maybe this isn't a feature for v1.0.

    2. Jul 27, 2011

      1 and 2 are mostly on the VM side. It's not impossible to do on a language level, but it's difficult and runtime penalty is high. 2 is easier than 1, though.

      3 is totally possible, and we currently plan it to be a custom annotation, and not a part of the language design

      1. Jul 27, 2011

        Hi Andrey,

        So in reference to #1, so what if the Kotlin collections package used 64-bit sizes in the interfaces (but not in the implementations)? For example, instead of something like "List.size() : Int", we would have "List.size() : Long". The List implementation classes that Kotlin supplies may only support Int-sized lists, but at least someone else could implement a list that supports Long-sizes without having to create an entirely separate and incompatible interface (BigList, etc).

        Just a thought.

        1. Jul 27, 2011

          I see your point. One other detail to think about here is why 64-bit and not 128 or 1024?

          1. Jul 27, 2011

            I like the way you think :)

            I'm all for > 64-bit support for really future-proofing things. However, it's not so much that 64-bit support "future-proofs" anything, but rather "current-proofs"... the 32-bit limitation is very antiquated at this point.

            Being careful not to generate any "N is all you'll ever need" statements, but Long.MAX_VALUE is a huge improvement over Integer.MAX_VALUE, which, for example, is 8 exabytes versus only 2 gigabytes. And it's not even so much about "how many bytes", but rather "how many items" can be supported in one collection. In this aspect, Long.MAX_VALUE is huge improvement, and would allow for even distributed Collection implementations that span 100s/1000s of machines to be API-compatible with "regular" Collection implementations.

            1. Jul 27, 2011

              Fair point

      2. Sep 20, 2011

        Anonymous

        Since immutability is such an important issue, can you create an extra confluence page that elaborates on this?

        1. Sep 20, 2011

          As soon as we get it fully thought through

          1. Sep 20, 2011

            Anonymous

            Well, here are some issues that I think are important.

            1. Should immutable classes be stack-allocated as in C# (http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx)?
            2. Should immutable classes be automatically co-variant? This one is actually bugging me for a long time and I don't have a perfect solution yet.
            1. Sep 21, 2011

              1. To our knowledge, this is impossible to implement on the JVM in a reasonable way
              2. This is unsound. Variance does not have anything to do with mutability. Consider these immutable classes:

              open class Formatter<T> { 
                abstract fun format(t : T) : String 
              } 
               
              class IntFormater() : Formatter<Int> { 
                override fun format(x : Int) : String = x.asHex() 
              }

              Can IntFormatter be assigned to something of type Formatter<Any>? No, because its implementation of format() will break if you pass anything but an Int there. And these classes don't even have state (either mutable or not).

  28. Jul 28, 2011

    Anonymous

    What is JetBrains' primary motivation to start develop this? At first glance, this looks like a long-running, expensive project. What's the intended trade-off?

  29. Jul 29, 2011

    New JVM languages (Clojure, Groovy, JRuby, Scala, etc., now including

    Kotlin) are probably the bright future of Java platform. Nevertheless, they are often
    rejected by major customer as "not reliable", "not enterprise" or "not yet mature".

    When starting to create Kotlin, don't you have a strategy how to face it?

    In my view, there are several categories of customers:

    1. Customers who request Java bytecode; they could get, in theory, Clojure / Groovy / etc. compiled into bytecode - this is the simplest situation
    2. Customers who request Java source code
    3. Customers who request Java source code and will maintain it by themself - here we can't probably find a way out

    For the 2nd category, a partial workaround might be to decompile Java bytecode and
    "masquerade" it a little. I mean, replace those parts that are most strikingly
    of other origin than Java.

    Let's take as example name of an inner class that serves to implement a closure.
    From AST of Clojure / Groovy / etc. source, we know e.g. the method that passes the
    closure as its parameter, the variable the closure might be assigned to etc.
    So the inner class name could be replaced automatically by something that could
    go more or less unnoticed. Generic terms such as "Handler" or "Processor"
    could be used as glue.

    It could work with some customers, but can't you see something cleaner?

    pf

    1. Jul 30, 2011

      Converting to Java source code is, though feasible, really difficult. I would expect a language to gain enough adoption at some point, and be accepted. I guess, it was only COBOL that was considered "enterprise" once, but that had somewhat changed over time...

  30. Jul 29, 2011

    Excellent set of languages features.  Particularly impressed with default non-nullable types, first-class delegation, and allowing arithmetic operator overloading.  Frequently overlooked language features like these plus an awesome IDE provides a compelling alternative to Java, where other JVM languages have come up short.  A few questions:

    • Why not use with implicit interfaces a la Go?  
    • Also, instead of supporting multiple inheritance (with an admittedly decent solution for the diamond problem) why not only support first-class delegation and implicit interfaces?  This provides most of the same functionality without the prone-to-abuse inheritance feature.  Any thoughts on dropping implementation inheritance altogether and just having first-class delegation (taking the best of Go and adding first-class delegation)?
    • Any plans to support immutable classes?  This is a missing feature in many languages and is very helpful for concurrency.
    • Speaking of concurrency, there is an excellent and very fast implementation of Actors on the JVM for Java called Jetlang (it's under the BSD license).  http://code.google.com/p/jetlang/  I saw that Actor-based concurrency was on the wishlist for post-1.0 Kotlin and figured Jetlang would be worth a look as to not reinvent the wheel.
    1. Jul 30, 2011

      Aswering your questions

      1) Structural typing would require dynamic method signature resolution on the JVM. Although it is technically possible (e.g. with the new invokedynamic instruction), the runtime penalty is rather high.
      2) Delegation cannot fully replace inheritance, because when you override some of the delegated methods, the object you delegate to doesn't know about it, and if it internally calls this method, the old implementation gets executed
      3) I think we'll have this as a compiler extension. If you have any particular suggestions, they are very welcome.
      4) Thanks for the suggestion. We'll look into it.

      1. Aug 01, 2011

        re: #3.  Although 'final' is a fine keyword (annotation), I miss dear old 'const'.

        1. Aug 02, 2011

          const is a different thing, and we will probably provide an extension for const support

  31. Aug 02, 2011

    Anonymous

    Are there any plans for Eclipse plugin?

    1. Aug 02, 2011

      We plan to provide two things:
      1) An open source Eclipse plugin that will be initially contributed by JetBrains and later we will gradually move it's support onto the community
      2) API exposed by the compiler, to make it easy to retrieve semantic information from within the plugin

      In any case, Eclipse support will be released later that IntelliJ support.

  32. Aug 03, 2011

    Any thoughts on specifying variable scope by convention like ruby?  Such as CONSTANT_CASE, @instance_variable, etc.?  And/or providing something similar to gofmt to ensure everyone uses the same style/conventions?

    1. Aug 03, 2011

      It's hard to say what a "constant" stands for in Kotlin. And I don't think we will risk to annoy everyone with prefixed member properties.

      1. Aug 04, 2011

        Anonymous

        My experience has been that if you don't, you will annoy everyone by having each person use a DIFFERENT prefixed member property. In the project I work with, due to various libraries we use as well as different people's coding styles, I see various fields named as:

             fSomething

            _something

            m_Something

            this.something

        It is really annoying to see a single source file that ends up using three or more different conventions like this (it extends a class using one convention, but then the developer who created it used another, and the project who is now maintaining it uses another).

        I don't really care what convention is used to distinguish fields from class member variables, but I would really like the language to specify one so that I don't have to deal with the, er, "creativity" of my coworkers in their field naming choices. I think that this is something Ruby did well (using an @ to prefix field references). I'd like to see other languages follow this. (Personally, I prefer a leading underscore, but I would follow any standard that existed rather than trying to fight it.) The common place this is needed is in constructors, getters, and setters. Note that using a field naming prefix is often a defensive tactic: Note that, for instance:

        class Foo { 
         
         int absquatulation; 
         
         
         Foo(Something absqatulation) { 
         
         this.absquatulation = absquatulation; 
         
         
        } 
         
         
        }

        Due to a typo, the above contains a semantic error that the compiler will not catch. If the code had been written like this, however:

        class Foo { 
         
         int _absquatulation; 
         
         Foo(Something absqatulation) { 
         
         _absquatulation = absquatulation; 
         
         } 
         
        }

        the compiler would have correctly reported an error that there was no such variable as "absquatulation" in scope. Therefore, the prefixes do actually serve a useful value. However, having them all be different does not.

        Prohibiting self-assignment ("x=x") would be nice too.

        As far as constants, normally in the C/C++/Java family of language, UPPER_CASE is used for compile-time constants (public static final variables whose value can be known at compile time). This is one of the few formatting issues that almost all developers that I have seen agree on. I think this is a good idea, and I'd like to see the language encourage it.

        Please take some time to figure out a good, consistent way to format files, and it would be even better if the language encouraged or required it in many cases. Having everybody argue (forever!) about where to put the curly braces, and when, and if, is just a huge waste of time and a barrier to usability. (I've also seen code that has three different curly brace placement styles within the same file.)

        Also, I'd like to see mandatory curly braces around blocks. If a language requires this (like Perl, for instance) it can really reduce coding errors due to, for instance, the "dangling else" problem, or misplaced semicolons, in complicated structures.

        1. Aug 04, 2011

          Anonymous

          Argh. The wiki's tedency to treat curly braces as the start of a macro can get annoying at times. Please fix the "Unknown macro:" in the above.

        2. Aug 04, 2011

          Got your point. Thanks

  33. Aug 04, 2011

    Anonymous

    Any comparisons to IBM's X10 language? The syntax seems similar.

    http://x10-lang.org/home.html

      1. Aug 04, 2011

        Thanks, Kotlin has annotations for most of the AST nodes too (including expressions)

    1. Aug 04, 2011

      Thanks for the link. From the first sight the main difference is simply very different goals.

  34. Aug 21, 2011

    Andrey,

    First of all i want to say thanks for all that you in particular and Kotlin team in general are doing. I really liked Kotlin. It's the first language i liked after i discovered Java to myself. And i think Kotlin has great future.

    I want to share this idea with you, it's not directly language-related.
    Are you allowing yourself to make a first test release of Kotlin and to experiment with it without having a constraint of backward compatibility for some time? If we'll look at good practical programming languages, that were becoming a tools for massive industrial software development we'll see that they were made after some experimenting.

    Before Java was released in 1995 it was called Oak from 1992 to 1995. It was a period of intense experimenting and testing of concepts. And even more: before that it took Gosling, Naughton, Warth, Frank and Sheridan 18 month to make first version of Oak to release it in 1992. The result is that Gosling himself calls Java a masterpiece (while creator is rarely being satisfied with his work) and from 1995 till today Java evolves cleanly and continues to drive innovation.

    It took Denis Ritchie some experiments with B in collaboration with Ken Thompson and close look to BCPL before he made C in collaboration with Brian Kernighan.

    Are you planning some evaluation period for Kotlin before setting first "hard" release with responsibility to hold backward compatibility?

    Thanks and Good Luck.

    1. Aug 21, 2011

      Yaromir,

      Thank you for your kind words.

      We are certainly planning some evaluation period before we release Kotlin and fix the spec. It will be internal evaluation by JetBrains team, as well as a publicly available compiler with no guarantees for compatibility. We are looking forward to all the feedback we can possibly collect and take into account.

      Thanks again.

  35. Aug 31, 2011

    One more question.

    I know it's too early to talk about this, but how do you plan to standardise Kotlin?
    I tried to study 3 cases:
    ISO working on C++
        Release of C+11 took 8 years after C+03 was released. Was there just some technical difficulties which took time to solve or their approach is obsolete?

    Java Community Process
        There was rather rapid evolution. One of the components of Java's success is that Java continuously accepts novation and, moreover, it creates novation by itself.

    WHATWG vs W3C working on html5
        Initially, they planned to defer the release of final spec until 2012 and there were more and more ideas to implement which, by the Ian Hickson's words could drag out the release till 2022. It ended up that they decided to move to iterative approach: rolling updates with snapshots.

    This brings me to the thought that "release-to-release" approach is really obsolete and a kind of rolling updates procedure can solve modern-world challenges. But i'm not quite sure about correctness of this conclusion. To further investigate this we need to compare organisational models and procedures in all 3 cases, which is hard work that will take a lot of time.

    Hope this was some help.

    Good luck in your hard challenge developing Kotlin.

    1. Aug 31, 2011

      It's likely to be an issue of a rather distant future, but you are right, the issue is there, and when we get to it, we'll have to think hard ) Thanks for your comment.

  36. Sep 05, 2011

    Anonymous

    "The main design goals behind this project are...": What about Kotlin having a execution speed similar to that of Java? So: compiles fast and runs fast...

    1. Sep 05, 2011

      Goes without saying

  37. Oct 04, 2011

    Anonymous

    Kotlin looks great, you might really fit in the Groovy/Scala gap.

    What will be the "preferred" way of supporting DSLs? In Groovy, it is quite easy to construct DSLs, it should be easy in Scala as well (haven't tried it yet).

    However, to me the easiest (though not cleanest) way is GEP 3 in Groovy:

    http://docs.codehaus.org/display/GroovyJSR/GEP+3+-+Command+Expression+based+DSL

    This could work in a statically typed language as well, couldn't it? Any plans to support DSL creation similar to this approach?

    1. Oct 04, 2011

      Check out this section: Type-safe Groovy-style builders

      1. Oct 04, 2011

        Anonymous

        yes, this is pretty cool, however GEP 3 goes even further, because you don't have to use (curly) braces, dots or whatever.

        This makes the creation of DSLs a breeze. With builders, you would have to use at least braces, which IMO makes it more difficult for non-technical people to use it.

        Or is it possible to do this in a similar way in Kotlin and I just don't get it? 

        What I mean is a syntax like this:

        read file "data.csv" and store data in database

        read file "data.csv" and evaluate month september, 2011

        This can easily be done with GEP 3, where there is a certain convertion what call is converted to method arguments, method calls, etc.

        1. Oct 04, 2011

          This kind of syntax is not impossible but can cause some confusion (plus it conflicts with our current annotation syntax, which is a minor issue). We'll think about it.

          By the way, I don't believe that any people for whom curly braces are a big deal can do any meaningful DSL coding whether in Groovy or in Kotlin, because if they make mistake, and the compiler throws an error at them, they wouldn't know what to do.

          1. Oct 07, 2011

            Anonymous

            BTW I just saw that you wrote a blog post about this topic here: http://blog.jetbrains.com/kotlin/2011/10/dsls-in-kotlin-part-1-whats-in-the-toolbox-builders/

            So to me a combination of extension functions and infix calls (and builders) seems to be a good way of creating DSLs in Kotlin.

            Not as easy as "Command Expression based DSL" in Groovy, but statically typed and with IDE support (I suppose)

            which does more than compensate the slightly more complicated syntax.

  38. Oct 05, 2011

    Anonymous

    Do you plan to do a PLEAC (http://pleac.sourceforge.net/) for Kotlin? This could leverage acceptance a lot.

    1. Oct 05, 2011

      Good idea! We'll definitely do it. Thanks.

  39. Oct 07, 2011

    Anonymous

    Some words on the Kotlin runtime library: There may be situations (I recently encountered one) where I can only ship one single jar file which should be able to work with a standard JRE without any additions (no classpath etc.). I this case I would include the sources of the Kotlin runtime into my jar. This is only reasonable if:

    • The Kotlin runtime is small.
    • Code relying on separate Kotlin runtimes can still interact "in a Kotlin way".
    • The license allows the embedding of the Kotlin runtime sources into commercial code.

    What do ou think? Is this a sensible way to go?

    1. Oct 07, 2011

      Anonymous

      ...and maybe support this in the IDE: output a jar with the Kotlin code included?

      1. Oct 07, 2011

        Anonymous

        i.e.: ...Kotlin runtime included.

    2. Oct 07, 2011

      • The Kotlin runtime is small.
        • You don't even have to include all of the Kotlin runtime. The mandatory part of the Kotlin runtime is small. All the rest you can leave out if you don't use it.
      • Code relying on separate Kotlin runtimes can still interact "in a Kotlin way".
        • Kotlin runtime is a bunch of classes. On the JVM, same classes become distinct when loaded by different class loaders, so there's not way to pass objects between instances of the same library loaded independently, no matter what library it is: a Kotlin runtime or whatever. So, if you want to pass function objects or tuples between different parts of your system that do not share the same Kotlin runtime library, this will not work. Same for reified generics. On the bright side: everything else will work.
      • The license allows the embedding of the Kotlin runtime sources into commercial code.
        • Totally yes. The license will be Apache 2
  40. Oct 15, 2011

    Anonymous

    Has any thought been given to transpiling Kotlin to JavaScript? There
    was a suggestion in this post http://www.infoq.com/news/2011/07/kotlin
    but I have not seen any other mention of a JavaScript target.

    What a pity Google didn't adopt Kotlin instead of Dart.

    1. Oct 15, 2011

      We are planning to support a JavaScript target one day, but currently it is not a top priority.

  41. Nov 22, 2011

    Anonymous

    Just for interest, what will be the extension for Kotlin source files? I'd object the most obvious *.kot extension, because it means "shit" in German. Just for you to know. Germans would appreciate using *.ktl or something similar a lot :)

    1. Nov 22, 2011

      Don't worry, we use *.kt

  42. Nov 22, 2011

    Anonymous

    Maybe it's too early to think about infrastructure around Kotlin, but i have some thoughts about unit testing in Kotlin i wanted to share.

    Is it possible to make single framework to avoid diversity of unit testing tools? And should this diversity be avoided at all?

    On one hand, if multiple unit testing frameworks appear, this means there is a necessity in them.
    On other hand for particular project we have problem not even of many unit tests depending on many frameworks by itself rather than a problem that the newbie quality engineer have to learn all of the frameworks. This takes time and adds barriers to involving new engineers to the project.

    D has an interesting feature - it has "unittest" keyword, but i don't like this solution and i can't explain why. I'm also interested in hardware development and i was pretty surprised when i saw a "testbench" keyword in Verilog. So we can see some cases when the same pattern of implementing testing capabilities on the language level rather that with frameworks is used both in software and hardware engineering.
    Of course, unit tests are not exactly the same thing as testbenches for hardware, but this two cases give something to think about.

    Or maybe it isn't worth thinking and we should just reuse Java UnitTesting frameworks within Kotlin interface to Java?

    What do you think about "keyword vs framework"?
    And, in general, what, by your opinion, should be added to language and what should be implemented as libraries and frameworks? JetBrains has a lot of experience in creating DSLs so i think you know this better.

    P.S. This is Yaromir, i forgot my password. :)

    1. Nov 22, 2011

      Right now the plan is to provide a test framework for Kotlin as part of the standard library. Extension functions and closures make it possible to create a much nicer looking framework than good old JUnit, and we're going to make use of that. Obviously, writing tests in Kotlin using JUnit or TestNG will also be possible.

      We don't have any goal of avoiding the diversity of testing frameworks. If people want to explore different approaches to testing using Kotlin, that's just great from our point of view.

      As for language support for testing, we don't currently see any compelling need for that. Even if it turns out to be useful later, it's much more likely to be implemented as a compiler plugin and not as a core language feature.

      1. Feb 15, 2012

        Hi Dmitry,

        Any news on unit testing?  Support in IDEA would be great.

        1. Feb 16, 2012

          We are working on it right now

  43. Nov 24, 2011

    Anonymous

    Are we gonna get an early Christmas present of an Alpha release of Kotlin?

    1. Nov 24, 2011

      We'll keep it a surprise, anyway

  44. Nov 24, 2011

    Anonymous

    I appreciate your work, but... there are a plenty of languages that share the same ideas of Java and C# only varying a little their syntax and introducing a lot of sugar. Fantom, Ceylon, Groovy++, Vala, Xtend, Nemerle, Boo, Mirah, etc (over 9000)...

    Kotlin is fully inspired of Scala and designed to be fully integrated with Java. But if it pretends to be a really useful language it must be cross-platform. So compiling for JVM, CLR, Android, JavaScript and using platform-independent API layer would be very nice. Another useful thing I see is cross-compiling Kotlin code to .java for GWT integration.

    1. Nov 24, 2011

      All I can say for now is that we are working on compilers for some of the platforms you mentioned.

    2. Nov 24, 2011

      Anonymous - that's a huge wish list.

      I think Kotlin can be useful without addressing all of your requirements.

      Do you want twenty mediocre capabilities or 5 great ones?

      I hope that JetBrains takes things one step at a time and gets the language and core libraries right first.

        

  45. Dec 01, 2011

    Anonymous

    Добрый день!

    Вопрос автору языка: Вы не намерены сделать русскую версию языка, которая позволила бы программировать, не прибегая к латинице? 

    1. Dec 01, 2011

      Добрый день.

      Нет, таких планов у нас нет, но любой желающий сможет это сделать, когда код проекта будет опубликован (это случится довольно скоро).

  46. Dec 15, 2011

    Anonymous

    A language succeed by hitting its opportunity, Objective-C is the one, Scala have akka to bet, and what to kotlin?

    I ever used c, python, ruby, groovy, scala, java, Personally I like kotlin very much and have firm believe by trust jetbrains.

    Since java indicates less features, good for large amount developers in `labor intensive industry`, while several other languages try to serve brilliant ones. They are quite different.

    Scala is believed to be good for library developers, while build an ORM library(EBean - java, Squeryl..) or MVC framework(Play), they are all using the trick: code generation, or cglib-like staffs(maybe even struggle with classloaders).

    What a pity!

    If kotlin have restricted `macro`, that will be a huge feature to library developers.

    cheers

    - liusong1111

    1. Dec 15, 2011

      We are considering something like this for future versions

  47. Dec 26, 2011

    I'm a big Groovy fan and IntelliJ IDEA Ultimate REALLY makes Groovy/Grails development even more pleasing.  I REALLY looking forward to playing with Kotlin.  I intend to be an early adopter.  Is there anything a mere mortal such as I can do to help?

    Thanks again guys for creating such a great IDE.  My team is the first in my company to switch from Eclipse and we are slowly gaining new advocates.  You guys really care about software.  Keep up the good work!

  48. Jan 11, 2012

    I have a couple of random questions

    1) Is there any plan to include list comprehensions?  I find myself using them a lot in Clojure.  I think they are often a lot more readable than the equivalent higher order functions.

    2) If a class's properties are all vals will the compiler generate sensible default implementations of toString, hashCode and equals?  Like Scala's case classes and Clojure's records.

    1. Jan 11, 2012

      1) It depends on how readable our HO functions will actually be. We are currently working on them.
      2) The plan is to have an annotation on a class (like Scala's 'case') that makes the compiler do so.

  49. Jan 24, 2012

    Edited: Found the answer to my async/await question, but can't delete post. As with everything else I really like your pragmatic approach, and look forward to working with Kotlin. 

  50. Jan 31, 2012

    It will be possible to attach custom attributes to a property?

    In particular I'm thinking on a label or description to be shown in tooltips and forms

    1. Jan 31, 2012

      Sure you can attach annotations to a property, although I wouldn't recommend to put UI stuff into the model code.

  51. Feb 03, 2012

    hallo,

    is there any timeline for a public release of Kotlin (alpha,beta,...).

    1. Feb 03, 2012

      A public preview of the IDE and the compiler will be out in February.

  52. Feb 03, 2012

    thanks

  53. Feb 22, 2012

    Just a rant: I've read that to-JavaScript transcription isn't a prio yet — understandable considering the current dev state of Kotlin.

    You know that G is working on Dart which is just a better GWT, that is, Googlers will focus on creating a badass Dart-to-JavaScript transcriptor. Wouldn't it be better — instead of creating an own to-JS transcriptor — to transcript Kotlin to Dart and let Google's Dart-to-JavaScript transcriptor do the badass optimizations for you? Dart will be definitely syntactically & semantically closer to Kotlin than JavaScript can possibly be, also Dart is just like Kotlin (kinda [optionally]...) type-safe language, so is Kotlin.

    1. Feb 22, 2012

      We reuse the back-end G uses for GWT and Dart. Translating Kotlin to another unstable language seems to be pushing "unstability" further than we are ready to push it

      1. Feb 23, 2012

        Nice to hear that! My proposal wasn't so much about using Dart as an intermediate language but re-using what GWT already created and what Dart is creating and will create. Also I'd never recommend to use anything from Dart in the current dev phase.

  54. Mar 16, 2012

    Congratulations for getting Kotlin out! I like the language: very much in the spirit of Scala, but without all that too many language features that cause the language to get scattered. Is there a language guide as a PDF or as a single page html? Then I could easier play a bit with Kotlin when being on the train to work.

    Regards, Oliver

    1. Mar 16, 2012

      Hi,

      The best I can offer for now is this: http://dl.dropbox.com/u/31618705/kotlin-confluence-2012--03-16.zip
      A zipped collection of HTML pages. Viewable offline. I hope it helps.

    1. Jul 11, 2012

      Does it give you an error message?

      1. Jul 11, 2012

        No. Just artifacts list of the repository is empty.

        If click "Check now" on the "Edit repository" window shows messgebox with "Plugin descriptions contain some errors. Please, check idea.log for details."
        But idea.log does not contain information about it.

        Second xml-file contains wrong url (http://teamcity.jetbrains.com/repository/download/bt354/lastSuccessful/updatePlugins.xml)
        but i don't understand what is wrong at http://teamcity.jetbrains.com/repository/download/bt345/lastSuccessful/updatePlugins.xml

      1. Jul 11, 2012

        Thanks. The problem was in the authentication.

        >Where did you get those urls?
        I took the urls from TeamCity.

  55. Aug 16, 2012

    Some ideas for you from a guy in Oz with a passion for software engineering principles and quality...

    1) Take inspiration from Eiffel. Null safety is just the start (void-safety in Eiffel).
    Eiffel is the best designed language in the world and the JVM platform is most practical commercially.
    A merger of the two would be ideal. Kotlin comes closer than any language so far... keep going.

    2) The world needs design by contract(DbC). Use the full semantic model that Eiffel has proven - don't water it down as so many Java contract frameworks do. Make sure the contract assertions allow a label and/or free text names. Also implement a "contract view" of classes as documentation for the user of a framework (i.e. only the contracts of methods are shown, implementations are stripped out).

    3) Propose a clean subset of Kotlin as the new base language for MPS(its on their roadmap for 2013/4). This way Kotlin language extensions and DSLs will be done the way they should be: Opt-in and able to integrate with a wide variety of language extensions and DSLs because one company can't anticipate everyone's needs. Kotlin can be the foundation of the coming LOP revolution.

    4) Implement Simple Concurrent Object Oriented Programming (SCOOP) for Kotlin. It shares the same philosophy as Kotlin: Simplicity and ease for the engineer. Just like null safety it is added into the type system and in the case of SCOOP only a single additional reserved word is introduced to the syntax: separate. There is a good paper here on how implement SCOOP for Java: http://www.cs.utoronto.ca/~faraz/papers/cpa09.pdf

    5) Add opt-in Command-Query separation. i.e. functions that return a value should have no side effects. To remain compatible with Java semantics you need a mixed command/query methods. Consider adding two more method descriptors : "procedure" (void method with side effects) and "function" (method with no side effects returning a value or tuple) in addition to "fun".
    btw: I don't like abbreviations like "fun" and therefore "proc" and "func" are equally disliked - good language design should be human readable. Don't sacrifice readability for a little conciseness that actually obscures.

    6) Make Kotlin for AppCode a higher priority (i.e. LLVM, Cocoa etc). Kotlin could be a killer cross-platform development tool for core libraries.

    Thats enough for the moment.

    1. Aug 16, 2012

      Thanks for the feedback and the encouraging words!

      1. Aug 16, 2012

        No worries mate!

        Thinking further on DbC...

        Don't use annotations - Ughhh. Many contract frameworks tack it on and the expressions are all enclosed in a string which prevents syntax highlighting, refactoring, type checking etc DdC needs to be built into the language itself and so IDEA can work with it in the AST.

        Don't forget "check" assertions - they are also useful in addition to require, ensure and invariant.

        I was thinking along the lines of :

        (This is very close to how I implemented a simple DbC framework in groovy many years ago)

        This is not exactly following Eiffel, I have made the following improvements:

        1) Mandatory labels
        These are important as its good to have a human readable version of the assertion because:
        a) It aids the USER of a framework in understanding how to use it.
        b) It helps diagnose bugs when the label is added to a contract violaton exception then logged or alerted to the developer.

        2) Contract violation messages
        Added into the exception, these give more details about the offending values to help track bugs faster.

        3) Ordering is significant
        The second requirement is dependent on the first. i.e. if the first is violated the second is not relevent. This saves duplicating the first assertion in the second just to avoid multiple violations.

        4) Allow some variable initialisation code prior to requirement assertion in a method.

        On the topic of multiple violations perhaps there is an opportunity here to allow multiple violations and define the dependencies e.g.:

        In the case above the last two requirements could both be violated giving the developer more information up front.
        This means adding more than one contract violation to a single exception - perhaps this is too complex.

        OK enough.

        I am currently doing grails development for a startup and hope to convince the CEO to start phasing in Kotlin - wish me luck!

        If I succeed the first item on my agenda will be DbC so perhaps I can contribute at some point.

        PS: Is this the right forum to discuss language design? Is there a better place?

        Cheers

        1. Aug 16, 2012

          The real forum is here

          1. Aug 16, 2012

            Done. Posted in the Kontributors forum