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

Re: new language "Kotlin" from jetbrains

75 replies
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
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
>

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
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
>>
Michael Stal
Joined: 2011-01-29,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
I am wondering why we are heavily discussing Kotlin. Guess, it is more a threat to other languages than to Scala. To be honest, I am rather sceptical about the inflation of new languages built by smart people but without much background in programming language design. It is not a single feature that matters but the overall structure of the language. Considering this, Scala has many benefits compared to all these new kids on the block. We don't have to be worry! The only real competitor would be F# if available on JVM if you ask me
just my 2c
  Michael

Sent from my iPad
On 24.07.2011, at 14:02, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

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 (viktor [dot] klang [at] gmail [dot] com" rel="nofollow">viktor [dot] klang [at] gmail [dot] com)> wrote:
> On Jul 24, 2011 6:20 AM, "Cédric Beust ♔" <cedric [at] beust [dot] com (cedric [at] beust [dot] com" rel="nofollow">cedric [at] beust [dot] com)> wrote:
>>
>> On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com (nivanov [at] gridgain [dot] com" rel="nofollow">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
>>
H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: new language "Kotlin" from jetbrains
i don't see a problem with 100 languages being developed (ide/tool support being another problem) as they are very similar to each other. i could probably switch between ceylon, scala, java, groovy and kotlin because i am already familiar with most of their concepts.

Am 24.07.2011 15:02, schrieb Michael Stal:
7E8DA639-9633-46CE-88F5-EC0E363D4A06 [at] gmail [dot] com" type="cite"> I am wondering why we are heavily discussing Kotlin. Guess, it is more a threat to other languages than to Scala. To be honest, I am rather sceptical about the inflation of new languages built by smart people but without much background in programming language design. It is not a single feature that matters but the overall structure of the language. Considering this, Scala has many benefits compared to all these new kids on the block. We don't have to be worry! The only real competitor would be F# if available on JVM if you ask me
just my 2c
  Michael

Sent from my iPad
On 24.07.2011, at 14:02, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com" rel="nofollow">joshua [dot] suereth [at] gmail [dot] com> wrote:

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" rel="nofollow">viktor [dot] klang [at] gmail [dot] com> wrote:
> On Jul 24, 2011 6:20 AM, "Cédric Beust ♔" <cedric [at] beust [dot] com" rel="nofollow">cedric [at] beust [dot] com> wrote:
>>
>> On Sat, Jul 23, 2011 at 3:13 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com" rel="nofollow">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
>>

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On 24/07/2011 15:23, HamsterofDeath wrote:
> i don't see a problem with 100 languages being developed (ide/tool
> support being another problem) as they are very similar to each other.

What is funny, is there has been always a lot of languages coming out
every year, and most of them are just ignored by the vast majority of
programmers... Not much debate, at least.

Now, the JVM ecosystem has less languages built on it, so they got more
audience because lot of programmers live on this ecosystem, and perhaps
look around, tired of the old syntax of Java.

That, and the fact most of these languages are done by big names in
programming language design, or big (or at least well known) companies.

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains
Hi Viktor,
2011/7/24 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>

Well, if you think that's magical and bad, consider default parameter values.

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
Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Re: new language "Kotlin" from jetbrains
2011/7/24 Cédric Beust ♔ <cedric [at] beust [dot] com>
Hi Viktor,
2011/7/24 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>

Well, if you think that's magical and bad, consider default parameter values.

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

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
Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains
2011/7/24 Jim Powers <jim [at] casapowers [dot] com>
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.

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

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Re: new language "Kotlin" from jetbrains
2011/7/24 Cédric Beust ♔ <cedric [at] beust [dot] com>
2011/7/24 Jim Powers <jim [at] casapowers [dot] com>
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.

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.

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
Peter C. Chapin 2
Joined: 2011-01-07,
User offline. Last seen 42 years 45 weeks ago.
RE: new language "Kotlin" from jetbrains

I wonder how the F# people feel about the possibility of Scala on .NET. J

 

Peter

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Michael Stal
Sent: Sunday, July 24, 2011 09:02
To: Josh Suereth
Cc: √iktor Ҡlang; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains

 

The only real competitor would be F# if available on JVM if you ask me

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

2011/7/24 Michael Stal <michael [dot] stal [at] gmail [dot] com>
I am wondering why we are heavily discussing Kotlin.

Probably because it's being developed by JetBrains, which guarantees that it will have top notch support from at least one major IDE right out of the gate. No other JVM language has had such support so far.
-- Cédric
Michael Stal
Joined: 2011-01-29,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
they should be afraid :-)However both Martin and Don are excellent language developers. And Don Syme has high respect for Scala

Sent from my iPad
On 24.07.2011, at 16:28, "Peter C. Chapin" <PChapin [at] vtc [dot] vsc [dot] edu> wrote:

I wonder how the F# people feel about the possibility of Scala on .NET. J

 

Peter

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Michael Stal
Sent: Sunday, July 24, 2011 09:02
To: Josh Suereth
Cc: √iktor Ҡlang; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains

 

The only real competitor would be F# if available on JVM if you ask me

channingwalton
Joined: 2008-09-27,
User offline. Last seen 2 weeks 1 day ago.
Re: new language "Kotlin" from jetbrains

On Jul 24, 7:20 am, Francois wrote:
> On 23/07/2011 23:07, Channing wrote:
> > But right now, a language like kotlin will be much more attractive to
> > them because it makes doing what they do now slightly easier.
>
> That's intersting too. And what make Kotlin suitable for that, and not
> Scala ? The too-much different syntax ?

Its not something that Kotlin is more suitable, it isn't. Kotlin is
just not scary for the average dev. I have had a few people come to me
saying they are 'scared' that scala is too difficult for them because
of all the FUD they see and hear.

Yes I am aware of Debasish's most excellent blogs. I am going to spend
more time studying them I think.

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Re: new language "Kotlin" from jetbrains


On Sun, Jul 24, 2011 at 3:00 PM, Channing <channingwalton [at] mac [dot] com> wrote:
On Jul 24, 7:20 am, Francois <fan [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> On 23/07/2011 23:07, Channing wrote:
> > But right now, a language like kotlin will be much more attractive to
> > them because it makes doing what they do now slightly easier.
>
> That's intersting too. And what make Kotlin suitable for that, and not
> Scala ? The too-much different syntax ?

Its not something that Kotlin is more suitable, it isn't. Kotlin is
just not scary for the average dev. I have had a few people come to me
saying they are 'scared' that scala is too difficult for them because
of all the FUD they see and hear.

Yes I am aware of Debasish's most excellent blogs. I am going to spend
more time studying them I think.

I've had similar experiences with developers being introduced to Scala.  There is some apprehension w.r.t. things like implicits.  Some education of how to use implicits and how to structure your own implicits typically address this concern.

--
Jim Powers
soc
Joined: 2010-02-07,
User offline. Last seen 34 weeks 5 days ago.
Re: Re: new language "Kotlin" from jetbrains

Hi,
>> i don't see a problem with 100 languages being developed (ide/tool
>> support being another problem) as they are very similar to each other.
>
> What is funny, is there has been always a lot of languages coming out
> every year, and most of them are just ignored by the vast majority of
> programmers... Not much debate, at least.
I guess the main difference is that they basically get much of their
audience by bashing Scala (and we are sadly participating here ...)

While the overall level of intellectual dishonesty is troubling, I think
it is a step into the right direction:
People don't have to explain anymore "Why Java is not enough anymore"
but can start with trying to differentiate themselves from Scala (and fail).

Bye

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On 24/07/2011 17:05, Michael Stal wrote:
> However both Martin and Don are excellent language developers. And Don
> Syme has high respect for Scala

And Martin Ordersky has high respect for Scala, IIRC.
F# is an interesting language, but its syntax might be different enough
not to be a direct concurrent, perhaps.

Chris Marshall
Joined: 2009-06-17,
User offline. Last seen 44 weeks 3 days ago.
RE: Re: new language "Kotlin" from jetbrains
> Date: Sat, 23 Jul 2011 14:07:21 -0700
> Subject: [scala-debate] Re: new language "Kotlin" from jetbrains
> From: channingwalton [at] mac [dot] com

> 5. Now the problem. Financial models of weird structured products is a nightmare. Across a single
> stack, from front to back office, the same domain is modelled in each
> system in multiple different ways and almost always in deeply unsatisfying ways.
+1
>
> I believe that any language that is not statically typed and supports higher order abstractions, > mixins, etc. will not be up to the job.
The authors of Kapital, which is the exotics system at JPMorgan (who basically invented exotics) and which is written in *Smalltalk* (yes, Smalltalk), would likely havethe opposite opinion on this.

Sylvain HENRY
Joined: 2009-05-28,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Le 22/07/2011 19:26, Nikita Ivanov a écrit :
03G4w [at] mail [dot] gmail [dot] com" type="cite"> > +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...
It depends on your real-world. I work with the High Performance Computing (HPC) community (yes, the ones that are still programming using Fortran, C and the like) and we need to get best performances with platforms such as SMP (NUMA), CELL, GPU or even SCC.

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

03G4w [at] mail [dot] gmail [dot] com" type="cite">
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



On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <dlandis [at] gmail [dot] com" target="_blank" rel="nofollow">dlandis [at] gmail [dot] com> wrote:
On Fri, Jul 22, 2011 at 10:10 AM, Maxime Lévesque
<maxime [dot] levesque [at] gmail [dot] com" target="_blank" rel="nofollow">maxime [dot] levesque [at] gmail [dot] com> 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.



-- 
Sylvain HENRY
PhD Student INRIA/LaBRI RunTime Team
Tel: +33 (0)6-70-94-86-76
http://hsyl20.fr
Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
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

 

 
Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
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

 

 
channingwalton
Joined: 2008-09-27,
User offline. Last seen 2 weeks 1 day ago.
Re: Re: new language "Kotlin" from jetbrains

On 25 Jul 2011, at 12:22, Chris Marshall wrote:

> >
> > I believe that any language that is not statically typed and supports higher order abstractions,
> > mixins, etc. will not be up to the job.
>
> The authors of Kapital, which is the exotics system at JPMorgan (who basically invented exotics) and which is written in *Smalltalk* (yes, Smalltalk), would likely have
> the opposite opinion on this.

Quite so. I know some of those guys and I'd forgotten about it.

Patrick Logan
Joined: 2011-07-25,
User offline. Last seen 42 years 45 weeks ago.
Re: RE: Re: new language "Kotlin" from jetbrains


On Monday, July 25, 2011 4:22:06 AM UTC-7, Chris Marshall wrote:
>
> I believe that any language that is not statically typed and supports higher order abstractions, > mixins, etc. will not be up to the job.
The authors of Kapital, which is the exotics system at JPMorgan (who basically invented exotics) and which is written in *Smalltalk* (yes, Smalltalk), would likely havethe opposite opinion on this.


Smalltalk has had very good tool support, going back 30 and more years. Very good programmers plus good tools plus a well-designed language can do wonders.
I would prioritize my choices for any project in that order...
1. Have good people2. Have good tools3. Have a good language
Sometimes you have to swap #2 and #3, and that works out well as long as you have #1. 
Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
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...)

channingwalton
Joined: 2008-09-27,
User offline. Last seen 2 weeks 1 day ago.
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 ;)

Raoul Duke
Joined: 2009-01-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

On Tue, Jul 26, 2011 at 1:24 PM, Channing wrote:
> Maybe they should just write a scala compiler plugin that prevents you
> using all the complex things in scala ;)

as much as that is tongue-in-cheek, i'd like to use it as an
opportunity to publicly disagree strongly with the meme in programming
language design subcultures that complexity can be hidden in /
abstracted away to one part of the language, leaving Joe New
Programmer safe and comfy. to that i say, "bullshit" because i've been
through that with java generics, and scala types, and &c.

sincerely. :-)

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