http://confluence.jetbrains.net/display/Kotlin/Welcome
The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:
http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala. I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile. The scenery up here on mile two, it's nice, you
should come give it a look.
P.S. First mile is long.
In short:
On the broader issue ... designing new programming languages is all
the rage now, with Go, Vala, Rust, BitC, Closure, Plaid, Agda, Coq,
Nemerle, Kotlin ... some of the reasons for doing so are better than
others, but in any case it's going to continue. Hopefully lessons will
be learned from all these efforts.
-- Jim
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking). If you just want add and subtract a few features, I would guess that forking could save you one hell of a lot of time compared to starting from scratch. It would also make the language a lot more familiar to current Scala users, thereby encouraging adoption. Who wants to learn a whole new language just for a few different features? But maybe the language differs from Scala more than I realize, since I only briefly skimmed the list of differences.
I think the tooling support became an intrinsic feature of the language (if not one of the most important one). I won't be surprised to see tooling support be a part of the language specifications in the future.
JetBrains has an enormous advantage on that (naturally). I think Scala has ~12-18 months before Kotlin hits the 1.0.
On 20/07/11 12:16, Rex Kerr wrote:
> (2) NotNull support
This is a step backwards.
It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise).
Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online.
In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption.
NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ... although I do
see the point about the psychology that, since '?' is a language
feature, you're expected to do things that way. But at least, if you
do use the feature, your code is typechecked and you can't get runtime
NPE's from Kotlin (as opposed to interop) code except for
initialization order problems.
-- Jim
Kotlin seems similar enough to Scala that I'm wondering why they didn't just fork Scala (assuming that the Scala license allows forking).
Who wants to learn a whole new language just for a few different features?
(3) Delegation/proxying (without a plugin).
NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ...
Rust has done away with nulls altogether, with the cost that
initialization is restricted. From
https://github.com/graydon/rust/wiki/Language-FAQ
"
Data values in the language can only be constructed through a fixed
set of initializer forms. Each of those forms requires that its inputs
already be initialized. A dataflow analysis (the typestate system used
elsewhere) ensures that local variables are initialized before use.
"
On the broader issue ... designing new programming languages is all
the rage now, with Go, Vala, Rust, BitC, Closure, Plaid, Agda, Coq,
Nemerle, Kotlin ... some of the reasons for doing so are better than
others, but in any case it's going to continue. Hopefully lessons will
be learned from all these efforts.
And I would add that the theory beside Scala and Kotlin is quite
different, and so it does not seems to be like "a few different
features", but much more like "some core fundation features are different"
--
Francois Armand
http://fanf42.blogspot.com
It's primarily a dig at Groovy and Groovy++ rather than Scala (despite of proclamation otherwise). Agree - kind of sad we have a whole mess w/Kotlin/Ceylon coming online.In the same time it underscores the need for 1st class Eclipse/IDEA tooling - probably #1 reason for slow-than-expected Scala adoption.
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:Maybe I'm the last guy to hear about things (it happens enough) but
there's this language here which looks like a more credible effort to be
a better/simpler scala than most:
http://confluence.jetbrains.net/display/Kotlin/Welcome
The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:
http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala. I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile. The scenery up here on mile two, it's nice, you
should come give it a look.
P.S. First mile is long.
They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.
The key ones to my eye are
(1) Extension functions. Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.
The things it has on top of Scala (nullablity and delegation) both seem to be designed well. But everything adds to the language footprint.
Cheers
-- Martin
On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:
The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:
http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
It makes me sad to see another whole implementation's worth of effort
being poured into something new
The key ones to my eye are
(1) Extension functions. Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.
Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.
On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:
[..]
It makes me sad to see another whole implementation's worth of effort
being poured into something new -- come on guys, you won't be enough
better than scala. I know everyone wants their own baby, but just
imagine what we might accomplish if we didn't all keep re-running the
same opening mile. The scenery up here on mile two, it's nice, you
should come give it a look.
P.S. First mile is long.
They've only gone (or planned) a few hundred yards in a direction that Scala hasn't already been.
-- Francois ARMAND http://fanf42.blogspot.com http://www.normation.com
On Wed, Jul 20, 2011 at 3:02 AM, martin odersky <martin....@epfl.ch> wrote:On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <ich...@gmail.com> wrote:On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips <pa...@improving.org> wrote:
The "What Kotlin has that Scala has not" list does read like a list of
things I would not mind having:
http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
It makes me sad to see another whole implementation's worth of effort
being poured into something newThe key ones to my eye are
(1) Extension functions. Much cleaner syntax and better performance than the Pimp My Library pattern using implicits.
Extension functions are shortsighted because they only make a class get new methods but do not let it implement new interfaces. In any mature framework, the primary reason for a method to exist is to implement some interface. Extension functions don't scale up to that usage.
I don't think that all features must "scale" in order to be worthwhile. While loops don't scale very well to complex collection manipulations, but Scala without them would be unusable for high-performance tasks. Operators don't scale beyond 3 or 4 characters before they're indecipherable gibberish, but Scala that required "a plus b" would be awkward to use. Tuples don't scale to large numbers of items, but that doesn't mean that they should be discarded in favor of HLists.
Even if we granted that scalability was a very high priority, I don't think the "mature framework" where your job is to glue together interfaces is the only or even the most interesting direction for scalability. Another area of scalability is to manage large quantities of runtime data, e.g. with millions of objects. GC is a pain in such situations, and there, I'd argue that PML is the one that doesn't scale (not unless escape analysis is perfect), because the cost-per-object gets increasingly expensive as the object churn goes up, while extension functions have fewer limits. There's also scalability in terms of number-of-lines-of-code, and right now the volume of boilerplate per PML pattern is more than an extension function would require (if you just need to add the capability, not the interface).
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).
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
From my experience and talking to other people, people do not measure complexity that way. The majority of people don't find Lisp simple.
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).
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."
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.
Cheers
-- Martin
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.
martin odersky wrote:
On Wed, Jul 20, 2011 at 10:26 AM, Ittay Dror <ittay...@gmail.com> wrote:
From my experience and talking to other people, people do not measure complexity that way. The majority of people don't find Lisp simple.
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).
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.
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)
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.
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
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
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.
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 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
+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.
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.
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 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!
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.
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.
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.
I never said scala was complex :)
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
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.
-- Francois ARMAND http://fanf42.blogspot.com http://www.normation.com
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).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.
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.
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-----
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.
By the way, a small tip how to get a MASSIVE boost for Scala: provide a Scala to Javascript compiler.
- Steven Obua
+1
That was one of two pieces of typeclass syntactic-sugar I was
advocating here: http://www.scala-lang.org/node/9757
-Ben
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.
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
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.
My little finer says that that wish may become reality in a not so far
future...
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...
Please! This would be great! CoffeeScript is killing me! =)
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
That's a very pragmatic and probably also very smart view of things. But none I could ever subscribe to :-)
- Steven
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
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.
-------- 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
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
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.