- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: new language "Kotlin" from jetbrains
On Tue, Jul 19, 2011 at 7:37 PM, Jim Balter <Jim [at] balter [dot] name> wrote:
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
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
Re: new language "Kotlin" from jetbrains
2011/7/19 Cédric Beust ♔ :
> On Tue, Jul 19, 2011 at 7:37 PM, Jim Balter 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
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.
"
Re: new language "Kotlin" from jetbrains
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" <odersky [at] gmail [dot] 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 [dot] suereth [at] gmail [dot] com>
> wrote:
>
>> +1
>>
>> I would just be happy if the compiler had sugar for easier typeclass
>> creation/definition and under the covers it still used implicits.
>> With the T : M syntax, if we also had a way to make methoda on M[T]
>> that take a T as their first parameter appear to be methods on T
>> without boilerplate, then most uses of implicit views are unecessary
>> for me.
>>
>> Another implicit view use case i would miss is acting as a "lens"
>> between two types that represent the same thing from different
>> libraries.
>>
>> So... implicits are more general, but I would love some
>> optimisations for common use cases.
>>
>> On Jul 20, 2011 10:07 AM, "John Nilsson" <john [at] milsson [dot] nu> wrote:
>> > On Wed, Jul 20, 2011 at 9:02 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch
>> >wrote:
>> >
>> >> Extension functions are shortsighted because they only make a
>> class get new
>> >> methods but do not let it implement new interfaces. In any mature
>> framework,
>> >> the primary reason for a method to exist is to implement some
>> interface.
>> >> Extension functions don't scale up to that usage.
>> >>
>> >
>> > I wonder. Is this really true in the face of type classes? It
>> seems to me
>> > that the approach of type classes scales almost better than
>> subclassing.
>> >
>> > I know you think this is a question of optimization. But there are
>> semantics
>> > to consider.
>> >
>> > a) Wrapping an object creates a new object, with identiy, hashing,
>> > monitoring and all that. Do we really want to rely on optimzation
>> to remove
>> > theese semantics?
>> >
>> > b) Doesn't wrapping interfere with type inference and typing in
>> general?
>> > Most of the time you _dont_ want to change the type of the wrapped
>> object.
>> > To return X or RichX...
>> >
>> > BR,
>> > John
Re: new language "Kotlin" from jetbrains
On Wednesday 20 July 2011, Josh Suereth wrote:
> 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!
Simplicity is far from a simple concept...
It's easy to think you can "simplify" some construct in an existing
language. Until, that is, you set about it and find that it's rife with
tradeoffs.
So yes, by all means, let them try. They could come up with a
significantly distinct language that has real advantages. That would be
good. I think it's a bit more likely they'll find that the tradeoffs
bite and and that it's far easier to imagine a simpler language than it
is to realize one.
> ...
Randall Schulz
Re: new language "Kotlin" from jetbrains
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
Re: new language "Kotlin" from jetbrains
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 ♔ <cedric [at] beust [dot] com>
Re: new language "Kotlin" from jetbrains
+1 (said it better than I could have)
On Jul 20, 2:07 pm, Josh Suereth wrote:
> 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 ♔
>
>
>
>
>
>
>
> > On Wed, Jul 20, 2011 at 9:02 AM, Josh Suereth 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
RE: new language "Kotlin" from jetbrains
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
From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Cédric Beust ?
Sent: July-20-11 1:06 PM
To: Josh Suereth
Cc: Martin Odersky; martin odersky; John Nilsson; Rex Kerr; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 9:02 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] 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
Re: new language "Kotlin" from jetbrains
On Jul 20, 1:05 pm, Cédric Beust ♔ wrote:
> On Wed, Jul 20, 2011 at 9:02 AM, Josh Suereth 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.
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
If you are in the majority, it's a silent one, then :-)
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
Re: new language "Kotlin" from jetbrains
On Jul 20, 12:31 pm, martin odersky wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth 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...
--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
Re: Re: new language "Kotlin" from jetbrains
2011/7/21 Seth Tisue <sethtisue [at] gmail [dot] com>
There is another dimension to it I forgot to highlight. While this pattern is fine to pimp existing libraries, it breaks the DRY principle in your own code when you design typeclasses with infix operations. For example, clients of Numeric are not supposed to invoke directly the methods of the trait. Instead, the typical usage scenario is to invoke operators defined in Ops by importing the mkNumericOps implicit conversion. The problem is that maintaining the _glue_ code in Ops duplicates the intent and can't entirely be checked by the compiler, e.g. it is easy to forget an operator because there is no common trait.
To word it as an embarassing question: why do I need to pimp my own Scala library? Therefore my suggestion (right or wrong) to add support for infix operators.
Cheers,
Sébastien
Re: Re: new language "Kotlin" from jetbrains
- Josh
On Thu, Jul 21, 2011 at 12:45 PM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:
Re: Re: new language "Kotlin" from jetbrains
On Thu, Jul 21, 2011 at 7:48 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Since "type" and "class" are already reserved keywords, I'm looking forward to the syntax discussion
--
Viktor Klang
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Re: Re: new language "Kotlin" from jetbrains
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
On Thu, Jul 21, 2011 at 11:32 AM, Seth Tisue <sethtisue [at] gmail [dot] com> wrote:
Re: Re: new language "Kotlin" from jetbrains
i'm very much looking forward to this one!
Best wishes,
--greg
On Thu, Jul 21, 2011 at 8:38 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
Re: new language "Kotlin" from jetbrains
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth
> 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
Re: new language "Kotlin" from jetbrains
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
On Thu, Jul 21, 2011 at 6:57 AM, Ben Hutchison <brhutchison [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
On Fri, Jul 22, 2011 at 11:51 AM, Justin du coeur <jducoeur [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
"Things that would take a series of bolg-posts to explain in Java can comfortably fit in a simple tweet when illustrated in Scala..."
:)
On 21 July 2011 16:09, John Nilsson <john [at] milsson [dot] nu> wrote:
--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev [dot] lee [dot] wright [at] gmail [dot] com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: 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
Re: new language "Kotlin" from jetbrains
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 22/07/11 01:25, Kevin Wright wrote:
> 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..."
>
> :)
>
You could, but your "sceptics" will call shenanigans on the fact that
this is unrelated to :"complexity." The right approach is dismissal.
This "complexity" circus is
a blatant excuse/euphemism to refuse to learn the topic at hand and
any attempts to alter this result in movement of the goal post.
- --
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4okuoACgkQmnpgrYe6r60bwQCfTXrq+LaUavAx/jhjy76716d2
nsAAoInlQcd+KorVXr5G8dZYd1znh8/5
=RxO2
-----END PGP SIGNATURE-----
Re: new language "Kotlin" from jetbrains
I mostly agree with your sentiment and find much inspiration in your writings, trying to learn as much as I can to improve my skills as developer.
I do think you are wrong in one vital aspect though. That is I don't agree that it is a productive use of energy and time to fight against the reality of human nature. The sad fact is that our profession is, and will be, littered with incompetence and stupidity. In fact we are all relatively incompetent and stupid compared to our future selves. So I accept the fact that this will be a constant force that shapes the impact and results of my work. Accepting this fact lets me divert energy and time designing for this reality rather than against it.
I find it very inspiring and humbling that the world manages to produce such wealth and abundance as it does _despite_ this apparent overflow of ignorance. There are some really curious forces at work here! ;-)
BR,
John
On Thu, Jul 21, 2011 at 10:58 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You don't agree, but in the next sentence you almost state precisely
what I said -- to "fight against human nature" (this what I call
pseudo-psychology by the way). Dismissing dishonesty is an
optimisation (productive use of energy and time). The alternative is
to address the dishonesty itself. Coincidentally, this is also a
reliable fire-lighting technique.
On 22/07/11 07:37, John Nilsson wrote:
> Tony, with all due respect.
>
> I mostly agree with your sentiment and find much inspiration in
> your writings, trying to learn as much as I can to improve my
> skills as developer.
>
> I do think you are wrong in one vital aspect though. That is I
> don't agree that it is a productive use of energy and time to fight
> against the reality of human nature. The sad fact is that our
> profession is, and will be, littered with incompetence and
> stupidity. In fact we are all relatively incompetent and stupid
> compared to our future selves. So I accept the fact that this will
> be a constant force that shapes the impact and results of my work.
> Accepting this fact lets me divert energy and time designing for
> this reality rather than against it.
>
> I find it very inspiring and humbling that the world manages to
> produce such wealth and abundance as it does _despite_ this
> apparent overflow of ignorance. There are some really curious
> forces at work here! ;-)
>
> BR, John
>
>
>
> On Thu, Jul 21, 2011 at 10:58 PM, Tony Morris
> tonymorris [at] gmail [dot] com (<tonymorris [at] gmail [dot] com>) wrote:
>
>> **
>>
> On 22/07/11 01:25, Kevin Wright wrote:
>>>> 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..."
>>>>
>>>> :)
>>>>
> You could, but your "sceptics" will call shenanigans on the fact
> that this is unrelated to :"complexity." The right approach is
> dismissal. This "complexity" circus is a blatant excuse/euphemism
> to refuse to learn the topic at hand and any attempts to alter this
> result in movement of the goal post.
>
>>
>>
- --
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4ooP4ACgkQmnpgrYe6r61PxQCeK0KjS2n0SxuHu0WFzErttFl6
mc4AoKYcCz4StPEmnF6RrKR8UBgyApWi
=TgW/
-----END PGP SIGNATURE-----
Re: new language "Kotlin" from jetbrains
I realised after posting that I wasn't really addressing your specific comment but rather a collection of my own thoughts triggered by it. My thoughts was focused on the question of when to use and promote "advanced but perceived complex techniques" and when to just adapt to the ignorance surrounding you by selecting and shaping your techniques to fit the give audience.
So I do agree that the first option is to require competence from your surrounding. However if the surroundings will not change (as is arguably the case for Scala on its way to mainstream) the next step is to adapt yourself to your surroundings.
BR,
John
On Thu, Jul 21, 2011 at 11:58 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
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
On Wed, Jul 20, 2011 at 9:57 PM, Ben Hutchison <brhutchison [at] gmail [dot] com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
Re: new language "Kotlin" from jetbrains
On Wednesday 20 July 2011, Meredith Gregory wrote:
> 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.
Forgive me for being a bit glib, but do you think the Expression Problem
inherently favors FP over OO?
> ...
>
> --greg
Randall Schulz
Re: new language "Kotlin" from jetbrains
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
On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:
--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967
Re: new language "Kotlin" from jetbrains
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 [dot] odersky [at] epfl [dot] ch>
Re: new language "Kotlin" from jetbrains
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
On Thu, Jul 21, 2011 at 2:06 AM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
Re: new language "Kotlin" from jetbrains
On Thu, Jul 21, 2011 at 6:06 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:
Do you mean sharing constraints? I am not sure what equality types in the sense of polymorphic equality would have to do with it.
I had a look at the example, but could not make much sense of it. At first glance, I would recommend to try to eliminate the type parameters in favor of abstract types. It seems that would cut down some repetition. Did you try a design along these lines?
The fresh names ideas are very interesting (in fact I was involved at the beginning, check out "A functional theory of local names", POPL 1994). I'll have to study your paper to see how it could be applied to modularity. But in any case that seems to be very much research; no actual language has a module system building on this theory.
Cheers
-- Martin
Re: new language "Kotlin" from jetbrains
I don't have access to serious statistics on this, but my (non statistically valid) reading of this is different, the vast majority of programmers are *not*
facing concurrency issues, at least not in the enterprise context, a huge chunk of which is the traditional web UI in front end to a relational DB,
granted that this code runs in a multithreaded VM, but they are writing code that react to a single user, the complexity there arises not from algorithmics problems,
but by the quantity of functionality (each functions being simple in isolation), i.e. complexity arising from massive cumulation of simple code. This has been the case for the
last 15 years, and the vast majority is still doing this. I think your statement applies to the cutting edge segment, and I'm pleased to see that Scala is adressing it, but in
order to become huge, a significant quantity of boring work needs to get done, IDE support being one of them, not just the quality of the IDE support itself, but the
"download and test drive experience". Every now and then I go to the Scala IDE site and install a new version to check things out, I always find
conflicting documentation (version X on one page, version X+2 on another page), then the installer tells me that I'm missing a dependency, etc.,
I could spend the time to solve this, but I don't know if it will be 15 minutes of 2 hours, the "short attention span" crowd that want to test drive Scala will
see this as a turn off, before they can even contemplate the powerfull features of Scala (which they might never even use....).
This kind of polishing work is boring and not attractive to open source unpaid developers, so it tends to not get done.
ML
Re: new language "Kotlin" from jetbrains
Thanks! i fully appreciate this perspective. There is almost always a lot of work to be done to provide the "it just works" experience and the effect it has on users. i remember early Lift put a lot of effort into this and i believe was one of the primary factors in Lift adoption. It certainly made a difference to me. i was still fiddling with a RoR sample after 18 hours of investment, while Lift just worked and required me to type in exactly 3 command lines to generate the project's beginning from archetype.
i disagree about the concurrency experience, though. As we get to a more and more service-based ecosystem the concurrency isn't coming from the user-thread, but in coordinating the different services needed to come together to provide a response to the user request. For example, the user is making a loan application, we need to verify property and credit history. These can (and should) be done in parallel. It's not about accessing the DB, anymore. It's about delegating work to different services -- some of which may be data stores. It's a mash, mash, mash-up world, Max! ;-)
Best wishes,
--greg
On Thu, Jul 21, 2011 at 10:04 AM, Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
RE: new language "Kotlin" from jetbrains
Specifically looking at these generics samples: http://confluence.jetbrains.net/display/Kotlin/Generics#Generics-Typeprojections
From: Razvan Cojocaru [mailto:pub [at] razie [dot] com]
Sent: July-25-11 12:01 PM
To: 'scala-debate [at] googlegroups [dot] com'
Subject: RE: [scala-debate] new language "Kotlin" from jetbrains
I don’t think anyone noted that this Kotlin inspired mightily from scala, with some tweaks like ‘fun’ instead of ‘def’ and <> instead of [] and a few things missing?
I don’t know other languages that made the same choices in syntax that scala did, so maybe they had other sources of inspiration but that’s highly unlikely since they keep it close to Java/JVM.
Heh,
Razvan
Re: new language "Kotlin" from jetbrains
>i disagree about the concurrency experience, though. As we get to a more and more service-based ecosystem the concurrency
>isn't coming from the user-thread, but in coordinating the different services needed to come together to provide a
>response to the user request. For example, the user is making a loan application, we need to verify property and
>credit history. These can (and should) be done in parallel.
Dear Greg, for the last decade this has been done with things like JMS (or plain old java threads),
granted that there is room for huge improvement in this area (JMS has got to be the uglyest API
around : type safety discarded, repeat yourself everywhere, swamps of XML, etc...),
my point was that even if you reduce the complexity of these areas to zero in such applications, you
will not have reduced it's total complexity by that much, since most of it comes from the
sheer number of simple features, screens, background tasks, reports, etc, rather than their individual
complexity. Now this is based on my perception of what constitutes the typical (or the vast majority of)
enterprise app, so my statement doesn't pretend to be a hard fact, simply my perception.
I do beleive the segment you are talking about truly exists, I just don't see it as "the vast majority".
My overall point was that attracting the hordes of short attention span "doing it for the money and could hardly care less about theoretical underpinings"
developers, has more to do with the impression they get in their first hour of trial, if they don't get a working IDE installed
and a project skeleton within 30 minutes, they will disqualify the whole language.
ML
2011/7/21 Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com>
Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 10:10 AM, Maxime Lévesque
wrote:
>
- Hide quoted text -
>>i disagree about the concurrency experience, though. As we get to a more
>> and more service-based ecosystem the concurrency
>>isn't coming from the user-thread, but in coordinating the different
>> services needed to come together to provide a
>>response to the user request. For example, the user is making a loan
>> application, we need to verify property and
>>credit history. These can (and should) be done in parallel.
>
> Dear Greg, for the last decade this has been done with things like JMS (or
> plain old java threads),
> granted that there is room for huge improvement in this area (JMS has got to
> be the uglyest API
> around : type safety discarded, repeat yourself everywhere, swamps of XML,
> etc...),
> my point was that even if you reduce the complexity of these areas to zero
> in such applications, you
> will not have reduced it's total complexity by that much, since most of it
> comes from the
> sheer number of simple features, screens, background tasks, reports, etc,
> rather than their individual
> complexity. Now this is based on my perception of what constitutes the
> typical (or the vast majority of)
> enterprise app, so my statement doesn't pretend to be a hard fact, simply my
> perception.
> I do beleive the segment you are talking about truly exists, I just don't
> see it as "the vast majority".
+1
As an "enterprise" Java developer myself I have to agree with Maxime
here. I appreciate Greg's perspective of course, but it simply is not
true in my experience in the financial sector over the past 5+ years
that the "vast majority" of developers are struggling with concurrency
issues. I would say the vast majority are not in fact.
Re: new language "Kotlin" from jetbrains
>
> As an "enterprise" Java developer myself I have to agree with Maxime
> here. I appreciate Greg's perspective of course, but it simply is not
> true in my experience in the financial sector over the past 5+ years> that the "vast majority" of developers are struggling with concurrency
> issues. I would say the vast majority are not in fact.
Couldn't agree more...
I think the whole idea that "vast majority of people are struggling with concurrency" is basically a white lie to a degree that starts to harm Scala community more than it helps.
JDK has come a long, long way with current java.util.concurrent utilities since mid 90s. Java libs provide (almost) perfect immutable collections and atomic. Etc, etc... Needless to say that most enterprise devs are not even exposed to heavy multithreading (and rightly so) b/c they are "shielded" by containers and managed APIs like web-frameworks, etc. And I can guarantee that people who migrate to Scala are 100% comfortable with various concurrency strategies in any JVM language. Doug Lea's book is read by anyone who wants to read... You see my point.
The whole idea of Scala (or other FP languages) being more friendly to concurrency than imperative languages like Java is rather a significant academic stretch that has little to do with real-world reality. That is a solution in a desperate search of a problem...
Scala's strength comes from completely different corners like DSL support, it's hybrid nature and type system that promote a new level abstractions and productivity for the developers. Slight concurrency friendliness is a nice cosmetics.
My points come from talking to enterprise customers and trying to promote Scala. The response on concurrency I often get is "who's f...ing cares about threads - how do I solve my real XYZ problem?" To a degree - I even stopped mentioning concurrency (actors, immutability) issues at all.
Everything is IMHO. --Nikita Ivanov, CEOGridGain Systemswww.gridgain.com
On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <dlandis [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
Models based on shared-state concurrent programming don't scale to many-core architectures and can't be efficiently applied to architectures with distributed memory (CELL, GPU, etc.). Moreover, applications built using this model do not compose.
This is why other models are under consideration (Transactional Memory, Data Parallelism, Actors, OpenCL-like, etc.). Most of them require tasks without global side-effects so that they can be executed by any device at any time, sometimes more than once. Data immutability may be required and is anyway helpful to manage distributed data replicates, especially on architectures that aren't cache-coherent. That's why FP languages are more friendly to parallelism, they already impose these constraints.
I agree that most mainstream developers won't need to care about all this, at least for a while... :-)
Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 11:26 AM, Nikita Ivanov wrote:
>> +1
>>
>> As an "enterprise" Java developer myself I have to agree with Maxime
>> here. I appreciate Greg's perspective of course, but it simply is not
>> true in my experience in the financial sector over the past 5+ years
>> that the "vast majority" of developers are struggling with concurrency
>> issues. I would say the vast majority are not in fact.
> Couldn't agree more...
> I think the whole idea that "vast majority of people are struggling with
> concurrency" is basically a white lie to a degree that starts to harm Scala
> community more than it helps.
> JDK has come a long, long way with current java.util.concurrent utilities
> since mid 90s. Java libs provide (almost) perfect immutable collections and
> atomic. Etc, etc... Needless to say that most enterprise devs are not even
> exposed to heavy multithreading (and rightly so) b/c they are "shielded" by
> containers and managed APIs like web-frameworks, etc. And I can guarantee
> that people who migrate to Scala are 100% comfortable with various
> concurrency strategies in any JVM language. Doug Lea's book is read by
> anyone who wants to read... You see my point.
> The whole idea of Scala (or other FP languages) being more friendly to
> concurrency than imperative languages like Java is rather a significant
> academic stretch that has little to do with real-world reality. That is a
> solution in a desperate search of a problem...
> Scala's strength comes from completely different corners like DSL support,
> it's hybrid nature and type system that promote a new level abstractions and
> productivity for the developers. Slight concurrency friendliness is a nice
> cosmetics.
> My points come from talking to enterprise customers and trying to promote
> Scala. The response on concurrency I often get is "who's f...ing cares about
> threads - how do I solve my real XYZ problem?" To a degree - I even stopped
> mentioning concurrency (actors, immutability) issues at all.
> Everything is IMHO.
> --
> Nikita Ivanov, CEO
> GridGain Systems
> www.gridgain.com
And here I am, concerned neither with concurrency nor DSLs, but
instead concerned with *productivity.* Scala's functional nature
allows me to be far more productive than languages without proper
support for functional programming, because it allows me to write more
code at a higher level of abstraction, and thus produce more in less
time with fewer bugs. For me, that's all that Scala is about, no more,
no less. Places where Scala forces me to write boilerplate due to the
lack of compile-time syntactic macros reduce my productivity, so
that's a big annoyance for me.
DSLs, in particular, I don't get the fuss about. Writing a DSL is just
programming, the kind of everyday programming that is used to solve
every software problem ever. You write an abstraction that helps to
solve your problem, and then you solve your problem using that
abstraction. If you've done it well, code written using those
abstractions ensures that you're not violating invariants of the
problem domain, expresses intent succinctly, and performs well.
There's no need to give this a special name - this is just
programming, and if the programs you're writing aren't like this, then
you're doing it wrong.
Scala makes it easier to do things right.
Kris
Re: new language "Kotlin" from jetbrains
It really does depend what area you're working in. I would agree that concurrency is a non-issue for the majority of programmers today, since the majority of programmers aren't doing stuff that's primarily realtime multi-user. But for most *juicy* problems that I find myself working on, concurrency is a front-and-center headache every day; hence, I find the Actors architecture quite exciting, because it is a fine solution to many such problems. (And functional styles are a fine way to approach the more data-parallel scaling problems, which we again hit routinely...)
On Fri, Jul 22, 2011 at 1:26 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
I can't imagine concurrency issues being an issue in the coming years either. Free lunch or not.
In my experience the biggest struggle is keeping agile on top of an ever growing pile of legacy features hacked into others in an effort to meet deadlines. It has nothing to do with algorithms or concurrency and everything to do with structure and modularity.
BR,
John
On Fri, Jul 22, 2011 at 6:49 PM, Ðavîd Låndïs <dlandis [at] gmail [dot] com> wrote:
Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <dlandis [at] gmail [dot] com> wrote:
Another +1 from me as well. The problems posed by concurrency are vastly overstated these days. First because the complexities are often neatly abstracted behind frameworks and technologies that have been honed for more than a decade (web and application servers mostly, but also individual libraries) and second because ever since Java 5, developers who actually have to deal with complex threading problems have had some very powerful and well designed tools to address them (j.c.util is the most obvious one, JCIP is also a very important part of this picture).
I also find it odd when so many people are saying that the multicore era is upon us and we need to start dealing with the "new" problem of massive parallelism.
We've been dealing with this ever since Java shipped 1.0 with the java.lang.Thread class in it. Switching from multi processors to multi cores adds no problem that JVM developers haven't already been exposed to for the better part of a decade.
It's nice to see new directions such as actors or ForkJoin being explored, but there's nothing really revolutionary happening there.
-- Cédric
Re: new language "Kotlin" from jetbrains
On 22 July 2011 18:00, Cédric Beust ♔ <cedric [at] beust [dot] com> wrote:
I'm not convinced by this. While it's true that existing Java features handle coarse-grained concurrency fairly well, and that certain scenarios are well catered for (one thread per request on a web app, for example), the same doesn't hold true for fine grained concurrency. There are a number of influences at work here:
- core counts are growing exponentially, Moore's law is still in effect
- chip manufactures are becoming increasingly power-conscious. One way this is being achieved without an overall reduction in MIPS is by using the same silicon area to hold more (smaller, simpler and slower) cores, there's also a trend towards managing power simply by turning cores off instead of playing with clock multipliers (this makes a lot of sense if you have >8 cores). This means that that core counts will multiply faster under moore's law than a simple transistor count would suggest.
- Running one thread per request doesn't load-balance well if some requests are much longer than others. Application design to work around this and break up requests is possible, at the cost of added complexity
- hardware is approaching the stage where core counts will exceed the number of requests that a given processor is likely to be serving simultaneously (in e.g. a web service). This exact tipping point is different for every application, but it breaks down the simple "pretend you're single-threaded" model that continues to work well in so many scenarios.
- Increasingly, we're looking to offload logic onto GPUs, where core counts are *already* in 3-digits. Imperative program designs don't cross-compile onto such hardware at all well.
- Frameworks and application servers must also be programmed! You can't very well state that "a framework will handle all my concurrency concerns for me" if you're actually writing the framework. Library authors need language support to be able to work this magic in the first place! Without it, you can expect libraries to be updated more slowly and to have more concurrency bugs - so the benefits tickle down.
- Features such as improved NIO support and delimited continuations also qualify as helpers and enablers of concurrency, it's not just about parallel collections, fork-join and actors.
Yes, it's not a big issue *yet*, and anyone who currently needs concurrency has (hopefully) already got a way to deal with it effectively. But then again, the full extent of massively-multicore isn't full upon us yet either - not unless you're working for CERN, or weather prediction, or some similar form of big-data crunching. Expect to see more programming of this nature in the future though...
--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev [dot] lee [dot] wright [at] gmail [dot] com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: 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
Fwd: Re: new language "Kotlin" from jetbrains
On Jul 24, 2011 6:20 AM, "Cédric Beust ♔" <cedric [at] beust [dot] com> wrote:
>
> On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
>>
>> After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code.
>>
>> Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...
>
>
> Fair enough, but you need to realize that implicits come with their own baggage as well. Just today, somebody on #scala was having a problem because he was not importing a particular implicit.
>
> Think about that for a second: the code was compiling and running fine, but it was not giving the expected result. Importing the correct implicit fixed the problem.
Well, if you think that's magical and bad, consider default parameter values. Omission will result in one result, addition will result in another, so honestly what's the difference?
>
> Anyone sufficiently experienced with Scala will probably get a gut feeling that might push them in the right direction to solve this kind of bug, but the simple fact that an import can fundamentally modify the behavior of a program is quite new for anyone familiar with Java.
>
> --
> Cédric
>
Re: Re: new language "Kotlin" from jetbrains
2011/7/24 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>
I'm not saying that it's good or bad, just that it's breaking an expectation that a lot of Java developers have, even if they don't realize it. When your program doesn't work as expected, you don't ask yourself "Did I forget an import?".
-- Cédric
Re: Re: new language "Kotlin" from jetbrains
There is a corollary to that when introducing an implicit into scope produces unexpected behavior.
This said, implicits are perhaps the most radical feature of Scala in comparison to other languages, therefore likely to garner the most criticism.
RE: default parameters - an IDE can trivially tell you about default parameters, it's somewhat trickier to tell you about implicits that are being applied.
Implicits rock regardless.
--
Jim Powers
Re: Re: new language "Kotlin" from jetbrains
This is pretty trivial, implicitly and even the REPL will tell you that. What might be useful is telling you which implicits woud be applied if you add such and such import. Since this list can potentially be very long, you might want to restrict it to only the root types that can be found in the current compilation unit.
-- Cédric
Re: Re: new language "Kotlin" from jetbrains
I didn't say it couldn't be done, clearly the compiler does it, for instance. From an IDE point-of-view telling the user about default parameters is relatively old-hat, telling them about implicits is not. See the post on this subject regarding what the Scala plugin for Idea has to do to work with implicits for details. --
Jim Powers
Re: Fwd: Re: new language "Kotlin" from jetbrains
feel free to use a language without implicits.
I think implicits, being a new toy, will take some time to reign in. See my nescala presentation for best practices.
I'm putting together a proposal to simplify most other implicit use cases. If we have optimal paths for extension methods *and* type traits, I think we can keep libraries sane for all but the really advanced problems.
On Jul 24, 2011 5:20 AM, "√iktor Ҡlang" <viktor [dot] klang [at] gmail [dot] com> wrote:> On Jul 24, 2011 6:20 AM, "Cédric Beust ♔" <cedric [at] beust [dot] com> wrote:
>>
>> On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com>
> wrote:
>>>
>>> After looking at Kotlin's extension functions in details I think it is a
> major blunder comparing to implicits in Scala. They may be easier to handle
> in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but
> there's no way I can do away without ability to convert one type to another
> at least here in GridGain's code.
>>>
>>> Just adding a function to another type (primitive "pimping") is just one
> specific application of implicits - and it seems that kotlin team wrongly
> assumed that that's the only one at all...
>>
>>
>> Fair enough, but you need to realize that implicits come with their own
> baggage as well. Just today, somebody on #scala was having a problem because
> he was not importing a particular implicit.
>>
>> Think about that for a second: the code was compiling and running fine,
> but it was not giving the expected result. Importing the correct implicit
> fixed the problem.
>
> Well, if you think that's magical and bad, consider default parameter
> values. Omission will result in one result, addition will result in another,
> so honestly what's the difference?
>
>>
>> Anyone sufficiently experienced with Scala will probably get a gut feeling
> that might push them in the right direction to solve this kind of bug, but
> the simple fact that an import can fundamentally modify the behavior of a
> program is quite new for anyone familiar with Java.
>>
>> --
>> Cédric
>>
RE: new language "Kotlin" from jetbrains
I don’t think anyone noted that this Kotlin inspired mightily from scala, with some tweaks like ‘fun’ instead of ‘def’ and <> instead of [] and a few things missing?
I don’t know other languages that made the same choices in syntax that scala did, so maybe they had other sources of inspiration but that’s highly unlikely since they keep it close to Java/JVM.
Heh,
Razvan
Re: new language "Kotlin" from jetbrains
On 25/07/2011 18:01, Razvan Cojocaru wrote:
> I don’t think anyone noted that this Kotlin inspired mightily from scala, with some tweaks
> like ‘fun’ instead of ‘def’ and <> instead of [] and a few things missing?
Well it makes sense... After all, I think they like (most of) Scala, actually, but wanted
to make a "simpler and more familiar to Java programmers" Scala... (and easier to tool)
Whether they are successful is another problem...
Whether the new language is up to modern programming needs (making good libraries, for
example) is another problem.
(I don't have an answer on these...)
Re: new language "Kotlin" from jetbrains
On Jul 26, 10:17 am, Philippe Lhoste wrote:
> Well it makes sense... After all, I think they like (most of) Scala, actually, but wanted
> to make a "simpler and more familiar to Java programmers" Scala... (and easier to tool)
Maybe they should just write a scala compiler plugin that prevents you
using all the complex things in scala ;)