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.
In short:
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.
-- Jim
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.
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.
On 20/07/11 12:16, Rex Kerr wrote:
> (2) NotNull support
This is a step backwards.
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.
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.
-- Jim
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking).
Who wants to learn a whole new language just for a few different features?
(3) Delegation/proxying (without a plugin).
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 ...
Rust has done away with nulls altogether, with the cost that
initialization is restricted. From
https://github.com/graydon/rust/wiki/Language-FAQ
"
Data values in the language can only be constructed through a fixed
set of initializer forms. Each of those forms requires that its inputs
already be initialized. A dataflow analysis (the typestate system used
elsewhere) ensures that local variables are initialized before use.
"
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.
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"
--
Francois Armand
http://fanf42.blogspot.com
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.
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.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.
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
On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.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.
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.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.
-- Francois ARMAND http://fanf42.blogspot.com http://www.normation.com
On Wed, Jul 20, 2011 at 3:02 AM, martin odersky <martin....@epfl.ch> wrote:On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.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 newThe 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).