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

new language "Kotlin" from jetbrains

118 replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala. I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile. The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise). Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online. 
In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption. 
Best,
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com



On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: new language "Kotlin" from jetbrains
I'll bet you loved this:
There're other "new" languages. Why not them?

In short:

  • Scala is too complex and it's very hard to make a good tooling support for it

--Russ P.


On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.



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

JetBrains knows a little something about that subject, so their
comment shouldn't be taken lightly.

On the broader issue ... designing new programming languages is all
the rage now, with Go, Vala, Rust, BitC, Closure, Plaid, Agda, Coq,
Nemerle, Kotlin ... some of the reasons for doing so are better than
others, but in any case it's going to continue. Hopefully lessons will
be learned from all these efforts.

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

I share the lament.

On 20/07/11 09:29, Paul Phillips wrote:
> Maybe I'm the last guy to hear about things (it happens enough) but
> there's this language here which looks like a more credible effort to be
> a better/simpler scala than most:
>
> http://confluence.jetbrains.net/display/Kotlin/Welcome
>
> The "What Kotlin has that Scala has not" list does read like a list of
> things I would not mind having:
>
> http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
>
> It makes me sad to see another whole implementation's worth of effort
> being poured into something new -- come on guys, you won't be enough
> better than scala. I know everyone wants their own baby, but just
> imagine what we might accomplish if we didn't all keep re-running the
> same opening mile. The scenery up here on mile two, it's nice, you
> should come give it a look.
>
> P.S. First mile is long.

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: new language "Kotlin" from jetbrains
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking). If you just want add and subtract a few features, I would guess that forking could save you one hell of a lot of time compared to starting from scratch. It would also make the language a lot more familiar to current Scala users, thereby encouraging adoption. Who wants to learn a whole new language just for a few different features? But maybe the language differs from Scala more than I realize, since I only briefly skimmed the list of differences.

--Russ P.


On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.



--
http://RussP.us
Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 9:16 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking). If you just want add and subtract a few features, I would guess that forking could save you one hell of a lot of time compared to starting from scratch. It would also make the language a lot more familiar to current Scala users, thereby encouraging adoption. Who wants to learn a whole new language just for a few different features? But maybe the language differs from Scala more than I realize, since I only briefly skimmed the list of differences.

From: http://confluence.jetbrains.net/display/Kotlin/FAQ Does it have IDE support?Yes. The compiler is developed as an IntelliJ IDEA plugin, and user-facing IDE features are there from the very beginning (we make good use of them while debugging and testing). 
I expect that the compiler will be pretty fast, and very much designed for interactive IDE use.
--
Jim Powers
Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: new language "Kotlin" from jetbrains
I think that the only rational response to this challenge is for TypeSafe to announce a new IDE: 'Intelli/S Notion' completely written in Scala.
--
Jim Powers
Srirangan
Joined: 2011-01-22,
User offline. Last seen 12 weeks 1 day ago.
Re: new language "Kotlin" from jetbrains
LOL

On Wed, Jul 20, 2011 at 7:16 AM, Jim Powers <jim [at] casapowers [dot] com> wrote:
I think that the only rational response to this challenge is for TypeSafe to announce a new IDE: 'Intelli/S Notion' completely written in Scala.
--
Jim Powers



--
Srirangan  |  About  Blog  GitHub  LinkedIn  Twitter
nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
I think the tooling support became an intrinsic feature of the language (if not one of the most important one). I won't be surprised to see tooling support be a part of the language specifications in the future. 
JetBrains has an enormous advantage on that (naturally). I think Scala has ~12-18 months before Kotlin hits the 1.0.
--Nikita Ivanov, CEOGridGain Systems www.gridgain.com



On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.

The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

  (2) NotNull support

  (3) Delegation/proxying (without a plugin).

I'm pretty sure I wouldn't miss everything else, although inline string interpretation would be nice without having to go through XML.

Some of the design choices seem downright perplexing if one wants something simpler than Scala.  Having to remember 30 rules to know which method corresponds to which operator?  Extension functions extending anything anywhere?  Pattern matching syntax even more complicated than Scala's?

  --Rex

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 10:11 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
I think the tooling support became an intrinsic feature of the language (if not one of the most important one). I won't be surprised to see tooling support be a part of the language specifications in the future. 

Compiler support for the IDE was a first-class consideration when MS was developing the initial .NET language suite (C#, C++, and VB). I recall reading a blog post (from MS) about how compiler design has been fundamentally changed as a result of taking into account the IDE as the primary consumer of the compiler's functionality.  
JetBrains has an enormous advantage on that (naturally). I think Scala has ~12-18 months before Kotlin hits the 1.0.

Agreed that JB has a massive advantage in the IDE arena, but getting to a 1.0 for a new language is still pretty far from attaining wide-spread adoption, Scala is not Kotlin's only competitor.  -- Jim Powers
Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On 20/07/11 12:16, Rex Kerr wrote:
> (2) NotNull support
This is a step backwards.

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 4:53 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise).

You think so? Well, let's see the quote again:
"Scala is too complex and it's very hard to make a good tooling support for it"
Now, what could possibly make you think they actually meant Groovy?
It's simple, really. Martin is the first to admit that tooling for Scala (especially IDE support) is hard, and he's throwing resources at the problem. Now you have IDEA, the creators of one of the most popular IDE's today, say the same thing, and you still choose to ignore it.
What will it take?
Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online. 

I don't find it sad, I'm pretty excited. Every language brings its own contribution to the edifice, be it small or big. I'm looking forward to seeing what an IDE company can come up with.  
In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption. 

Violent agreement here.
-- Cédric
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 10:17 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
On 20/07/11 12:16, Rex Kerr wrote:
> (2) NotNull support
This is a step backwards.

It's a step sideways.  If you have to put up with null anyway, which we do with Java interop, and that will last until all Java libraries of great utility have Scala wrappers, then it's nice to have the compiler help you check when things might be null and might not.  Any time the compiler can tell me when my assumptions are wrong, I count it as a step forward.

Of course, this can lead to the increased use of nulls instead of more powerful concepts, which would be a step backwards.

  --Rex

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking).

Besides the the license concern, isn't it obvious? Writing programming languages is fun, and if you are an IDE company, it's a no-brainer to create a language from scratch so that the language and the tools can move forward in lockstep.
 
Who wants to learn a whole new language just for a few different features?

"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.
--  Cédric
jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On Tue, Jul 19, 2011 at 7:26 PM, Rex Kerr wrote:
> On Tue, Jul 19, 2011 at 10:17 PM, Tony Morris wrote:
>>
>> On 20/07/11 12:16, Rex Kerr wrote:
>> > (2) NotNull support
>> This is a step backwards.
>
> It's a step sideways.  If you have to put up with null anyway, which we do
> with Java interop, and that will last until all Java libraries of great
> utility have Scala wrappers, then it's nice to have the compiler help you
> check when things might be null and might not.  Any time the compiler can
> tell me when my assumptions are wrong, I count it as a step forward.
>
> Of course, this can lead to the increased use of nulls instead of more
> powerful concepts, which would be a step backwards.
>
>   --Rex

NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ... although I do
see the point about the psychology that, since '?' is a language
feature, you're expected to do things that way. But at least, if you
do use the feature, your code is typechecked and you can't get runtime
NPE's from Kotlin (as opposed to interop) code except for
initialization order problems.

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
  (3) Delegation/proxying (without a plugin).

In the spirit of Scala I guess the feature missing here is a good macro system to solve the general case.

Take a look at MorphJ: http://code.google.com/p/morphing/wiki/MorphJ


Besides that. The module as compilation unit thing sounded like a good thing too...


BR,
John
Paul Hudson
Joined: 2011-01-08,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On 20 July 2011 01:03, Jim Balter <Jim [at] balter [dot] name> wrote:
On the broader issue ... designing new programming languages is all
the rage now, with Go, Vala, Rust, BitC, Closure, Plaid, Agda, Coq,
Nemerle, Kotlin ... some of the reasons for doing so are better than
others, but in any case it's going to continue. Hopefully lessons will
be learned from all these efforts.

I think today's XKCD might explain some of this http://xkcd.com/927/ :)

fanf
Joined: 2009-03-17,
User offline. Last seen 2 years 30 weeks ago.
Re: new language "Kotlin" from jetbrains

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"

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 1:53 AM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise). Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online. 
In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption. 
Yes, exactly.

It looks like a language that has taken ideas from C#, Java, and Scala and blended them. I do not really see any tradeoffs that would make it simpler than Scala. Maybe a bit simpler to compile, and fewer opportunities for mis-use (no implicits, no symbolic operators) but not simpler to spec or program in. On the other hand it will have to prove that it's as good for library and framework abstractions as Scala is.

The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin

sergei
Joined: 2011-03-29,
User offline. Last seen 1 year 20 weeks ago.
Re: new language "Kotlin" from jetbrains
Hmm. Interesting. 
The fundamental strength of JetBrains twelve or so years back when it was founded was outstanding output/compensation ratio of Eastern European programmers. I recall marveling at the sheer numbers and pedigrees of JetBrain programmers willing to work for so relatively little. That advantage is mostly gone now, as large Eastern European cities became ones of the most expensive in the world to live in, with corresponding salary requirements. 
Secondary advantage was strong higher education system built in the Soviet times, pumping out humble and consistently productive local talent. It severely deteriorated since then, as education funding was ruthlessly cut and the whole generation of would-be-professors and star students left Eastern European countries in the last couple of decades. Interestingly enough, a virtual carbon-copy of that system is still operational and thriving in India, which partially explains India's increasing strength in software development.
Indication of JetBrains increasing weakness for me personally was the way that the three major Scala IDEs were evolving for the last couple years. I was really surprised that just one person could develop a more useful Scala plugin for NetBeans than the whole mighty JetBrains could for IDEA. 
I'm not sure to what degree that phenomenon could be explained by the fresher, better organized NetBeans code base, the differences in talent of corresponding developers, and lack of strategic vision on the JetBrains part, yet the subjective fact for me was that JetBrains seriously dropped the ball on this one. There was a two-three-year period of Scala IDE vacuum than they utterly failed to fill.
And now they are throwing in the towel completely, probably being scared by the TypeSafe's progress on Eclipse-based Scala IDE. In general, they are seriously squeezed by the successes of Eclipse-based IDEs and continuing evolution of Visual Studio and XCode. Maybe coming up with the language they can control is a wise competitive response to that situation. Or maybe it is a futile attempt to turn things around, driven mostly by emotion. Frankly, I don't know at this point. Time will tell...  
On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking). If you just want add and subtract a few features, I would guess that forking could save you one hell of a lot of time compared to starting from scratch. It would also make the language a lot more familiar to current Scala users, thereby encouraging adoption. Who wants to learn a whole new language just for a few different features? But maybe the language differs from Scala more than I realize, since I only briefly skimmed the list of differences.

--Russ P.


On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.



--
http://RussP.us

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:

 http://confluence.jetbrains.net/display/Kotlin/Welcome

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.

The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

Cheers

 -- Martin

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


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 3:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new
 
The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

I don't think that all features must "scale" in order to be worthwhile.  While loops don't scale very well to complex collection manipulations, but Scala without them would be unusable for high-performance tasks.  Operators don't scale beyond 3 or 4 characters before they're indecipherable gibberish, but Scala that required "a plus b" would be awkward to use.  Tuples don't scale to large numbers of items, but that doesn't mean that they should be discarded in favor of HLists.

Even if we granted that scalability was a very high priority, I don't think the "mature framework" where your job is to glue together interfaces is the only or even the most interesting direction for scalability.  Another area of scalability is to manage large quantities of runtime data, e.g. with millions of objects.  GC is a pain in such situations, and there, I'd argue that PML is the one that doesn't scale (not unless escape analysis is perfect), because the cost-per-object gets increasingly expensive as the object churn goes up, while extension functions have fewer limits.  There's also scalability in terms of number-of-lines-of-code, and right now the volume of boilerplate per PML pattern is more than an extension function would require (if you just need to add the capability, not the interface).

I'm not saying to get rid of implicit conversions.  They're very useful, and if I had to pick one, I'd pick them.  But there are cases, including cases where scalability is important, where using implicit conversions for PML is a mediocre substitute for extension functions.

  --Rex

fanf
Joined: 2009-03-17,
User offline. Last seen 2 years 30 weeks ago.
Re: new language "Kotlin" from jetbrains
On 20/07/2011 04:16, Rex Kerr wrote:
CAP_xLa08j1Pn94nixtfLtRHS7UG9HcuVYk46G_u0edymb2v-1w [at] mail [dot] gmail [dot] com" type="cite"> On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <paulp [at] improving [dot] org" rel="nofollow">paulp [at] improving [dot] org> wrote:
[..]
It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala.  I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile.  The scenery up here on mile two, it's nice, you
should come give it a look.

P.S. First mile is long.

They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.

Well, it's only my personnal interpretation, but I think that in the first mile, Paul also take into account the "adoption" factor.
Scala is now known and used in application deployed for several years, it has started to be an option for new projects... How much time and effort before Kotlin (or any other new Scala-alike language) reaching that state ?

I, too, share Paul (or Tony and others) sadness on that. On the other hand, being on a "every cloud has a silver line" mood, I will say that all these languages (and COT ;) are a good matrix for Scala 3.0.

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

There's another dimension to complexity, which is what people typically do with a language. Again, I find the average Scala code pleasantly simple, but it's true that some of the best published code is complex, in that it solves very abstract tasks. Scalaz has a lot of great ideas embedded in it, but if we want Scala to succeed we need to publish more of the simple kind of code!

Best,

 -- Martin

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 9:33 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Wed, Jul 20, 2011 at 3:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:

 http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala

It makes me sad to see another whole implementation's worth of effort
being poured into something new
 
The key ones to my eye are

  (1) Extension functions.  Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.

Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

I don't think that all features must "scale" in order to be worthwhile.  While loops don't scale very well to complex collection manipulations, but Scala without them would be unusable for high-performance tasks.  Operators don't scale beyond 3 or 4 characters before they're indecipherable gibberish, but Scala that required "a plus b" would be awkward to use.  Tuples don't scale to large numbers of items, but that doesn't mean that they should be discarded in favor of HLists.

Even if we granted that scalability was a very high priority, I don't think the "mature framework" where your job is to glue together interfaces is the only or even the most interesting direction for scalability.  Another area of scalability is to manage large quantities of runtime data, e.g. with millions of objects.  GC is a pain in such situations, and there, I'd argue that PML is the one that doesn't scale (not unless escape analysis is perfect), because the cost-per-object gets increasingly expensive as the object churn goes up, while extension functions have fewer limits.  There's also scalability in terms of number-of-lines-of-code, and right now the volume of boilerplate per PML pattern is more than an extension function would require (if you just need to add the capability, not the interface).

It's pretty straightforward to optimize these wrappers away, either in the compiler or in the JVM. I have so far resisted making them a special case (which we could) because I think that a decent general purpose optimizer should be able to eliminate the object creation and call indirection, generating in effect the same code as an extension method. Scala optimizers evolve more slowly than I would like, but it's no reason to give up and instead throw more features into the language.

 -- Martin

Ittay Dror 2
Joined: 2010-05-05,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains


martin odersky wrote:
4RFvbgyQNBZMk114Bxe7+jGzg [at] mail [dot] gmail [dot] com" type="cite">

On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com" rel="nofollow">naftoligug [at] gmail [dot] com> wrote:


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

From my experience and talking to other people, people do not measure complexity that way. The majority of people don't find Lisp simple.

4RFvbgyQNBZMk114Bxe7+jGzg [at] mail [dot] gmail [dot] com" type="cite">
There's another dimension to complexity, which is what people typically do with a language. Again, I find the average Scala code pleasantly simple, but it's true that some of the best published code is complex, in that it solves very abstract tasks. Scalaz has a lot of great ideas embedded in it, but if we want Scala to succeed we need to publish more of the simple kind of code!

I think another dimension is familarity. People get out of collage and are eager to get a job. So they learn a language and from then on all languages measure up by how close they are to that language. I think this is why Groovy is so successful (being very close to Java syntax).

Ittay

4RFvbgyQNBZMk114Bxe7+jGzg [at] mail [dot] gmail [dot] com" type="cite">
Best,

 -- Martin

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On 20/07/11 18:16, martin odersky wrote:
4RFvbgyQNBZMk114Bxe7+jGzg [at] mail [dot] gmail [dot] com" type="cite">

On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com" rel="nofollow">naftoligug [at] gmail [dot] com> wrote:


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

There's another dimension to complexity, which is what people typically do with a language. Again, I find the average Scala code pleasantly simple, but it's true that some of the best published code is complex, in that it solves very abstract tasks. Scalaz has a lot of great ideas embedded in it, but if we want Scala to succeed we need to publish more of the simple kind of code!

Best,

 -- Martin

Complex is a euphemism for, "I do not understand [that which is complex], and I will fight tooth and nail to ensure the situation stays that way."

Others include, "academic", "unnatural" or "is not real world."

I recommend blunt dismissal rather than taking it too seriously.

-- 
Tony Morris
http://tmorris.net/

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 10:26 AM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com> wrote:


martin odersky wrote:


On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

From my experience and talking to other people, people do not measure complexity that way. The majority of people don't find Lisp simple.

I agree with you and Toni there's that dimension as well. "Complex" as a synonym for "unfamiliar". But often the comparisons then say that Scala is the next C++, and there the analogy breaks down completely. C++ is familiar, yet complex (in terms of feature count/interaction). Scala is less familiar, but also much less complex.

Cheers

 -- Martin

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: new language "Kotlin" from jetbrains

Complex is a euphemism for, "I do not understand [that which is complex], and I will fight tooth and nail to ensure the situation stays that way."

Others include, "academic", "unnatural" or "is not real world."

I recommend blunt dismissal rather than taking it too seriously.

Not quite...
I typically see "complex" used to mean "The apparent learning curve is too steep/long to justify the perceived gains". (Which actually says the same thing, just from a different perspective)This is then followed up decision to ignore the concept; which is considered perfectly rational by the objector on the basis of the above cost/benefit analysis.
Lack of understanding is, of course, inherent here: If you already understood the thing then there would be no learning curve!An effective response in such circumstances is to demonstrate that the learning cost is much lower, or that the benefits are much higher, than was originally believed.
Ittay Dror 2
Joined: 2010-05-05,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains


martin odersky wrote:
Ajn_D-gNg [at] mail [dot] gmail [dot] com" type="cite">

On Wed, Jul 20, 2011 at 10:26 AM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com" rel="nofollow">ittay [dot] dror [at] gmail [dot] com> wrote:


martin odersky wrote:


On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com" target="_blank" rel="nofollow">naftoligug [at] gmail [dot] com> wrote:


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

From my experience and talking to other people, people do not measure complexity that way. The majority of people don't find Lisp simple.

I agree with you and Toni there's that dimension as well. "Complex" as a synonym for "unfamiliar". But often the comparisons then say that Scala is the next C++, and there the analogy breaks down completely. C++ is familiar, yet complex (in terms of feature count/interaction). Scala is less familiar, but also much less complex.

I love Scala and C++ was my first language and I was quite good at it I think. Yet Scala does feel to me like going back to C++. First, it has more features than Java. Second, compiling is slow. Third, compile errors remind me of C++ compile errors.

I think Scala is complex in the same sense that Chess feels complex. There are plenty of games that have more rules than Chess. Maybe there's a "flat" vs. "deep" complexity. "flat" complexity is a lot of features. "deep" complexity is the ability to mix features. If a language has a lot of "flat" features (e.g., extension methods) it will feel easier to learn simply because there is just one layer to trudge through. If a language as "deep" complexity, then learning the few simple features it has is only the beginning. Maybe people feel at loss because it is hard to know when they have mastered the language.

Another aspect may be that the wealth of Scala is usually demonstrated by its type system. But to correctly define types (esp. type constructurs, abstract types, bounds, type classes etc.) you need to think in the abstract while languages such as Groovy provide features that are easily traceable at runtime. So it is easy to put a debugger and find out why things don't work. There's no such thing for compilation. So designing is trickier. (It is the analogy of debugging your programs with println, but trickier)

Ittay

Ajn_D-gNg [at] mail [dot] gmail [dot] com" type="cite"> Cheers

 -- Martin

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 11:03 AM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com> wrote:


martin odersky wrote:


On Wed, Jul 20, 2011 at 10:26 AM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com> wrote:


martin odersky wrote:


On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:


The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.

Cheers

 -- Martin


What precisely is the value or purpose of a small language footprint?

Well a lot of people complain that "Scala is too complex". I personally don't believe that, and note that most of the criticism comes from people who are designing or supporting competing languages, not people who learn Scala. But I take the point very seriously. How do you measure  complexity? The best I know is to look how many features does a language have, and how many tricky interactions between these features. By that measure C# is a far more complex language than Scala and the jury is still out whether Kotlin or Ceylon or Groovy++ or any of the other "better Java" languages will me more or less complex (my guess is: probably in the same ballpark).

From my experience and talking to other people, people do not measure complexity that way. The majority of people don't find Lisp simple.

I agree with you and Toni there's that dimension as well. "Complex" as a synonym for "unfamiliar". But often the comparisons then say that Scala is the next C++, and there the analogy breaks down completely. C++ is familiar, yet complex (in terms of feature count/interaction). Scala is less familiar, but also much less complex.

I love Scala and C++ was my first language and I was quite good at it I think. Yet Scala does feel to me like going back to C++. First, it has more features than Java.

I believe once Java 8 is out we will have reached parity in numbers of features, if that's not already the case with Java 7. Languages like C#, C++ have way more features than Scala.
 
Second, compiling is slow. Third, compile errors remind me of C++ compile errors.

I hope we can fix both of these. Note that compiling Java was initially also quite slow.
 
I think Scala is complex in the same sense that Chess feels complex. There are plenty of games that have more rules than Chess. Maybe there's a "flat" vs. "deep" complexity. "flat" complexity is a lot of features. "deep" complexity is the ability to mix features. If a language has a lot of "flat" features (e.g., extension methods) it will feel easier to learn simply because there is just one layer to trudge through. If a language as "deep" complexity, then learning the few simple features it has is only the beginning. Maybe people feel at loss because it is hard to know when they have mastered the language.

The "deep" vs "broad" discussion does captures the point very well, I think.
 
Another aspect may be that the wealth of Scala is usually demonstrated by its type system. But to correctly define types (esp. type constructurs, abstract types, bounds, type classes etc.) you need to think in the abstract while languages such as Groovy provide features that are easily traceable at runtime. So it is easy to put a debugger and find out why things don't work. There's no such thing for compilation. So designing is trickier. (It is the analogy of debugging your programs with println, but trickier)

Very true. That's why we are working on a type debugger. There was a talk at Scala Days about this.

Cheers

 -- Martin

nomad
Joined: 2011-01-16,
User offline. Last seen 1 year 22 weeks ago.
Re: new language "Kotlin" from jetbrains

Martin,

I was wondering if you could comment a little bit on the performance
tradeoff of extension functions vs. implicit conversions. When the
Kotlin page claims that Scala wraps values into adapters at runtime
(http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
this seems like a bit of a mischaracterization to me. It's true that
implicits require a rich wrapper to be created at runtime, but
determination of the wrapper, and the actual "wrapping" seem to be
happening at compile-time. There's some debate about this happening on
reddit (http://www.reddit.com/r/programming/comments/iub22/
project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
hoping you might comment on some of the arguments being made there.

Cheers,
Rob

On Jul 20, 3:02 am, martin odersky wrote:
> On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr wrote:
> > On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips wrote:
>
> >> Maybe I'm the last guy to hear about things (it happens enough) but
> >> there's this language here which looks like a more credible effort to be
> >> a better/simpler scala than most:
>
> >>  http://confluence.jetbrains.net/display/Kotlin/Welcome
>
> >> The "What Kotlin has that Scala has not" list does read like a list of
> >> things I would not mind having:
>
> >>  http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
>
> >> It makes me sad to see another whole implementation's worth of effort
> >> being poured into something new -- come on guys, you won't be enough
> >> better than scala.  I know everyone wants their own baby, but just
> >> imagine what we might accomplish if we didn't all keep re-running the
> >> same opening mile.  The scenery up here on mile two, it's nice, you
> >> should come give it a look.
>
> >> P.S. First mile is long.
>
> > They've only gone (or planned) a few hundred yards in a direction that
> > Scala hasn't already been.
>
> > The key ones to my eye are
>
> >   (1) Extension functions.  Much cleaner syntax and better performance than
> > the Pimp My Library pattern using implicits.
>
> Extension functions are shortsighted because they only make a class get new
> methods but do not let it implement new interfaces. In any mature framework,
> the primary reason for a method to exist is to implement some interface.
> Extension functions don't scale up to that usage.
>
> Cheers
>
>  -- Martin

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: new language "Kotlin" from jetbrains


On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro <rob [dot] patro [at] gmail [dot] com> wrote:
Martin,

 I was wondering if you could comment a little bit on the performance
tradeoff of extension functions vs. implicit conversions.  When the
Kotlin page claims that Scala wraps values into adapters at runtime
(http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
this seems like a bit of a mischaracterization to me.  It's true that
implicits require a rich wrapper to be created at runtime, but
determination of the wrapper, and the actual "wrapping" seem to be
happening at compile-time. There's some debate about this happening on
reddit (http://www.reddit.com/r/programming/comments/iub22/
project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
hoping you might comment on some of the arguments being made there.


See my earlier mail in this thread:

It's pretty straightforward to optimize these wrappers away, either in the compiler or in the JVM. I have so far resisted making them a special case (which we could) because I think that a decent general purpose optimizer should be able to eliminate the object creation and call indirection, generating in effect the same code as an extension method. Scala optimizers evolve more slowly than I would like, but it's no reason to give up and instead throw more features into the language.

 -- Martin

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

when everything besides "pimp my lib" is irrelevant, then extension functions are the better choice. they are simpler and are guaranteed not to add a performance penaltly. when wrapping stuff at runtime, you cannot be sure in advance what the vm will optimize away and what it won't.

however, implicit conversions are more powerful - wrapping stuff temporarily is just one use case that happens to have to same effect as extension functions. extension functions can't actually wrap/convert an object, so if you want to do that, you'll have to do it manually.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 05:28:08 -0700 (PDT)
> Von: Rob Patro
> An: scala-debate
> Betreff: [scala-debate] Re: new language "Kotlin" from jetbrains

> Martin,
>
> I was wondering if you could comment a little bit on the performance
> tradeoff of extension functions vs. implicit conversions. When the
> Kotlin page claims that Scala wraps values into adapters at runtime
> (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> this seems like a bit of a mischaracterization to me. It's true that
> implicits require a rich wrapper to be created at runtime, but
> determination of the wrapper, and the actual "wrapping" seem to be
> happening at compile-time. There's some debate about this happening on
> reddit (http://www.reddit.com/r/programming/comments/iub22/
> project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> hoping you might comment on some of the arguments being made there.
>
> Cheers,
> Rob
>
> On Jul 20, 3:02 am, martin odersky wrote:
> > On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr wrote:
> > > On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips
> wrote:
> >
> > >> Maybe I'm the last guy to hear about things (it happens enough) but
> > >> there's this language here which looks like a more credible effort to
> be
> > >> a better/simpler scala than most:
> >
> > >>  http://confluence.jetbrains.net/display/Kotlin/Welcome
> >
> > >> The "What Kotlin has that Scala has not" list does read like a list
> of
> > >> things I would not mind having:
> >
> > >>  http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
> >
> > >> It makes me sad to see another whole implementation's worth of effort
> > >> being poured into something new -- come on guys, you won't be enough
> > >> better than scala.  I know everyone wants their own baby, but just
> > >> imagine what we might accomplish if we didn't all keep re-running the
> > >> same opening mile.  The scenery up here on mile two, it's nice, you
> > >> should come give it a look.
> >
> > >> P.S. First mile is long.
> >
> > > They've only gone (or planned) a few hundred yards in a direction that
> > > Scala hasn't already been.
> >
> > > The key ones to my eye are
> >
> > >   (1) Extension functions.  Much cleaner syntax and better
> performance than
> > > the Pimp My Library pattern using implicits.
> >
> > Extension functions are shortsighted because they only make a class get
> new
> > methods but do not let it implement new interfaces. In any mature
> framework,
> > the primary reason for a method to exist is to implement some interface.
> > Extension functions don't scale up to that usage.
> >
> > Cheers
> >
> >  -- Martin

xeno.by
Joined: 2011-07-18,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

Here's how Kotlin implements reification: "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" (http://confluence.jetbrains.net/display/Kotlin/Welcome?
focusedCommentId=40703305&#comment-40703305).

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

just found:
http://confluence.jetbrains.net/display/Kotlin/Tuples

they have labeled tuples, meaning you can access the attributes by names instead of _1, _2 and so on

this is a feature worth of being copied.
first idea:

val magicTuple:(x,y) = (1,2)

is short for

class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
val magicTUple = new asd(1,2)

so the caller also benefits from the names.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 14:32:12 +0200
> Von: martin odersky
> An: Rob Patro
> CC: scala-debate
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

> On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro wrote:
>
> > Martin,
> >
> > I was wondering if you could comment a little bit on the performance
> > tradeoff of extension functions vs. implicit conversions. When the
> > Kotlin page claims that Scala wraps values into adapters at runtime
> > (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> > this seems like a bit of a mischaracterization to me. It's true that
> > implicits require a rich wrapper to be created at runtime, but
> > determination of the wrapper, and the actual "wrapping" seem to be
> > happening at compile-time. There's some debate about this happening on
> > reddit (http://www.reddit.com/r/programming/comments/iub22/
> > project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> > hoping you might comment on some of the arguments being made there.
> >
> >
> See my earlier mail in this thread:
>
> It's pretty straightforward to optimize these wrappers away, either in the
> compiler or in the JVM. I have so far resisted making them a special case
> (which we could) because I think that a decent general purpose optimizer
> should be able to eliminate the object creation and call indirection,
> generating in effect the same code as an extension method. Scala
> optimizers
> evolve more slowly than I would like, but it's no reason to give up and
> instead throw more features into the language.
>

Maxime Lévesque
Joined: 2009-08-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

And how about type level programming, or defining type level constraints ?
I see this a compelling use case for implicit params and conversions.

ML

2011/7/20 Dennis Haupt <h-star [at] gmx [dot] de>
when everything besides "pimp my lib" is irrelevant, then extension functions are the better choice. they are simpler and are guaranteed not to add a performance penaltly. when wrapping stuff at runtime, you cannot be sure in advance what the vm will optimize away and what it won't.

however, implicit conversions are more powerful - wrapping stuff temporarily is just one use case that happens to have to same effect as extension functions. extension functions can't actually wrap/convert an object, so if you want to do that, you'll have to do it manually.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 05:28:08 -0700 (PDT)
> Von: Rob Patro <rob [dot] patro [at] gmail [dot] com>
> An: scala-debate <scala-debate [at] googlegroups [dot] com>
> Betreff: [scala-debate] Re: new language "Kotlin" from jetbrains

> Martin,
>
>   I was wondering if you could comment a little bit on the performance
> tradeoff of extension functions vs. implicit conversions.  When the
> Kotlin page claims that Scala wraps values into adapters at runtime
> (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> this seems like a bit of a mischaracterization to me.  It's true that
> implicits require a rich wrapper to be created at runtime, but
> determination of the wrapper, and the actual "wrapping" seem to be
> happening at compile-time. There's some debate about this happening on
> reddit (http://www.reddit.com/r/programming/comments/iub22/
> project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> hoping you might comment on some of the arguments being made there.
>
> Cheers,
> Rob
>
> On Jul 20, 3:02 am, martin odersky <martin [dot] oder [dot] [dot] [dot] [at] epfl [dot] ch> wrote:
> > On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <icho [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> > > On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips
> <pa [dot] [dot] [dot] [at] improving [dot] org>wrote:
> >
> > >> Maybe I'm the last guy to hear about things (it happens enough) but
> > >> there's this language here which looks like a more credible effort to
> be
> > >> a better/simpler scala than most:
> >
> > >>  http://confluence.jetbrains.net/display/Kotlin/Welcome
> >
> > >> The "What Kotlin has that Scala has not" list does read like a list
> of
> > >> things I would not mind having:
> >
> > >>  http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
> >
> > >> It makes me sad to see another whole implementation's worth of effort
> > >> being poured into something new -- come on guys, you won't be enough
> > >> better than scala.  I know everyone wants their own baby, but just
> > >> imagine what we might accomplish if we didn't all keep re-running the
> > >> same opening mile.  The scenery up here on mile two, it's nice, you
> > >> should come give it a look.
> >
> > >> P.S. First mile is long.
> >
> > > They've only gone (or planned) a few hundred yards in a direction that
> > > Scala hasn't already been.
> >
> > > The key ones to my eye are
> >
> > >   (1) Extension functions.  Much cleaner syntax and better
> performance than
> > > the Pimp My Library pattern using implicits.
> >
> > Extension functions are shortsighted because they only make a class get
> new
> > methods but do not let it implement new interfaces. In any mature
> framework,
> > the primary reason for a method to exist is to implement some interface.
> > Extension functions don't scale up to that usage.
> >
> > Cheers
> >
> >  -- Martin

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 9:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

I wonder. Is this really true in the face of type classes? It seems to me that the approach of type classes scales almost better than subclassing.

I know you think this is a question of optimization. But there are semantics to consider.

a) Wrapping an object creates a new object, with identiy, hashing, monitoring and all that. Do we really want to rely on optimzation to remove theese semantics?

b) Doesn't wrapping interfere with type inference and typing in general? Most of the time you _dont_ want to change the type of the wrapped object. To return X or RichX...

BR,
John
John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 3:23 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
just found:
http://confluence.jetbrains.net/display/Kotlin/Tuples

they have labeled tuples, meaning you can access the attributes by names instead of _1, _2 and so on

this is a feature worth of being copied.
first idea:

val magicTuple:(x,y) = (1,2)

is short for

class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
val magicTUple = new asd(1,2)

so the caller also benefits from the names.

One could maybe go one step further and unify argument lists and tuples. Enabling function composition by name instead of position and other goodies.

BR,
John
Maxime Lévesque
Joined: 2009-08-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

as a substitute for labeled tuples :

val z = new {val a = 1; val b = 2}

println(z.a)


2011/7/20 Dennis Haupt <h-star [at] gmx [dot] de>
just found:
http://confluence.jetbrains.net/display/Kotlin/Tuples

they have labeled tuples, meaning you can access the attributes by names instead of _1, _2 and so on

this is a feature worth of being copied.
first idea:

val magicTuple:(x,y) = (1,2)

is short for

class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
val magicTUple = new asd(1,2)

so the caller also benefits from the names.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 14:32:12 +0200
> Von: martin odersky <martin [dot] odersky [at] epfl [dot] ch>
> An: Rob Patro <rob [dot] patro [at] gmail [dot] com>
> CC: scala-debate <scala-debate [at] googlegroups [dot] com>
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

> On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro <rob [dot] patro [at] gmail [dot] com> wrote:
>
> > Martin,
> >
> >  I was wondering if you could comment a little bit on the performance
> > tradeoff of extension functions vs. implicit conversions.  When the
> > Kotlin page claims that Scala wraps values into adapters at runtime
> > (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> > this seems like a bit of a mischaracterization to me.  It's true that
> > implicits require a rich wrapper to be created at runtime, but
> > determination of the wrapper, and the actual "wrapping" seem to be
> > happening at compile-time. There's some debate about this happening on
> > reddit (http://www.reddit.com/r/programming/comments/iub22/
> > project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> > hoping you might comment on some of the arguments being made there.
> >
> >
> See my earlier mail in this thread:
>
> It's pretty straightforward to optimize these wrappers away, either in the
> compiler or in the JVM. I have so far resisted making them a special case
> (which we could) because I think that a decent general purpose optimizer
> should be able to eliminate the object creation and call indirection,
> generating in effect the same code as an extension method. Scala
> optimizers
> evolve more slowly than I would like, but it's no reason to give up and
> instead throw more features into the language.
>
>  -- Martin

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

add some sugar for that, please. like
(x = 1;b = 2) - new and the val should be omitted here

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 10:16:37 -0400
> Von: "Maxime Lévesque"
> An: Dennis Haupt
> CC: martin odersky , rob [dot] patro [at] gmail [dot] com, scala-debate [at] googlegroups [dot] com
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

> as a substitute for labeled tuples :
>
> val z = new {val a = 1; val b = 2}
>
> println(z.a)
>
>
> 2011/7/20 Dennis Haupt
>
> > just found:
> > http://confluence.jetbrains.net/display/Kotlin/Tuples
> >
> > they have labeled tuples, meaning you can access the attributes by names
> > instead of _1, _2 and so on
> >
> > this is a feature worth of being copied.
> > first idea:
> >
> > val magicTuple:(x,y) = (1,2)
> >
> > is short for
> >
> > class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
> > val magicTUple = new asd(1,2)
> >
> > so the caller also benefits from the names.
> >
> > -------- Original-Nachricht --------
> > > Datum: Wed, 20 Jul 2011 14:32:12 +0200
> > > Von: martin odersky
> > > An: Rob Patro
> > > CC: scala-debate
> > > Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains
> >
> > > On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro
> wrote:
> > >
> > > > Martin,
> > > >
> > > > I was wondering if you could comment a little bit on the
> performance
> > > > tradeoff of extension functions vs. implicit conversions. When the
> > > > Kotlin page claims that Scala wraps values into adapters at runtime
> > > >
> (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> > > > this seems like a bit of a mischaracterization to me. It's true
> that
> > > > implicits require a rich wrapper to be created at runtime, but
> > > > determination of the wrapper, and the actual "wrapping" seem to be
> > > > happening at compile-time. There's some debate about this happening
> on
> > > > reddit (http://www.reddit.com/r/programming/comments/iub22/
> > > > project_kotlin_a_new_statically_typed_programming/c26rgu0), and I
> was
> > > > hoping you might comment on some of the arguments being made there.
> > > >
> > > >
> > > See my earlier mail in this thread:
> > >
> > > It's pretty straightforward to optimize these wrappers away, either in
> > the
> > > compiler or in the JVM. I have so far resisted making them a special
> case
> > > (which we could) because I think that a decent general purpose
> optimizer
> > > should be able to eliminate the object creation and call indirection,
> > > generating in effect the same code as an extension method. Scala
> > > optimizers
> > > evolve more slowly than I would like, but it's no reason to give up
> and
> > > instead throw more features into the language.
> > >
> > > -- Martin
> >

Maxime Lévesque
Joined: 2009-08-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

Not sure how hard (or how much unwanted interaction with existing feature) this kind of
sugar would add, it seems like an "explosive" feature in this regard, unless one introduces something like :

val z = #{a = 1; b = 2}

maybe a macro system might be a generalizable way to introduce this
(...but then you ratchet up the complexity...)


2011/7/20 Dennis Haupt <h-star [at] gmx [dot] de>
add some sugar for that, please. like
(x = 1;b = 2) - new and the val should be omitted here

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 10:16:37 -0400
> Von: "Maxime Lévesque" <maxime [dot] levesque [at] gmail [dot] com>
> An: Dennis Haupt <h-star [at] gmx [dot] de>
> CC: martin odersky <martin [dot] odersky [at] epfl [dot] ch>, rob [dot] patro [at] gmail [dot] com, scala-debate [at] googlegroups [dot] com
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

> as a substitute for labeled tuples :
>
> val z = new {val a = 1; val b = 2}
>
> println(z.a)
>
>
> 2011/7/20 Dennis Haupt <h-star [at] gmx [dot] de>
>
> > just found:
> > http://confluence.jetbrains.net/display/Kotlin/Tuples
> >
> > they have labeled tuples, meaning you can access the attributes by names
> > instead of _1, _2 and so on
> >
> > this is a feature worth of being copied.
> > first idea:
> >
> > val magicTuple:(x,y) = (1,2)
> >
> > is short for
> >
> > class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
> > val magicTUple = new asd(1,2)
> >
> > so the caller also benefits from the names.
> >
> > -------- Original-Nachricht --------
> > > Datum: Wed, 20 Jul 2011 14:32:12 +0200
> > > Von: martin odersky <martin [dot] odersky [at] epfl [dot] ch>
> > > An: Rob Patro <rob [dot] patro [at] gmail [dot] com>
> > > CC: scala-debate <scala-debate [at] googlegroups [dot] com>
> > > Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains
> >
> > > On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro <rob [dot] patro [at] gmail [dot] com>
> wrote:
> > >
> > > > Martin,
> > > >
> > > >  I was wondering if you could comment a little bit on the
> performance
> > > > tradeoff of extension functions vs. implicit conversions.  When the
> > > > Kotlin page claims that Scala wraps values into adapters at runtime
> > > >
> (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> > > > this seems like a bit of a mischaracterization to me.  It's true
> that
> > > > implicits require a rich wrapper to be created at runtime, but
> > > > determination of the wrapper, and the actual "wrapping" seem to be
> > > > happening at compile-time. There's some debate about this happening
> on
> > > > reddit (http://www.reddit.com/r/programming/comments/iub22/
> > > > project_kotlin_a_new_statically_typed_programming/c26rgu0), and I
> was
> > > > hoping you might comment on some of the arguments being made there.
> > > >
> > > >
> > > See my earlier mail in this thread:
> > >
> > > It's pretty straightforward to optimize these wrappers away, either in
> > the
> > > compiler or in the JVM. I have so far resisted making them a special
> case
> > > (which we could) because I think that a decent general purpose
> optimizer
> > > should be able to eliminate the object creation and call indirection,
> > > generating in effect the same code as an extension method. Scala
> > > optimizers
> > > evolve more slowly than I would like, but it's no reason to give up
> and
> > > instead throw more features into the language.
> > >
> > >  -- Martin
> >

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains

+1

I would just be happy if the compiler had sugar for easier typeclass creation/definition and under the covers it still used implicits.   With the T : M syntax, if we also had a way to make methoda on M[T] that take a T as their first parameter appear to be methods on T without boilerplate, then most uses of implicit views are unecessary for me.

Another implicit view use case i would miss is acting as a "lens" between two types that represent the same thing from different libraries.

So... implicits are more general, but I would love some optimisations for common use cases.

On Jul 20, 2011 10:07 AM, "John Nilsson" <john [at] milsson [dot] nu> wrote:
> On Wed, Jul 20, 2011 at 9:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>wrote:
>
>> Extension functions are shortsighted because they only make a class get new
>> methods but do not let it implement new interfaces. In any mature framework,
>> the primary reason for a method to exist is to implement some interface.
>> Extension functions don't scale up to that usage.
>>
>
> I wonder. Is this really true in the face of type classes? It seems to me
> that the approach of type classes scales almost better than subclassing.
>
> I know you think this is a question of optimization. But there are semantics
> to consider.
>
> a) Wrapping an object creates a new object, with identiy, hashing,
> monitoring and all that. Do we really want to rely on optimzation to remove
> theese semantics?
>
> b) Doesn't wrapping interfere with type inference and typing in general?
> Most of the time you _dont_ want to change the type of the wrapped object.
> To return X or RichX...
>
> BR,
> John
Maxime Lévesque
Joined: 2009-08-18,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

One advantage that Scala could exploit more aggressively is GWT+Scala.
Web client code is a significant percentage of code being written and
maintained nowdays, and having it strongly typed, and in the same
language as the back end will be a huge plus n my opinion
...When it gets there, I wonder how "strategic" that project is considered
to be by the Scala team.


2011/7/20 Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>

+1

I would just be happy if the compiler had sugar for easier typeclass creation/definition and under the covers it still used implicits.   With the T : M syntax, if we also had a way to make methoda on M[T] that take a T as their first parameter appear to be methods on T without boilerplate, then most uses of implicit views are unecessary for me.

Another implicit view use case i would miss is acting as a "lens" between two types that represent the same thing from different libraries.

So... implicits are more general, but I would love some optimisations for common use cases.

On Jul 20, 2011 10:07 AM, "John Nilsson" <john [at] milsson [dot] nu> wrote:
> On Wed, Jul 20, 2011 at 9:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>wrote:
>
>> Extension functions are shortsighted because they only make a class get new
>> methods but do not let it implement new interfaces. In any mature framework,
>> the primary reason for a method to exist is to implement some interface.
>> Extension functions don't scale up to that usage.
>>
>
> I wonder. Is this really true in the face of type classes? It seems to me
> that the approach of type classes scales almost better than subclassing.
>
> I know you think this is a question of optimization. But there are semantics
> to consider.
>
> a) Wrapping an object creates a new object, with identiy, hashing,
> monitoring and all that. Do we really want to rely on optimzation to remove
> theese semantics?
>
> b) Doesn't wrapping interfere with type inference and typing in general?
> Most of the time you _dont_ want to change the type of the wrapped object.
> To return X or RichX...
>
> BR,
> John

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Hi Martin,
On Wed, Jul 20, 2011 at 12:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

Really? C# offers extension methods that don't apply to interfaces either. I find I need extension methods much more often than I need to add an extension to an existing interface.
Not long ago, Brian Goetz posted a proposal to implement this functionality in Java (draft here, PDF) which was very clever but went largely unnoticed, because the need just doesn't appear to be there, in my experience.
-- Cédric
Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 12:57 AM, Francois <fanf42 [at] gmail [dot] com> wrote:
Scala is now known and used in application deployed for several years, it has started to be an option for new projects... How much time and effort before Kotlin (or any other new Scala-alike language) reaching that state ?

Considering that Scala's mindshare is still minuscule (even smaller than Groovy), I think the space between Java and a more modern language is still largely up for grabs. Also, Kotlin is going in one direction than no other language (Groovy, Fantom, Gosu, Ceylon, Scala) has covered adequately yet: top notch IDE support.
This could mean nothing or it could be the difference between obscurity and mainstream.
We'll see.
-- Cédric
Tom Switzer
Joined: 2011-07-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains
Rather than named tuples, I'd love to see Scala case classes implement their arity-specific Product variant instead of just Product. That is, if case class Point(x: Int, y: Int) implemented Product2[Int,Int] instead of Product. This would let case-classes be used in the place of "tuple" arguments.

On Wed, Jul 20, 2011 at 9:23 AM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
just found:
http://confluence.jetbrains.net/display/Kotlin/Tuples

they have labeled tuples, meaning you can access the attributes by names instead of _1, _2 and so on

this is a feature worth of being copied.
first idea:

val magicTuple:(x,y) = (1,2)

is short for

class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
val magicTUple = new asd(1,2)

so the caller also benefits from the names.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 14:32:12 +0200
> Von: martin odersky <martin [dot] odersky [at] epfl [dot] ch>
> An: Rob Patro <rob [dot] patro [at] gmail [dot] com>
> CC: scala-debate <scala-debate [at] googlegroups [dot] com>
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

> On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro <rob [dot] patro [at] gmail [dot] com> wrote:
>
> > Martin,
> >
> >  I was wondering if you could comment a little bit on the performance
> > tradeoff of extension functions vs. implicit conversions.  When the
> > Kotlin page claims that Scala wraps values into adapters at runtime
> > (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> > this seems like a bit of a mischaracterization to me.  It's true that
> > implicits require a rich wrapper to be created at runtime, but
> > determination of the wrapper, and the actual "wrapping" seem to be
> > happening at compile-time. There's some debate about this happening on
> > reddit (http://www.reddit.com/r/programming/comments/iub22/
> > project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> > hoping you might comment on some of the arguments being made there.
> >
> >
> See my earlier mail in this thread:
>
> It's pretty straightforward to optimize these wrappers away, either in the
> compiler or in the JVM. I have so far resisted making them a special case
> (which we could) because I think that a decent general purpose optimizer
> should be able to eliminate the object creation and call indirection,
> generating in effect the same code as an extension method. Scala
> optimizers
> evolve more slowly than I would like, but it's no reason to give up and
> instead throw more features into the language.
>
>  -- Martin

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains


2011/7/20 Cédric Beust ♔ <cedric [at] beust [dot] com>
Hi Martin,
On Wed, Jul 20, 2011 at 12:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.

Really? C# offers extension methods that don't apply to interfaces either. I find I need extension methods much more often than I need to add an extension to an existing interface.

Hi Cedric,

Yes, that might be. But in more evolved designs you do need to implement new interfaces, and extension methods fail there. With implicits you get both functionalities for the price of one language feature.

Not long ago, Brian Goetz posted a proposal to implement this functionality in Java (draft here, PDF) which was very clever but went largely unnoticed, because the need just doesn't appear to be there, in my experience.
I know about defender methods. They are an interesting design, but I really would wish they just added traits instead. The delta between defender methods and traits is very small, but infuriatingly it can't be bridged.

The fact that people do not ask for defender methods might be because the need only manifests itself in larger designs.  And of course, these only come up once you have worked with the feature for a while.

Cheers

 -- Martin


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