This page is no longer maintained — Please continue to the home page at www.scala-lang.org

new language "Kotlin" from jetbrains

118 replies
jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

On Fri, Jul 22, 2011 at 5:27 AM, Philippe Lhoste wrote:
> From a quick look at the site, it looks like the language specification
> isn't set in stone, yet... Like Ceylon, there is no (publicly available)
> compiler yet.
>
> I believe they missed an opportunity to distinguish more from
> Scala/Java/other concurrents, to support metaprogramming, via type-safe and
> scope-safe macros.
> I found the idea made elegantly in Nemerle (I don't know enough Lisp to
> comment on it, but I believe it is the same idea).

a) A problem with making "less complex" a selling point for your
language is that it makes it difficult to improve your design by
incorporating good ideas, no matter how good they are.

b) When your priority is integration of your language with an IDE,
macros are probably the last feature you would be willing to consider.

c) Borrowing Nemerle's macros wouldn't distinguish it from "other
concurrents" since Nemerle is one.

I actually think that this proliferation of Scala look-almost-alikes
is a good thing, largely because it increases the visibility of Scala
and highlights its excellence ... imitation is the sincerest form of
flattery, as they say. And I think these languages that miss the point
of Scala's "complex" features will suffer for it and will further
illustrate the point. And it may also work the other way around ...
these languages may serve as proving grounds for ideas that may later
make their way into Scala.

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On 22/07/2011 23:17, Jim Balter wrote:
> a) A problem with making "less complex" a selling point for your
> language is that it makes it difficult to improve your design by
> incorporating good ideas, no matter how good they are.

Indeed, and since "complex" features are not built/integrated in the
design from the start, it is even complexer! See Java generics...

> b) When your priority is integration of your language with an IDE,
> macros are probably the last feature you would be willing to consider.

Not sure about this one, but I won't argue, as I have experience in IDE
design...

> c) Borrowing Nemerle's macros wouldn't distinguish it from "other
> concurrents" since Nemerle is one.

It isn't a direct concurrent, at least, as it is a .NET language, not a
JVM one.

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: new language "Kotlin" from jetbrains

On Tuesday 19 July 2011, Francois Armand wrote:
> Le 20/07/2011 04:38, Cédric Beust ♔ a écrit :
> > On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli
> >
> [...]
>
> > "A few different features" is what makes or breaks a language from
> > a mainstream adoption perspective. You don't know which ones will
> > work until you really try.
>
> And I would add that the theory beside Scala and Kotlin is quite
> different, and so it does not seems to be like "a few different
> features", but much more like "some core fundation features are
> different"

What is the theory upon which Kotlin is based?

Randall Schulz

nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...
I'm surprised they'd allow such a significant comparative drawback for their language.
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com

phlegmaticprogrammer
Joined: 2010-07-23,
User offline. Last seen 2 years 15 weeks ago.
Re: new language "Kotlin" from jetbrains
Well, if you start developing something that looks so much like Scala without any real differentiation... probably not all of your design decisions will be that great.
- Steven
On 24.07.2011, at 00:13, Nikita Ivanov wrote:
After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...
I'm surprised they'd allow such a significant comparative drawback for their language.
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com


jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov wrote:
> After looking at Kotlin's extension functions in details I think it is a
> major blunder comparing to implicits in Scala. They may be easier to handle
> in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but
> there's no way I can do away without ability to convert one type to another
> at least here in GridGain's code.
> Just adding a function to another type (primitive "pimping") is just one
> specific application of implicits - and it seems that kotlin team wrongly
> assumed that that's the only one at all...
> I'm surprised they'd allow such a significant comparative drawback for their
> language.

If they eliminated all such significant comparative drawbacks relative
to Scala, it's hard to see what technical (vs. marketing) motivation
for a new language would be left.

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains


On Sat, Jul 23, 2011 at 6:03 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:


What is the theory upon which Kotlin is based?


The theory of evolution?
 
Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...

Fair enough, but you need to realize that implicits come with their own baggage as well. Just today, somebody on #scala was having a problem because he was not importing a particular implicit.
Think about that for a second: the code was compiling and running fine, but it was not giving the expected result. Importing the correct implicit fixed the problem.
Anyone sufficiently experienced with Scala will probably get a gut feeling that might push them in the right direction to solve this kind of bug, but the simple fact that an import can fundamentally modify the behavior of a program is quite new for anyone familiar with Java.
-- Cédric
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
I'm curious what the missing implicit was.

2011/7/24 Cédric Beust ♔ <cedric [at] beust [dot] com>
On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...

Fair enough, but you need to realize that implicits come with their own baggage as well. Just today, somebody on #scala was having a problem because he was not importing a particular implicit.
Think about that for a second: the code was compiling and running fine, but it was not giving the expected result. Importing the correct implicit fixed the problem.
Anyone sufficiently experienced with Scala will probably get a gut feeling that might push them in the right direction to solve this kind of bug, but the simple fact that an import can fundamentally modify the behavior of a program is quite new for anyone familiar with Java.
-- Cédric

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
I forget the details but it was about a JDBC driver.
-- Cédric




2011/7/23 Naftoli Gugenheim <naftoligug [at] gmail [dot] com>
I'm curious what the missing implicit was.

2011/7/24 Cédric Beust ♔ <cedric [at] beust [dot] com>
On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...

Fair enough, but you need to realize that implicits come with their own baggage as well. Just today, somebody on #scala was having a problem because he was not importing a particular implicit.
Think about that for a second: the code was compiling and running fine, but it was not giving the expected result. Importing the correct implicit fixed the problem.
Anyone sufficiently experienced with Scala will probably get a gut feeling that might push them in the right direction to solve this kind of bug, but the simple fact that an import can fundamentally modify the behavior of a program is quite new for anyone familiar with Java.
-- Cédric


nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
Agree. Smarter compiler (better warnings + tooling) is necessary to make the learning of implicits easier. 
Another observation is that implicits are *extremely* centric for almost anything in Scala. It is, without a doubt, is one of the key features of the language (just try to find places where it's not used in core libs...).
Yet - Kotlin dismisses it as a thoughtless over-complication and picks one use case to base their feature on. I understand, of course, that Korlin and Scala are different animals - but that's one feature and Kotlin's reasoning that rubs me the wrong way... --Nikita Ivanov, CEOGridGain Systemswww.gridgain.com



2011/7/23 Cédric Beust ♔ <cedric [at] beust [dot] com>
On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...

Fair enough, but you need to realize that implicits come with their own baggage as well. Just today, somebody on #scala was having a problem because he was not importing a particular implicit.
Think about that for a second: the code was compiling and running fine, but it was not giving the expected result. Importing the correct implicit fixed the problem.
Anyone sufficiently experienced with Scala will probably get a gut feeling that might push them in the right direction to solve this kind of bug, but the simple fact that an import can fundamentally modify the behavior of a program is quite new for anyone familiar with Java.
-- Cédric

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: new language "Kotlin" from jetbrains
OK, for a non-strictly entertaining post to this thread.
Kotlin, so what?
Let's face it, Scala is provocative, perhaps more-so than most other languages on the JVM.  Many folks are going to react to Scala, some of them are going to go off and design a new language as a result.  This simply is going to happen.  There really is nothing that can be done about that, certainly Kotlin will not be the last language developed in response to Scala.  From a competitive stand-point many valid points have been raised on this list and in other forums.  We are at a strange cross-roads in the development of Scala: it is garnering enough attention to motivate the designers/stewards (Martin et al./Typesafe) to dial-up the "stability" knob at the same time that the language is sowing the seeds of its own competition.  For me, I side with the view that Scala needs to remain agile and responsive to up-start threats at the expense of "stability", however, perhaps the exact right choice to sustain Scala's adoption is to become more "stable".  I don't know what the best choice is.
RE: the sub-thread on Scala as "complex" - I think that a number of valid points have been made in this regard.  For me the word "complex" doesn't quite capture the issue.  I think that Scala is both a rich and deep language.  Sufficiently so that it is possible to express solutions to problems in Scala in ways that can appear extremely foreign to programmers familiar with most popular languages (I view this as a strength of Scala, not something to be seriously worried about).  That said, it is also a straight-forward exercise to propagate common idioms found in other languages, particularly Java. Further, I think the "complexity" story is not entirely contained in the language itself, it is a combination of the language and its "social ecosystem".  People coming to Scala are not simply going to go to scala-lang.org as the be-all and end-all of information on the language and the "best-practices" on how to apply the facilities of it.  There are numerous blog-posts, papers, mailing-list posts, and stack-overflow articles covering a wide-range of approaches and techniques for applying Scala to problems in some very non-obvious ways.  By "non-obvious" I'm referring to approaches that seemingly do not follow from the prior experience of the average programmer.  It's no secret that perhaps the most glaring example of this "alien technology" is the Scalaz library[1], but it certainly isn't limited to it. (As further example take a look at all the blog posts covering various type-level programming tricks.)  The knee-jerk reaction to all this is probably going to be describing Scala as "complex" because the seeming "mastery" of Scala requires I learn about things I may never have even heard the names of before taking on Scala.  The reality is that this situation is a tribute to Scala richness: you can take Scala pretty damned far in just about any direction you choose.
RE: Claims that Scala FP support is "standard fare" - While this claim is substantially true, the story isn't really finished, especially when it comes to type inference.   It's common knowledge to folks on the various Scala mailing lists that the Scala type inferencer is rather sophisticated but still a work in progress.  The fact that articles like this one (and the fantastic discussion it produced): http://pchiusano.blogspot.com/2011/05/making-most-of-scalas-extremely-limited.html exist at all adds to the perceived "complexity" of the language: not only do I have to learn Scala's type-system, but I'm likely going to have to become fluent in where the type infrencer seems to break down (perhaps for very good reasons, but honestly look at the discussion following the article from Martin, Daniel, and Paul and realize that almost all of it is gobbledygook to the uninitiated).  This includes eventually confronting the need to learn apparent arcana like "type-lambdas".  This stuff is only easy after it was hard.  Some will bet that the payoff isn't worth the effort.
RE: Macros - yeah, I want them in Scala.  More attractive than writing compiler plugins.
RE: Buying JetBrains - yes, it was said in jest with the hopes that folks would get a chuckle out of such an audacious statement.
RE: "Programming is hard" - No it's not, oh wait ... yeah, it is.
That's enough pablum for now.  Need sleep. 
--
Jim Powers
[1] It will be interesting to see if Scalaz can be implemented as succinctly (or at all) using Kotlin as it can be in Scala.  If it can perhaps there are lessons to be learned for Scala.
Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains

On Sun, Jul 24, 2011 at 12:13 AM, Nikita Ivanov wrote:
> After looking at Kotlin's extension functions in details I think it is a
> major blunder comparing to implicits in Scala. They may be easier to handle
> in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but
> there's no way I can do away without ability to convert one type to another
> at least here in GridGain's code.
> Just adding a function to another type (primitive "pimping") is just one
> specific application of implicits - and it seems that kotlin team wrongly
> assumed that that's the only one at all...
> I'm surprised they'd allow such a significant comparative drawback for their
> language.

The architecture of IDEA actually isn't that well suited to implicits.
You can't perform a global find-usages on one yet. Find usages
underpins many refactorings.

Normally this operation is pretty fast by starting with a text based
search to find all potential call sites; the typing them (using
cached) to see if they actually refer to the target method. However,
the method name does not appear at the call site when using implicit
views (same story for implicit parameters, apply/update methods,
for-comprehensions), so the AST of the entire program must be re-typed
and comprehensively searched. (This isn't implemented in the Scala
Plugin yet, and will be slow.) That limits the ability of the IDE to
scale up to large projects.

Kotlin omits features that are troublesome to the IDE. It's not a
stated goal of the language, but given JetBrain's pedigree its fair to
assume that this (and fast compilation) is as important to them as
presenting a simple language to users. This isn't a criticism: I think
there is a valid trade-off between expressivity of the language and
quality of tools.

-jason

Jesper Nordenberg
Joined: 2008-12-27,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

Jason Zaugg skrev 2011-07-24 09:45:
> Kotlin omits features that are troublesome to the IDE. It's not a
> stated goal of the language, but given JetBrain's pedigree its fair to
> assume that this (and fast compilation) is as important to them as
> presenting a simple language to users. This isn't a criticism: I think
> there is a valid trade-off between expressivity of the language and
> quality of tools.

I'm highly sceptical of any language designed for a specific tool
(especially limitations of a specific tool). IMHO, language should be
tool independent.

/Jesper Nordenberg

Stefan Zeiger
Joined: 2008-12-21,
User offline. Last seen 27 weeks 3 days ago.
Re: new language "Kotlin" from jetbrains

On 2011-07-24 06:33, Naftoli Gugenheim wrote:
> I'm curious what the missing implicit was.

It was a wrong implicit rather than a missing one. He wanted to use
ScalaQuery with MySQL and was using a wrong driver. The driver itself
and some implicit conversions (which can be specialized by the drivers)
need to be imported. For MySQL this would be:

import org.scalaquery.ql.extended.MySQLDriver.Implicit._

Your code will not compile without those imports. But if you import a
different driver, you will, of course, get the wrong SQL code for your
database.

-sz

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Ah, that makes a lot more sense. Usually leaving out an implicit won't allow the code to compile.

On Sun, Jul 24, 2011 at 11:45 AM, Stefan Zeiger <szeiger [at] novocode [dot] com> wrote:
On 2011-07-24 06:33, Naftoli Gugenheim wrote:
I'm curious what the missing implicit was.

It was a wrong implicit rather than a missing one. He wanted to use ScalaQuery with MySQL and was using a wrong driver. The driver itself and some implicit conversions (which can be specialized by the drivers) need to be imported. For MySQL this would be:

import org.scalaquery.ql.extended.MySQLDriver.Implicit._

Your code will not compile without those imports. But if you import a different driver, you will, of course, get the wrong SQL code for your database.

-sz

soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.
Re: Re: new language "Kotlin" from jetbrains

> I'm highly sceptical of any language designed for a specific tool
> (especially limitations of a specific tool). IMHO, language should be
> tool independent.
Agree. Languages shouldn't be "fun" to implement, they should provide a
tool to solve problems.
And if a certain language features makes it 10% easier to solve
problems, it doesn't matter at all if the compiler developer has to work
twice as hard.
Else ... welcome to the Modula/Oberon world, where things are easy to
implement but suck like a black hole.

Bye,

Simon

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains

2011/7/24 Cédric Beust ♔ :
> On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov wrote:
>>
>> After looking at Kotlin's extension functions in details I think it is a
>> major blunder comparing to implicits in Scala. They may be easier to handle
>> in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but
>> there's no way I can do away without ability to convert one type to another
>> at least here in GridGain's code.
>> Just adding a function to another type (primitive "pimping") is just one
>> specific application of implicits - and it seems that kotlin team wrongly
>> assumed that that's the only one at all...
>
> Fair enough, but you need to realize that implicits come with their own
> baggage as well. Just today, somebody on #scala was having a problem because
> he was not importing a particular implicit.
> Think about that for a second: the code was compiling and running fine, but
> it was not giving the expected result. Importing the correct implicit fixed
> the problem.
> Anyone sufficiently experienced with Scala will probably get a gut feeling
> that might push them in the right direction to solve this kind of bug, but
> the simple fact that an import can fundamentally modify the behavior of a
> program is quite new for anyone familiar with Java.

If there weren't new stuff, it wouldn't be a new language, now would
it? But the fundamental problem here is one that happens in Java as
well.

Basically, if the code compiled but did not work, then the API was
badly designed. Java has plenty examples of badly designed APIs that
cause plenty of grief, without help of any particular feature bringing
huge benefits with it. You can look back to the first versions of Java
and find examples of such.

So, yes, it IS new. People without Scala experience WILL have problems
that are new to them, no matter how much previous experience they had.
But this is like java.util.Date -- though the language did allow such
a thing, the real problem is bad design.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland