new language "Kotlin" from jetbrains

[Paul Phillips]

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 Paielli]

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.

--
http://RussP.us

[Nikita Ivanov]

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, CEO

GridGain Systems

www.gridgain.com

On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <pa...@improving.org> wrote:

[Tony Morris]

I share the lament.

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

[Jim Balter]

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.

-- Jim

[Russ Paielli]

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 <pa...@improving.org> wrote:

--
http://RussP.us

[Jim Powers]

On Tue, Jul 19, 2011 at 9:16 PM, Russ Paielli <russ.p...@gmail.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]

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]

LOL

--
Srirangan  |  About  Blog  GitHub  LinkedIn  Twitter

[Nikita Ivanov]

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, CEO

GridGain Systems

www.gridgain.com

On Tue, Jul 19, 2011 at 4:29 PM, Paul Phillips <pa...@improving.org> wrote:

[Rex Kerr]

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

[Tony Morris]

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

[Jim Powers]

On Tue, Jul 19, 2011 at 10:11 PM, Nikita Ivanov <niv...@gridgain.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

[Rex Kerr]

On Tue, Jul 19, 2011 at 10:17 PM, Tony Morris <tonym...@gmail.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 ♔]

On Tue, Jul 19, 2011 at 4:53 PM, Nikita Ivanov <niv...@gridgain.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

[Jim Balter]

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

[Cédric Beust ♔]

On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli <russ.p...@gmail.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

[John Nilsson]

On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.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

[Cédric Beust ♔]

On Tue, Jul 19, 2011 at 7:37 PM, Jim Balter <J...@balter.name> wrote:

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 ...

Agreed. I use this all the time in Fantom and it's really nice. The only downside is that question marks soon become overwhelming in code that is relies a lot on null. I guess it's one more incentive to drop the practice.

-- 

Cédric

[Jim Balter]

2011/7/19 Cédric Beust ♔ <ced...@beust.com>:

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.
"

[Paul Hudson]

On 20 July 2011 01:03, Jim Balter <J...@balter.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/ :)

[Francois Armand]

Le 20/07/2011 04:38, Cédric Beust ♔ a écrit :
> On Tue, Jul 19, 2011 at 6:16 PM, Russ Paielli <russ.p...@gmail.com

[...]

> "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"

--
Francois Armand
http://fanf42.blogspot.com

[martin odersky]

On Wed, Jul 20, 2011 at 1:53 AM, Nikita Ivanov <niv...@gridgain.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]

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...

[martin odersky]

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:

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]

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?

[Rex Kerr]

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 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

[Francois]

On 20/07/2011 04:16, Rex Kerr wrote:

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.

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

[martin odersky]

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

[martin odersky]

On Wed, Jul 20, 2011 at 9:33 AM, Rex Kerr <ich...@gmail.com> wrote:

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 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

[Tony Morris]

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.

[Ittay Dror]

martin odersky wrote:

On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <nafto...@gmail.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.

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

Best,

 -- Martin

[martin odersky]

On Wed, Jul 20, 2011 at 10:26 AM, Ittay Dror <ittay...@gmail.com> wrote:

martin odersky wrote:

On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <nafto...@gmail.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

[Russ Paielli]

On Wed, Jul 20, 2011 at 1:26 AM, Tony Morris <tonym...@gmail.com> wrote:

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."

Yes, sometimes, but certainly not always. Take a look at the US tax code.

--Russ P.

--
http://RussP.us

[Kevin Wright]

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]

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

Cheers

 -- Martin

[martin odersky]

On Wed, Jul 20, 2011 at 11:03 AM, Ittay Dror <ittay...@gmail.com> wrote:

martin odersky wrote:

On Wed, Jul 20, 2011 at 10:26 AM, Ittay Dror <ittay...@gmail.com> wrote:

martin odersky wrote:

On Wed, Jul 20, 2011 at 9:28 AM, Naftoli Gugenheim <nafto...@gmail.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

[Rob Patro]

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.oder...@epfl.ch> wrote:

[martin odersky]

On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro <rob....@gmail.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:

[Dennis Haupt]

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....@gmail.com>
> An: scala-debate <scala-...@googlegroups.com>
> Betreff: [scala-debate] Re: new language "Kotlin" from jetbrains

[Eugene Burmako]

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).

[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 <martin....@epfl.ch>
> An: Rob Patro <rob....@gmail.com>
> CC: scala-debate <scala-...@googlegroups.com>
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

[Maxime Lévesque]

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-s...@gmx.de>

[John Nilsson]

On Wed, Jul 20, 2011 at 9:02 AM, martin odersky <martin....@epfl.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]

On Wed, Jul 20, 2011 at 3:23 PM, Dennis Haupt <h-s...@gmx.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]

as a substitute for labeled tuples :

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

println(z.a)

2011/7/20 Dennis Haupt <h-s...@gmx.de>

[Dennis Haupt]

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....@gmail.com>
> An: Dennis Haupt <h-s...@gmx.de>
> CC: martin odersky <martin....@epfl.ch>, rob....@gmail.com, scala-...@googlegroups.com

[Maxime Lévesque]

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-s...@gmx.de>

[Josh Suereth]

+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.

[Maxime Lévesque]

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....@gmail.com>

[Cédric Beust ♔]

Hi Martin,

On Wed, Jul 20, 2011 at 12:02 AM, martin odersky <martin....@epfl.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 ♔]

On Wed, Jul 20, 2011 at 12:57 AM, Francois <fan...@gmail.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

[Josh Suereth]

I never said scala was complex :)

What im mostly looking for are crazy agressive compiler optimisations *and* some extra syntactic sugar for common implicit use cases.

I think this is what scala does *really* well.  The raw features in scala are very abstract, powerful, general and verbose with nice shorthands for common usage.

I mostly use point free style now, something I consider a syntactic convenience.  Im just asking for a few more to simplify certain common tasks.

Im off the opinion that anyone who wants to learn scala will find it approachable.  The corner places where there are complexities seem to revolve around implicits and types, although again the rules are 'simple' around them.   The downside is the code does not look simple, so any feature that reduces syntactic noise and keeps the purity of the idea is a win.

I'm more of the opinion that combating FUD with awesome software is the way to go.   If intellij feels their language has merit, then let them build it.  Scala has the features I need to write highly compelling libraries.  Hopefully I'll be able to do this in an open fashion shortly!

On Jul 20, 2011 11:16 AM, "Martin Odersky" <ode...@gmail.com> wrote:
> Now this is interesting. New language design comes out and its
> rationale accuses Scala of having too many features (unjustly, IMO,
> but still...) Scala list discussion starts about what other features
> to add to Scala. (?)
>
> Martin
>
> Sent from my phone
>
>
> On Jul 20, 2011, at 16:54, Josh Suereth <joshua....@gmail.com>

[Tom Switzer]

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.

[martin odersky]

On Wed, Jul 20, 2011 at 6:19 PM, Tom Switzer <thomas....@gmail.com> wrote:

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.

Now that we have sucesfully removed case classes inheriting from case classes that design becomes possible again. I agree we should do it.

Cheers

 -- Martin

[martin odersky]

On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua....@gmail.com> wrote:

I never said scala was complex :)

If you are in the majority, it's a silent one, then :-)
 

What im mostly looking for are crazy agressive compiler optimisations *and* some extra syntactic sugar for common implicit use cases.

I think we will reconsider Jorge's suggestion:

  implicit class Foo(..) { ... }

to generate the wrapping method automatically. I did not want to do this before, because it did not work for top-level classes. But now that we have package objects we can give it a uniform implementation, so it is an overall win. There you have it, you got me into accepting an extra crumb of syntactic sugar :-)

Cheers

 -- Martin

[martin odersky]

2011/7/20 Cédric Beust ♔ <ced...@beust.com>

Hi Martin,

On Wed, Jul 20, 2011 at 12:02 AM, martin odersky <martin....@epfl.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

[Cédric Beust ♔]

On Wed, Jul 20, 2011 at 9:02 AM, Josh Suereth <joshua....@gmail.com> wrote:

I never said scala was complex :)

I don't really understand this reticence to admitting liking something complex. I think Scala is complex and I like it. I used to love C++ too, for a similar reason. I don't see anything wrong with that, and it also helps understanding the concerns expressed toward Scala (which don't all come from competing language creators, by the way).

-- 

Cédric

[Derek]

On Jul 20, 1:05 pm, Cédric Beust ♔ <ced...@beust.com> wrote:

> On Wed, Jul 20, 2011 at 9:02 AM, Josh Suereth <joshua.suer...@gmail.com>wrote:
>
> > I never said scala was complex :)
>
> I don't really understand this reticence to admitting liking something
> complex. I think Scala is complex and I like it. I used to love C++ too, for
> a similar reason. I don't see anything wrong with that, and it also helps
> understanding the concerns expressed toward Scala (which don't all come from
> competing language creators, by the way).

Alright, I'll put on the flame suit but I really don't think it should
be necessary.

Today, Scala enjoys a community of very advanced programmers - smart
guys (and gals) recognize smart things and jump on them - no big
surprise here. But, for Scala to become something we can all use no
matter what we do or where we go, it has to "go big" and perceived
complexity will only serve to keep it small. Java is not complex - it
is painfully simple, which is why we crave more so that we can express
ourselves better - and it has extremely wide adoption. That's not a
coincidence.

I agree with you that (and I'm going to reword you a bit here,
apologies) no language is worth using if you can explore its depths in
10 minutes, but the reality is that if we want to see it everywhere,
it's got to be that simple. This is why the tight Java
interoperability is such /killer/ feature. I have high hopes for
Scala to hit the mainstream.

[Razvan Cojocaru]

Is there an absolute threshold of an intrinsic measure, where things become suddenly “complex” or is it always a relative term? i.e. can everyone please say “Scala is more/less complex than XXX” rather than absolute romantic statements like “Oh my god, the complexity… what a cruel world”. Having a quantified statement is even better seeing as that implies having to think about it. Such as “OMG, the spec has 50% more pages”?

 

I recommend Martin’s piece on complexity http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

 

Cheers,

Razie

[Francois]

On Wed, Jul 20, 2011 at 12:57 AM, Francois <fan...@gmail.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.

Top notch *IntelliJ* support, at least for some time. OK, every body but me seems to think it's the best IDE around, but it's not the only one, and not the one with the biggest user base (ok, perhaps it's a leadership minded user base, but again that put some delay on the broad adoption).

So,  as you said, we'll see. We are living interesting time.

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

[Cédric Beust ♔]

-- 

Cédric

On Wed, Jul 20, 2011 at 10:44 AM, Francois <fan...@gmail.com> wrote:

On Wed, Jul 20, 2011 at 12:57 AM, Francois <fan...@gmail.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.

Top notch *IntelliJ* support, at least for some time. OK, every body but me seems to think it's the best IDE around, but it's not the only one, and not the one with the biggest user base (ok, perhaps it's a leadership minded user base, but again that put some delay on the broad adoption).

Good point. I'm an Eclipse user myself, so Kotlin's IDEA support does little for me. However, the fact that the language is being designed from the ground up in lockstep with the IDE is, hopefully, a guarantee that it will be extremely toolable (e.g. offering a lot of hooks into the compiler's internals). I'm hopeful that Eclipse support will happen quickly (maybe it's already even underway).

-- 

Cédric

[Josh Suereth]

Let's be a bit more honest.   Type theory is complex.   The Scala language supports a lot of concepts around types as simply as it can.   Applications that use heavy amounts of type theory are complex because of the underlying concept being modeled, not the language itself.

When people say Java is simple, what they mean is that it doesn't allow you to express advanced concepts.  Java is actually far more complex for the concepts it does express.

What I'd like to see in Scala is a few more simplified ways to express the really advanced concepts.   This is what I think will help Scala not look as complex while providing a lot of power.   This is also why I see Scala as having a huge chance of success.   The ability to simply encode powerful concepts and scale the 'complexity' based on your own understanding of those powerful concepts is huge.

I'm in no denial that type theory is difficult, or that everyone should just understand category theory without having learned it.  However, I do not think Scala adds a lot of overhead towards learning these concepts, which is what I mean by "Scala is simple".   If we were honest, we'd just say "Type theory with variance and subtyping is complex" to which I heartily agree.   Using a language that pretends they are not complex is where we really run into issues.   Just look at examples of Java APIs and Scala APIs.   Inside of Google, the Scala APIs could leverage a *lot* more type safety with a lot less type parameters and variance annotations.   I'd say this made things simpler for users, but a bit more complex for library developers.

- Josh

2011/7/20 Cédric Beust ♔ <ced...@beust.com>

[Derek]

+1 (said it better than I could have)

[Rex Kerr]

On Wed, Jul 20, 2011 at 4:20 AM, martin odersky <martin....@epfl.ch> wrote:

On Wed, Jul 20, 2011 at 9:33 AM, Rex Kerr <ich...@gmail.com> wrote:

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.

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.

I'm all for having _compiler_ optimizations instead of language features.  But assuming that the JVM can handle everything is equivalent, for the medium term, to assuming that Scala is going to run on the Sun JVM where those optimizations exist, and hopefully not on Dalvik or elsewhere where they do not.  Of course, optimizations that no JVM can't do, due to lack of information, should have elevated priority.  But that doesn't mean that the others should be entirely neglected.

Besides, I think extension functions are just a generalization of what the language already has, namely multiple parameter lists.  Suppose you could put the parameter name wherever you please:

    def g(a: A)(b: B) = // ...
    g(a)(b)

    def (a: A)g(b: B) = // ...
    (a) g (b)
    a g b

    def (a: A)(b: B)g = // ...
    (a)(b)g

    def ~(a: A) = // ...
    ~ a

    def (a: A)~ = // ...
    a ~

And if you're going to have multiple parameter lists, why not multiple identifiers?  Compare (assuming that Range doesn't already have a by method):

    // Existing way to make DSL for int ranges
    implicit def x(i: Int) = new { def to(j: Int) = Range.inclusive(i,j) }
    implicit def y(r: Range) = new {
      def by(k: Int) = if (r.isInclusive) Range.inclusive(r.start,r.end,k) else Range(r.start,r.end,k)
    }

    // Suggested way to make DSL for int ranges
    def (i: Int) to (j: Int) by (k: Int) = Range.inclusive(i,j,k)

This really doesn't make the _language_ spec much more complex.  It also doesn't make the expressivity of the language any more complex (except for the variant that would allow more-than-one-initial-parameter).  You can already achieve all of this with the existing features, except that it's very clunky to write, has potential performance problems, and leads to strange allowed syntax:

    1 to 7 by 3 by 2   // Huh? Is this 1,4,7 or 1,6 or 1,3,5,7??

Finally, keep in mind that the JVM-applied optimizations so far only make things _better_, not identical to a method call.  For example, I get ~50% slowdown with x.isNaN compared to java.lang.Double.isNaN, and ~8x slowdown with a max b (for doubles) compared to math.max(a,b).

So I'd argue that extension methods are a special case of a modest increase in flexibility of method parameters, and that if PML is intended to replace extension methods entirely, that a compiler optimization not a JVM optimization is called for (since the best optimizing JVM still can't do it completely or very frequently).

  --Rex

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Something akin to newtype/deriving is a better choice than both. There
was a recent related discussion. Leave the wrap/unwrap up to the
compiler ot JVM as Martin says, though this does affect termination
semantics.

On 20/07/11 22:54, Dennis Haupt wrote:
> 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....@gmail.com> An: scala-debate

>> <scala-...@googlegroups.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.oder...@epfl.ch>

>>> 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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4nQHcACgkQmnpgrYe6r63eWgCgmmkJjUdnkHG38kvATLWfV6iv
g4UAn37HQR2boCouvN5kdWImqTNwy2Im
=Cr2F
-----END PGP SIGNATURE-----

[Erik Osheim]

So I've been spending a lot of time trying to optimize the Numeric type
class (see https://github.com/azavea/numeric) and I am of two minds on
the issue of whether it's worth doing specific optimization of wrapper
objects created by implicit decorators.

At Scalathon I started working on a compiler plugin to "cut out the
middle man" and translate things like "new Numeric(a).+(b)" directly
into "numeric.plus(a, b)" to avoid the object creation, and performance
problems I noticed in 2.9 (2-3x slow down).

Beyond the plugin (which isn't working yet) I've been going through a
lot of contortions to try to make sure Numeric is running as fast as
possible. So I definitely agree with Rex that it would be nice for
(relatively) low hanging optimization fruit to be picked--otherwise
users are forced to (each independently) determine which constructs are
the fastest and which to avoid.

But on the other hand, in HEAD the performance of my Numeric type class
is *much* better (based on recent tests), and I'm only seeing about a
(roughly) 4% penalty for using the implicit wrappers in the "normal"
case [1]. I'm not sure whether the compiler has started doing specific
optimizations or if it just happens to produce code that Hotspot has an
easier time optimizing. But it does lend some credence to Martin's
position.

That said, at the end of the day I would like things to be fast, and
will probably end up using whatever it takes to get that performance
(e.g. Arrays, while loops, the scala-CL compiler plugin, custom Numeric
type class, etc).

-- Erik

[1] I have even more convoluted wrappers that also do implicit
conversion of the second argument... these still don't run as fast as
direct code.

[Josh Suereth]

Neat.  I really look forward to what comes of this.

[Steven Obua]

Don't worry about "Kotlin", embrace "Babel-17" (http://www.babel-17.com) instead :-) It also has rudimentary tool support, and its newest incarnation v0.3.1 even has support for lenses!

By the way, a small tip how to get a MASSIVE boost for Scala: provide a Scala to Javascript compiler.

- Steven Obua

[Ben Hutchison]

On Thu, Jul 21, 2011 at 12:54 AM, Josh Suereth <joshua....@gmail.com> wrote:
> 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.

+1

That was one of two pieces of typeclass syntactic-sugar I was
advocating here: http://www.scala-lang.org/node/9757

-Ben

[Sébastien Bocq]

2011/7/20 Erik Osheim <er...@plastic-idolatry.com>

But on the other hand, in HEAD the performance of my Numeric type class
is *much* better (based on recent tests), and I'm only seeing about a
(roughly) 4% penalty for using the implicit wrappers in the "normal"
case [1]. I'm not sure whether the compiler has started doing specific
optimizations or if it just happens to produce code that Hotspot has an
easier time optimizing.

If your observation is correct then I would be relieved if compiler folks could reproduce and confirm that these are not conjectures anymore and that they have it well under control. It would be a pity that this change gets lost in a future release of the compiler. Me too, I can't help it, but my left imperative brain cringes when an implicit conversion occurs in the back for a simple infix operation.

Thanks,

Sébastien

[Ben Hutchison]

On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin....@epfl.ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua....@gmail.com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

IMO... this whole "complexity" issue risks becoming a major distraction.

I don't find Scala too complex. I came from Java, found parts of Scala
confusing or foreign at first, then got over it.

Scala should continue to focus on "making programming easier", above
"being popular" if need be. Making programming easier for easy
problems, but also and especially for hard problems, since any old
programming language can solve easy problems.

Scala got to its current, enviable position by a sincere, sustained
focus on tackling challenges using the best known methods and
technology (plus an awful lot of hard work). Regardless of whether
that technology was widely known or popular at the time of
introduction.

Problems will keep arising, things that emerge as difficult or awkward
to express in Scala; in type classes, variance, type inference, effect
tracking or elsewhere. We should not be ashamed to be the leader, to
go into battle with these problems and formulate solutions, even when
others yet deny they even exist.

-Ben

[Tony Morris]

Scala is not complex. Programming is hard.

Anti-intellectual disguises are self-deceiving distractions from the
fact. Giggle about it -- this "complex" issue is being taken way too
seriously.

[Meredith Gregory]

Dear All,

Actually, complexity is a major concern to the sensibilities. Who doesn't feel that needlessly complex just smells bad? With respect to language design, for any language, the question on my mind is always: does necessity dictate this complexity? Scala has played a very interesting balancing act, in my humble opinion. It has taken on the complexity of rationally reconstructing OO in a functional setting in order to achieve adoption. 

The rational reconstruction of OO -- on it's own -- represents needless complexity and for negative return on code reuse. However, it has a very positive side of smoothing out the transition for the vast majority of today's programmers. So, that's an absolutely fascinating trade-off that dances at the edge of necessity. Just like a musical setting -- where if there's no audience, Music tends not to show up, either -- in language design if there is no vibrant and active community around the language, there's often no magic happening with the language. So, there's a potent argument for taking on design choices that support adoption. 

However, a commitment to that approach is tantamount, in my mind, to a commitment to a certain agility. What happens when the bulk of the users have become facile with the new techniques to no longer need a trampoline? Then the necessity for certain design choices recedes. This agility is to be contrasted with an attitude of binary compatibility uber alles that freezes design choices that are demonstrably unsound. 

For my money, i would look to distribution and concurrency as the principal drivers over everything else for the next several years.  Concurrency is the area where necessary complexity dominates. This is widely supported in the literature and amply borne out in the experience of any seasoned programmer. If we believe that types really are a significant win in programming language design -- so much so as to go to the trouble to build an incredibly sophisticated type system -- why did types go out the window for Scala actors? In the one place where the programmer really, really needs automated support (such as from the compiler), namely concurrency, a model was put forward that didn't even type the messages -- which by all rights should be immutable structures and easily typed!

If anything, typing should be pushed further! There are lots of results now that could be used as the basis for driving language design that supports typed checking of concurrent behavior - not just structure. 

i'm not concerned about IDE, personally. i still use emacs after 28 years. i've tried all the IDE's. i disciplined myself to use IntelliJ nearly exclusively for a year just to make sure i gave these wannabes their due. None of them match up to emacs, in my experience. However, if Kotlin or any of the other emerging language designs has the agility to make concurrency their principal thrust, and has the goods to deliver excellent solutions that genuinely support the programmer who is building large scale distributed and concurrent systems, that will be where the bulk of programmers gravitate in a very short time -- if experience is any guide.

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

[Sébastien Bocq]

2011/7/21 Tony Morris <tonym...@gmail.com>

Scala is not complex. The problems it addresses are complex.

--
Sébastien

[martin odersky]

Hi Greg,

It's an interesting point of view, but I don't subscribe to it. For me OO is very much central to Scala, and to programming in general. I would not know how I could have done the collection libraries - and, nowadays, reflection - without the powerful OO capabilities of Scala. So it is not at all a trampoline for me. In fact, it's the more interesting part of Scala, whereas its FP capabilities are pretty standard.

See it another way: Scala's OO abstractions are a very flexible form of ML modules + mixin modules. If you say, OO is a trampoline, would you say the same for advanced module systems? Every language I know of that shuns both objects and advanced modules eventually succumbs to the global namespace fallacy. That is, there are some aspects of the language where a name can be used globally only once. In any large system that problem will then lead to naming policies where your `module' is part of your method names.

Cheers

 -- Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Sergei]

I honestly tried couple times in my life to get deeper into the IntelliJ and to make it the primary tool for a new project. Both times I rolled back to either Eclipse or NetBeans, unsatisfied. Now that I think about it, the main attraction of IntelliJ appears to be the wide variety of refactoring actions and relatively flat "in your face" menu structure, giving appearance of rich functionality. 

Yet I realized that I no longer refactor as much as I used to in my early programming days. I take more time to think about the high-level outline of the program and basically just copy it from my mind into IDE, enriching it with code details along the way. I used to just start coding right after I got *some* idea about it, which would inevitably require multiple refactoring passes later on. As to the IntelliJ's flattened menu structure and numerous keyboard shortcuts, some people find it appealing, but I personally do not. I guess it is a matter of taste.

So, at a risk of sounding snobbish, I would assert that IntelliJ is mostly a premium IDE for beginner programmers. Yes, some people start with it and stay with it long past their "coming of age" phase, yet I would argue that NetBeans was more productive for more experienced guys like me, and Eclipse is just an overall best-rounded platform that accommodates the widest range of programming styles. Just my personal opinion, based on first-hand experience.

Now, we need to realize that Eclipse started as a Java rewrite of IBM's venerable VisualAge for C++, the most advanced IDE at the time, significant chunks of which were written in Prolog, which helped codify the insane complexity of C++ and thus enabled the killer VisualAge feature - semantic referential search. 

IBM did not stop at donating his crown jewel to the Java ecosystem, it kept supporting it for years on end with the effort on order of fifty man-years per year. The apparent target was of course Microsoft's Visual Studio, yet Eclipse also effectively killed off multiple commercial Java IDE hopefuls, and presently is squeezing IntelliJ really hard.

I personally do not believe that Kotlin is primarily a reaction to Scala's complexity. I think it is an answer to the huge competitive threat that the Scala/Eclipse/Typesafe presents to Java/IntelliJ/JetBrains. Martin and Typesafe team have to be mentally and operationally prepared for former friends becoming competitors and even enemies now that the lines in the Scala game of domination are drawn much more clearly.

Once the situation is looked at from that angle, the executive opinions regarding the best course of action are bound to shift. For instance, instead of keeping polishing Scala the language, perhaps more attention is going to be paid to expanding Scala the platform - for instance, taking the LLVM one-man project and boosting it into an effort capable to quickly deliver "native" iOS Scala.

Or maybe to drastically accelerating the work on Scala translation onto parallel hardware code. The opportunity is there as the remainder of the enormous fiscal stimulus money is still slushing in VC coffers. Yet it could be gone in a blink of an eye with all those new sovereign defaults springing to public attention every week. The stimulus money given to the financiers may in effect be "called back" to save the governments. While not too late, please boost the Typesafe's valuation, quickly and shamelessly, and raise enough money (~$50,000,000) to expand the Scala platform beyond the threshold of self-sustainabilty.  

2011/7/20 Cédric Beust ♔ <ced...@beust.com>

[Francois]

On 21/07/2011 00:31, Steven Obua wrote:
> [...]

> By the way, a small tip how to get a MASSIVE boost for Scala: provide a Scala to Javascript compiler.

My little finer says that that wish may become reality in a not so far
future...

[Srirangan]

Please! This would be great! CoffeeScript is killing me! =)

--
Srirangan  |  About  Blog  GitHub  LinkedIn  Twitter

[Steven Obua]

On 21.07.2011, at 10:21, Francois wrote:

On 21/07/2011 00:31, Steven Obua wrote:

[...]

By the way, a small tip how to get a MASSIVE boost for Scala: provide a Scala to Javascript compiler.

My little finer says that that wish may become reality in a not so far future...

Now that you say that I looked up this one the net:

http://www.j2js.com/scala-demo/index.html

Is there already any (in)official action going on to make Javascript a standard target for Scala? That would be HUGE.

- Steven

[Francois]

Please! This would be great! CoffeeScript is killing me! =)

Just to be clear : I'm in no way involved with Scala compiler development, nor any kind of Scala to javascript compiler. It's just that I infered ideas from things read on the big internet (and of course, every thing published on Internet is REAL), that's it.

[Sébastien Bocq]

Hi Martin,

I think Greg makes a valid point. I do not question the need of composable namespaces with client specific state and types but I wonder if this _must_ be really rooted in a environment with OO style inheritance and method dispatching. While it is convenient, and mandatory on the JVM for Java interop, I think also the OO side induces a lot of unnecessary pain and suffering (and I come essentially from a OO background).

Cheers,
Sebastien

2011/7/21 martin odersky <martin....@epfl.ch>

[Andrew]

Hey all,

> So, at a risk of sounding snobbish, I would assert that IntelliJ is mostly a
> premium IDE for beginner programmers. Yes, some people start with it and
> stay with it long past their "coming of age" phase, yet I would argue that
> NetBeans was more productive for more experienced guys like me, and Eclipse
> is just an overall best-rounded platform that accommodates the widest range
> of programming styles. Just my personal opinion, based on first-hand
> experience.
>

That does, unfortunately, sound snobbish. I use IntelliJ as my primary
IDE, having previously used both Netbeans and Eclipse. I think you are
trying to make a general rule out of your personal opinion. Netbeans
may work for your style, IntelliJ works for others. We are not
beginners, we merely have a different programming style.

> IBM did not stop at donating his crown jewel to the Java ecosystem, it kept
> supporting it for years on end with the effort on order of fifty man-years
> per year. The apparent target was of course Microsoft's Visual Studio, yet
> Eclipse also effectively killed off multiple commercial Java IDE hopefuls,
> and presently is squeezing IntelliJ really hard.
>

Actually, judging by the fact that they have just released a bunch of
new IDEs for dynamic languages, they have a whole range of .Net
products, and have just brought out a competitor to XCode for
objective-c programming on the Mac, I would say they are doing pretty
well...

> I personally do not believe that Kotlin is primarily a reaction to Scala's
> complexity. I think it is an answer to the huge competitive threat that the
> Scala/Eclipse/Typesafe presents to Java/IntelliJ/JetBrains. Martin and
> Typesafe team have to be mentally and operationally prepared for former
> friends becoming competitors and even enemies now that the lines in the
> Scala game of domination are drawn much more clearly.
>

Really? I just think they are diversifying.

[Stefan Langer]

Hello,

I think I have read most of the thread skimming some longer posts and
I must say we have diverted from the path of seeing what Kotlin does
good and how we can encoporate this into Scala to what is better to
which IDE do we use and what is better.

In the long run only time will tell weather Kotlin will succeed or not
but I wouldn't bet my job on it. If it is the next dominant language I
will be sure to adapt and learn as it shouldn't be a problem once you
have understood the fundamental principles. Experience and some
statistics show that the actual language used doesn't have so much to
do with successful projects in the enterprise sector. It's more about
people and the social aspects but that is a different story.

Then again I'm not a tooling freak I like working with Eclipse but I
also use Emacs, Vim etc...
I like Scala and that is the reason why I use it. I like Ruby but
somehow I'm more into Scala lately.
I code Java because that is the way I make a living.
In the long run I hope that the language I like will be a language I
can make a living off. If not, so be it.

Summarized I do not care whether Kotlin is more or less complex then
Scala and I think this is an open ended debate that doesn't bare any
fruits. On the contrary the discussion how we can incorporate what is
good in Kotlin into Scala in a Scalaishway is a discussion which will
profit everybody.
Stop being afraid and adapt or you will be left behind cause the next
big thing is lurking around the corner.

-
Stefan

P.S.: Kotlin is a very weird name for me as a German. Reminds me
somehow of Quell Kot

[Steven Obua]

> In the long run I hope that the language I like will be a language I
> can make a living off. If not, so be it.
>

That's a very pragmatic and probably also very smart view of things. But none I could ever subscribe to :-)

- Steven

[Stefan Langer]

2011/7/21 Steven Obua <steve...@googlemail.com>:

>> In the long run I hope that the language I like will be a language I
>> can make a living off. If not, so be it.
>>
>
> That's a very pragmatic and probably also very smart view of things. But none I could ever subscribe to :-)

It's not like I want to but having family makes you pragmatic cause
the little ones want to eat and play and go have fun.
: )

[Steven Obua]

I totally understand that, it depends on your personal priorities and life choices so far. I think I can rephrase your statement so that it becomes true for me:

In the long run I hope that choosing the work I do in the way I do will make enough money for a family and little ones. If not, so be it.

- Steven

[Steven Obua]

I just found this interview via lambda the ultimate: http://drdobbs.com/architecture-and-design/231001802?pgno=2

So yes, there seem to be plans for a Scala to Javascript compiler. :-) But one year is a long time.

- Steven

[Lukas Rytz]

There's also http://scalagwt.gogoego.com/

Take a look at the "Source Code" tab in

http://dl.dropbox.com/u/12870350/scalagwt/Showcase.html#CwMenuBar

[Daniel Sobral]

On Wed, Jul 20, 2011 at 04:28, Naftoli Gugenheim <nafto...@gmail.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?

Not turning into C++.

C++ is a showcase example of the problems of a large language
footprint -- very hard to implement to spec, unexpected interaction
between features, difficulty in learning the language in full, etc.

--
Daniel C. Sobral

I travel to the future all the time.

[Dennis Haupt]

apart from unexpected interactions, i don't see a real problem

-------- Original-Nachricht --------
> Datum: Thu, 21 Jul 2011 11:00:22 -0300
> Von: Daniel Sobral <dcso...@gmail.com>
> An: Naftoli Gugenheim <nafto...@gmail.com>
> CC: scala-debate <scala-...@googlegroups.com>
> Betreff: Re: [scala-debate] new language "Kotlin" from jetbrains

[Erik Osheim]

On Thu, Jul 21, 2011 at 01:57:41AM +0200, S�bastien Bocq wrote:
> If your observation is correct then I would be relieved if compiler folks
> could reproduce and confirm that these are not conjectures anymore and that
> they have it well under control. It would be a pity that this change gets
> lost in a future release of the compiler. Me too, I can't help it, but my
> left imperative brain cringes when an implicit conversion occurs in the back
> for a simple infix operation.

Paul Phillips talked at Scalathon about how there wasn't enough
performance testing being done on the Scala libraries. Maybe the thing
to do is to try to write up my usecase and submit a patch that adds it
as a performance test (along with the performance numbers I see) so
people working on the compiler and libraries can try to preserve that
performance.

You're right that whatever change(s) improved things may have done so
unintentionally, and that it would be unfortunate if it later vanished
without warning.

-- Erik

[Sébastien Bocq]

2011/7/21 Erik Osheim <er...@plastic-idolatry.com>

Yes but it also occured to me that if you rely on these sort of runtime optimizations it will be really hard to ensure consistent performance across different platforms anyway. If you're performance minded, it may be still be more future proof to avoid these kind of implicit convertions. I can't help but think that infix notation is a syntactic issue and should be the handled properly by the compiler. I don't know all the ins and outs but there is already an unary_op, so why not not a infix_op?

--
Sébastien

[John Nilsson]

+1

I don't find Scala particularly complex either. If anything it is simpler than the popular alternatives. When coding Scala I often find myself smiling from how much easier everything is in Scala compared
to Java.

I don't know what people are referring to when they say Scala is a complex language. I guess it has something to do with the fact that Scala exposes some options that are simply not available in other language. Things that are comparably impossible in other language might be perceived as complex if you haven't seen it before, but in comparison complex vs impossible is still relatively simple!

I agree with the earlier assessment that the correct approach to the perceived complexity is to publish more example of how much simpler Scala is. OTOH who would do it? The simple things in Scala are so trivial that it hardly warrants a publication. Things that would take a series of bolg-posts to explain in Java can comfortable fit in a simple tweet when illustrated in Scala...

BR,
John

[Kevin Wright]

You could start by tweeting this line a few times:

    "Things that would take a series of bolg-posts to explain in Java can comfortably fit in a simple tweet when illustrated in Scala..."

:)

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Seth Tisue]

On Jul 20, 12:31 pm, martin odersky <martin.oder...@epfl.ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua.suer...@gmail.com>wrote:
> I think we will reconsider Jorge's suggestion:
>
>   implicit class Foo(..) { ... }
>
> to generate the wrapping method automatically.

Is there a ticket on this in Jira...?

I did find these links:
http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml
http://scala-programming-language.1934581.n4.nabble.com/Pre-SIP-Implicit-Classes-td2008170.html

--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Josh Suereth]

Looking back over this proposal, I'd like to offer a counter-proposal that includes most of what's in this proposal but with more support for Typeclass pimping.

Essentially a typeclass is a disassociation between the vtable of an abstract class and the data of a live object.   I think this disassociation is *very* powerful.  Right now, we do this disassociation with implicits and PIMPs, but I think with a bit of language support and an annotation or two, we could have this concept expressed within the bounds of core scala language *and* be able to optimise it down to passing a separate vtable from the object itself and gain some pretty crazy runtime speeds.

More to come this weekend hopefully.   So far my notes are a bit too disorganized to post, and I don't want to show syntax until I've ironed out what it should look like.

- Josh

[Daniel Sobral]

By the way, to those wanting String templates, there has been a plugin
providing that for Scala for a while now. I'm not sure if it works
with 2.9.0, but, anyway,

http://jrudolph.github.com/scala-enhanced-strings/Overview.scala.html

On Tue, Jul 19, 2011 at 20:29, 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.

[Meredith Gregory]

Dear Sebatien, Martin, et al,

First, i'm always delighted to see the depth, range and tolerance of differing points of view in the Scala community. If Kotlin did nothing else than generate this energetic debate, it would have accomplished a lot. i also see what a terrible writer i am. When i wrote my note it seemed clear to me that my primary points were, in today's environment

• language design needs to remain agile, flexible, adaptable
• distribution and concurrency should be the primary drivers occupying serious language design proposals for the next several years
• types should play a prominent role in the solutions to the challenges programmers face in designing and developing distributed and concurrent systems at scale

All the OO comments were subsidiary points exemplifying the subtleties of keeping a language design proposal on track with necessary complexity. Mostly, the point is that necessity is a moving target if we seek a mutually active and engaged relationship between language design community and developer community. So, i'm sorry to see that all the valuable and thoughtful attention went to the OO points.

If we were to have a serious discussion about namespace management, then i would have to address it on both practical and theoretical levels. On the practical level, Scala doesn't offer the same packaging for the ML functor+equality types. As a result, practical namespace management really gets to be irritatingly verbose. One of many practical examples can be found here. It's ugly, and though it composes, it gets much uglier when compositionally iterated. At industrial scales, i can tell you, this is so painful i have been sorely tempted to write code generators for Scala -- a very bad sign. i've yet to find a way to simplify this pattern and would be exceedingly grateful to anyone to alleviate my ignorance and incompetence on this point. 

On the theoretical level, once people fully take on board that names have structure, then when that idea is combined with the nominal approaches of Gabbay, Pitts, et al (see Fresh OCaml as an example), we get namespace management for free! Radestock and i showed some very compelling (if toy) examples in this paper. So, i'm forced to say that i completely agree with Sebastien. i absolutely acknowledge the fundamental importance of namespace management. As with all the other problems that OO was supposed to solve, i don't see it solving this one, either -- either at the practical level, or necessitated at the theoretical level. Instead, we see that both name and namespace management are much more easily and soundly managed with categorical technology. More importantly, i don't see the situation as binary. It's not OO/modules or no namespace management. There's rich world of alternative solutions out there just waiting for enterprising folks to put into a popular language design.

At the risk of droning on, let me add that the crucial point about concurrency is that this is truly the frontier. At the practical level, this is what the vast majority of developers are facing in their day jobs, now. At the theoretical level we still have not seen a compelling example of a categorical solution that aligns with Curry-Howard and gives a tractable model of mobile concurrency (which is far and away the most commonly encountered kind of concurrency that shows up in the web). Likewise, there is no compelling solution coming from type theory. We have only to look at Milner's efforts at the end of his life to see just how ill-suited category theory and type theory were to providing a substrate for reasoning about concurrent programming. At the end of the day, no one has told a compelling story showing that categorical composition aligns with parallel composition. So, practical demand for good support for concurrent programming is significantly mounting and theory is not yet up to the task! What an ideal situation! We get to discover and invent! And, we need to do it fast! Hurrah!

In the short term, i'm very glad to see, for example, the concurrent collections offering. Though it doesn't address many kinds of concurrency in the web, it feels directionally correct w.r.t the last two points in the bulleted list above.

Best wishes,

--greg

[Meredith Gregory]

Dear Josh,

i'm very much looking forward to this one!

Best wishes,

--greg