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
Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
On Tue, Jul 19, 2011 at 7:37 PM, Jim Balter <Jim [at] balter [dot] name> wrote:
NotNullable is the default ... you have to append '?' to a type to
make it Nullable. That seems to me a step forward from both Java and
Scala, where all reference types are always Nullable ...

Agreed. I use this all the time in Fantom and it's really nice. The only downside is that question marks soon become overwhelming in code that is relies a lot on null. I guess it's one more incentive to drop the practice.
-- Cédric
jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
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.
"

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: new language "Kotlin" from jetbrains
On Wed, Jul 20, 2011 at 1:26 AM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:

Complex is a euphemism for, "I do not understand [that which is complex], and I will fight tooth and nail to ensure the situation stays that way."


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

--Russ P.

--
http://RussP.us
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
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
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
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:

I never said scala was complex :)


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

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

I think we will reconsider Jorge's suggestion:

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

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

Cheers

 -- Martin

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: 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
Derek Wyatt 2
Joined: 2011-02-12,
User offline. Last seen 42 years 45 weeks ago.
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.

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

 

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
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 ♔ <cedric [at] beust [dot] com>
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

Derek Wyatt 2
Joined: 2011-02-12,
User offline. Last seen 42 years 45 weeks ago.
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

Ben Hutchison 3
Joined: 2009-11-02,
User offline. Last seen 42 years 45 weeks ago.
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

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On 21/07/11 14:57, Ben Hutchison wrote:
> 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

Scala is not complex. Programming is hard.

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

Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Dear All,
Actually, complexity is a major concern to the sensibilities. Who doesn't feel that needlessly complex just smells bad? With respect to language design, for any language, the question on my mind is always: does necessity dictate this complexity? Scala has played a very interesting balancing act, in my humble opinion. It has taken on the complexity of rationally reconstructing OO in a functional setting in order to achieve adoption. 
The rational reconstruction of OO -- on it's own -- represents needless complexity and for negative return on code reuse. However, it has a very positive side of smoothing out the transition for the vast majority of today's programmers. So, that's an absolutely fascinating trade-off that dances at the edge of necessity. Just like a musical setting -- where if there's no audience, Music tends not to show up, either -- in language design if there is no vibrant and active community around the language, there's often no magic happening with the language. So, there's a potent argument for taking on design choices that support adoption. 
However, a commitment to that approach is tantamount, in my mind, to a commitment to a certain agility. What happens when the bulk of the users have become facile with the new techniques to no longer need a trampoline? Then the necessity for certain design choices recedes. This agility is to be contrasted with an attitude of binary compatibility uber alles that freezes design choices that are demonstrably unsound. 
For my money, i would look to distribution and concurrency as the principal drivers over everything else for the next several years.  Concurrency is the area where necessary complexity dominates. This is widely supported in the literature and amply borne out in the experience of any seasoned programmer. If we believe that types really are a significant win in programming language design -- so much so as to go to the trouble to build an incredibly sophisticated type system -- why did types go out the window for Scala actors? In the one place where the programmer really, really needs automated support (such as from the compiler), namely concurrency, a model was put forward that didn't even type the messages -- which by all rights should be immutable structures and easily typed!
If anything, typing should be pushed further! There are lots of results now that could be used as the basis for driving language design that supports typed checking of concurrent behavior - not just structure. 
i'm not concerned about IDE, personally. i still use emacs after 28 years. i've tried all the IDE's. i disciplined myself to use IntelliJ nearly exclusively for a year just to make sure i gave these wannabes their due. None of them match up to emacs, in my experience. However, if Kotlin or any of the other emerging language designs has the agility to make concurrency their principal thrust, and has the goods to deliver excellent solutions that genuinely support the programmer who is building large scale distributed and concurrent systems, that will be where the bulk of programmers gravitate in a very short time -- if experience is any guide.
Best wishes,
--greg

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

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com
Sebastien Bocq
Joined: 2008-12-18,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains


2011/7/21 Tony Morris <tonymorris [at] gmail [dot] com>
On 21/07/11 14:57, Ben Hutchison wrote:
> On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
>> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
>> wrote:
>>> I never said scala was complex :)
>> If you are in the majority, it's a silent one, then :-)
> IMO... this whole "complexity" issue risks becoming a major distraction.
>
> I don't find Scala too complex. I came from Java, found parts of Scala
> confusing or foreign at first, then got over it.
>
> Scala should continue to focus on "making programming easier", above
> "being popular" if need be. Making programming easier for easy
> problems, but also and especially for hard problems, since any old
> programming language can solve easy problems.
>
> Scala got to its current, enviable position by a sincere, sustained
> focus on tackling challenges using the best known methods and
> technology (plus an awful lot of hard work). Regardless of whether
> that technology was widely known or popular at the time of
> introduction.
>
> Problems will keep arising, things that emerge as difficult or awkward
> to express in Scala; in type classes, variance, type inference, effect
> tracking or elsewhere. We should not be ashamed to be the leader, to
> go into battle with these problems and formulate solutions, even when
> others yet deny they even exist.
>
> -Ben

Scala is not complex. Programming is hard.

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

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



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

--
Sébastien
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: new language "Kotlin" from jetbrains
Hi Greg,

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

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

Cheers

 -- Martin



On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> 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. 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:
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



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

Sebastien Bocq
Joined: 2008-12-18,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Hi Martin,

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

Cheers,
Sebastien

2011/7/21 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
Hi Greg,

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

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

Cheers

 -- Martin



On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> 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. 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:
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



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


John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
+1

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

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

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

BR,
John

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

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

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

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

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

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

-Ben

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: new language "Kotlin" from jetbrains
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..."
:)



On 21 July 2011 16:09, John Nilsson <john [at] milsson [dot] nu> wrote:
+1

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

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

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

BR,
John

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

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

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

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

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

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

-Ben




--
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
Seth Tisue 2
Joined: 2011-07-21,
User offline. Last seen 42 years 45 weeks ago.
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/

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Re: new language "Kotlin" from jetbrains
Looking back over this proposal, I'd like to offer a counter-proposal that includes most of what's in this proposal but with more support for Typeclass pimping.
Essentially a typeclass is a disassociation between the vtable of an abstract class and the data of a live object.   I think this disassociation is *very* powerful.  Right now, we do this disassociation with implicits and PIMPs, but I think with a bit of language support and an annotation or two, we could have this concept expressed within the bounds of core scala language *and* be able to optimise it down to passing a separate vtable from the object itself and gain some pretty crazy runtime speeds.
More to come this weekend hopefully.   So far my notes are a bit too disorganized to post, and I don't want to show syntax until I've ironed out what it should look like.
- Josh

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

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

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

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


Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Dear Sebatien, Martin, et al,
First, i'm always delighted to see the depth, range and tolerance of differing points of view in the Scala community. If Kotlin did nothing else than generate this energetic debate, it would have accomplished a lot. i also see what a terrible writer i am. When i wrote my note it seemed clear to me that my primary points were, in today's environment
  • language design needs to remain agile, flexible, adaptable
  • distribution and concurrency should be the primary drivers occupying serious language design proposals for the next several years
  • types should play a prominent role in the solutions to the challenges programmers face in designing and developing distributed and concurrent systems at scale
All the OO comments were subsidiary points exemplifying the subtleties of keeping a language design proposal on track with necessary complexity. Mostly, the point is that necessity is a moving target if we seek a mutually active and engaged relationship between language design community and developer community. So, i'm sorry to see that all the valuable and thoughtful attention went to the OO points.
If we were to have a serious discussion about namespace management, then i would have to address it on both practical and theoretical levels. On the practical level, Scala doesn't offer the same packaging for the ML functor+equality types. As a result, practical namespace management really gets to be irritatingly verbose. One of many practical examples can be found here. It's ugly, and though it composes, it gets much uglier when compositionally iterated. At industrial scales, i can tell you, this is so painful i have been sorely tempted to write code generators for Scala -- a very bad sign. i've yet to find a way to simplify this pattern and would be exceedingly grateful to anyone to alleviate my ignorance and incompetence on this point. 
On the theoretical level, once people fully take on board that names have structure, then when that idea is combined with the nominal approaches of Gabbay, Pitts, et al (see Fresh OCaml as an example), we get namespace management for free! Radestock and i showed some very compelling (if toy) examples in this paper. So, i'm forced to say that i completely agree with Sebastien. i absolutely acknowledge the fundamental importance of namespace management. As with all the other problems that OO was supposed to solve, i don't see it solving this one, either -- either at the practical level, or necessitated at the theoretical level. Instead, we see that both name and namespace management are much more easily and soundly managed with categorical technology. More importantly, i don't see the situation as binary. It's not OO/modules or no namespace management. There's rich world of alternative solutions out there just waiting for enterprising folks to put into a popular language design.
At the risk of droning on, let me add that the crucial point about concurrency is that this is truly the frontier. At the practical level, this is what the vast majority of developers are facing in their day jobs, now. At the theoretical level we still have not seen a compelling example of a categorical solution that aligns with Curry-Howard and gives a tractable model of mobile concurrency (which is far and away the most commonly encountered kind of concurrency that shows up in the web). Likewise, there is no compelling solution coming from type theory. We have only to look at Milner's efforts at the end of his life to see just how ill-suited category theory and type theory were to providing a substrate for reasoning about concurrent programming. At the end of the day, no one has told a compelling story showing that categorical composition aligns with parallel composition. So, practical demand for good support for concurrent programming is significantly mounting and theory is not yet up to the task! What an ideal situation! We get to discover and invent! And, we need to do it fast! Hurrah!
In the short term, i'm very glad to see, for example, the concurrent collections offering. Though it doesn't address many kinds of concurrency in the web, it feels directionally correct w.r.t the last two points in the bulleted list above.
Best wishes,
--greg

On Thu, Jul 21, 2011 at 2:06 AM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:
Hi Martin,

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

Cheers,
Sebastien

2011/7/21 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
Hi Greg,

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

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

Cheers

 -- Martin



On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> 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. 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:
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



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





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains
Dear Josh,
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:
Looking back over this proposal, I'd like to offer a counter-proposal that includes most of what's in this proposal but with more support for Typeclass pimping.
Essentially a typeclass is a disassociation between the vtable of an abstract class and the data of a live object.   I think this disassociation is *very* powerful.  Right now, we do this disassociation with implicits and PIMPs, but I think with a bit of language support and an annotation or two, we could have this concept expressed within the bounds of core scala language *and* be able to optimise it down to passing a separate vtable from the object itself and gain some pretty crazy runtime speeds.
More to come this weekend hopefully.   So far my notes are a bit too disorganized to post, and I don't want to show syntax until I've ironed out what it should look like.
- Josh

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

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

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

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





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com
Maxime Lévesque
Joined: 2009-08-18,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
 
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.

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

 
On Thu, Jul 21, 2011 at 2:06 AM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:
Hi Martin,

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

Cheers,
Sebastien

2011/7/21 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
Hi Greg,

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

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

Cheers

 -- Martin



On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> 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. 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:
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



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





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Sebastien Bocq
Joined: 2008-12-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

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

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

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

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


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
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Dear Maxime,
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:
 
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.

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

 
On Thu, Jul 21, 2011 at 2:06 AM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:
Hi Martin,

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

Cheers,
Sebastien

2011/7/21 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
Hi Greg,

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

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

Cheers

 -- Martin



On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> 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. 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:
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



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





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com




--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Re: new language "Kotlin" from jetbrains
This I hope to address in my proposal.  Again, the syntax needs some work, but the Numeric#Ops type boilerplate would be gone.
- Josh

On Thu, Jul 21, 2011 at 12:45 PM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:

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

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

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

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


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

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
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:
This I hope to address in my proposal.  Again, the syntax needs some work, but the Numeric#Ops type boilerplate would be gone.

Since "type" and "class" are already reserved keywords, I'm looking forward to the syntax discussion

 

- Josh

On Thu, Jul 21, 2011 at 12:45 PM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:

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

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

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

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


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




--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
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-----

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
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> wrote:

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


odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
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:
Dear Sebatien, Martin, et al,
First, i'm always delighted to see the depth, range and tolerance of differing points of view in the Scala community. If Kotlin did nothing else than generate this energetic debate, it would have accomplished a lot. i also see what a terrible writer i am. When i wrote my note it seemed clear to me that my primary points were, in today's environment
  • language design needs to remain agile, flexible, adaptable
  • distribution and concurrency should be the primary drivers occupying serious language design proposals for the next several years
  • types should play a prominent role in the solutions to the challenges programmers face in designing and developing distributed and concurrent systems at scale
All the OO comments were subsidiary points exemplifying the subtleties of keeping a language design proposal on track with necessary complexity. Mostly, the point is that necessity is a moving target if we seek a mutually active and engaged relationship between language design community and developer community. So, i'm sorry to see that all the valuable and thoughtful attention went to the OO points.
If we were to have a serious discussion about namespace management, then i would have to address it on both practical and theoretical levels. On the practical level, Scala doesn't offer the same packaging for the ML functor+equality types.

Do you mean sharing constraints? I am not sure what equality types in the sense of polymorphic equality would have to do with it.
 
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. 

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?

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.

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
Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
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-----

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Yeah, sorry about that.

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:

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


Maxime Lévesque
Joined: 2009-08-18,
User offline. Last seen 42 years 45 weeks ago.
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>
Dear Maxime,
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:
 
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.

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

 
On Thu, Jul 21, 2011 at 2:06 AM, Sébastien Bocq <sebastien [dot] bocq [at] gmail [dot] com> wrote:
Hi Martin,

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

Cheers,
Sebastien

2011/7/21 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
Hi Greg,

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

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

Cheers

 -- Martin



On Thu, Jul 21, 2011 at 7:42 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> 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. 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:
On Thu, Jul 21, 2011 at 2:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> On Wed, Jul 20, 2011 at 6:02 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>
> wrote:
>>
>> I never said scala was complex :)
>
> If you are in the majority, it's a silent one, then :-)

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

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

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

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

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

-Ben



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



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





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com




--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

dlandis
Joined: 2009-09-30,
User offline. Last seen 3 years 3 weeks ago.
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.

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
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:

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.

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


John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Another +1 from me.

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:
On Fri, Jul 22, 2011 at 10:10 AM, Maxime Lévesque
<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.

nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
> +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, CEOGridGain Systemswww.gridgain.com



On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <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> 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.

Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
Okay, *somebody* has to push back here.  Just to point out the counter-example, I haven't built a single system in the past ten years that *hasn't* lost an enormous amount of time to dealing with concurrency issues.  Sure, straightforward websites can largely ignore this, but communications-oriented technologies get screwed by this stuff all the time.  (At my last company, even one of the architects couldn't manage to get the locking patterns right in our middleware layer, leading to some nasty and subtle bugs.)
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:
> +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, CEOGridGain Systemswww.gridgain.com



On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <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> 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.


Kris Nuttycombe
Joined: 2009-01-16,
User offline. Last seen 42 years 45 weeks ago.
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

Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: new language "Kotlin" from jetbrains

Quote

 

 

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

 

… if you actually meant that, you would be kidding me. A web server helps deal with your concurrent issues how exactly? Application servers, all they do in this respect is provide basically an actor framework (MDB) and transactional extensions for synchronous calls (EJB) with the underlying thread and resource pools.

 

Concurrency is hard. It has been abstracted for the past 5 decades or more, in numerous dedicated languages, environments, libraries and it’s still hard! If it wasn’t, we wouldn’t be talking about it. And when you go distributed, it’s that much harder. If it wasn’t we wouldn’t be talking about it!

 

In my experience, most java developers screw up badly whenever approaching concurrency but luckily, they don’t have to, most of the time. So you’d be right to observe that most of the time they don’t have issues with concurrency J

 

I’m glad to see that so many folks in this thread are having an easy time with concurrency, but then 80% of us think are better drivers than average! I wonder how many actually use concurrency constructs on a monthly or weekly basis to justify said skill.

 

Having said that, concurrency has nothing to do with scala. Are you talking about the “actor library” or the “parallel collection library”? Scala doesn’t even have a concurrency primitive like “synchronized” I think it’s a method..

 

Just saying…

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Cédric Beust ?
Sent: July-22-11 1:01 PM
To: Ðavîd Låndïs
Cc: Maxime Lévesque; Meredith Gregory; Sébastien Bocq; martin odersky; Ben Hutchison; Josh Suereth; John Nilsson; Rex Kerr; scala-debate
Subject: Re: [scala-debate] 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:

 

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.

 

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

 

 

 

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: new language "Kotlin" from jetbrains


On 22 July 2011 18:00, Cédric Beust ♔ <cedric [at] beust [dot] com> wrote:

On Fri, Jul 22, 2011 at 9:49 AM, Ðavîd Låndïs <dlandis [at] gmail [dot] com> wrote:

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.

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

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
Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
On Fri, Jul 22, 2011 at 11:03 AM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:

Quote

 

 

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

 

… if you actually meant that, you would be kidding me. A web server helps deal with your concurrent issues how exactly?


By running all the servlets and queries in a thread pool that's completely hidden from you. When was last time you were writing a servlet and you had to worry about spawning threads to run them all in parallel?  

Application servers, all they do in this respect is provide basically an actor framework (MDB) and transactional extensions for synchronous calls (EJB) with the underlying thread and resource pools.

 

Concurrency is hard. It has been abstracted for the past 5 decades or more, in numerous dedicated languages, environments, libraries and it’s still hard! If it wasn’t, we wouldn’t be talking about it. And when you go distributed, it’s that much harder. If it wasn’t we wouldn’t be talking about it!


Nobody is saying concurrency is easy, just that it's a non-issue for a lot of developers.  

In my experience, most java developers screw up badly whenever approaching concurrency but luckily, they don’t have to, most of the time. So you’d be right to observe that most of the time they don’t have issues with concurrency J

 

I’m glad to see that so many folks in this thread are having an easy time with concurrency, but then 80% of us think are better drivers than average! I wonder how many actually use concurrency constructs on a monthly or weekly basis to justify said skill.


I don't have an easy time with concurrency. Never have, probably never will. It's always difficult to write correct multithreaded code, especially if you are writing a framework (meaning: you're exposing these facilities to others). The point is that *I* am going through these pains so that users of my framework won't have to. For example, I make it possible for them to test the thread safety of their code without having to even spawn a single thread, with features such as:
@Test(threadPoolSize = 10, invocationCount = 10000)public void test() { ... }
-- Cédric
nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
Excellent point & example, Cedric. 
Concurrency is most of the time hidden and well insulated these days. Devs that need to deal with it accumulated enough proficiency by now - as well as JDK tools/frameworks matured dramatically over the last few years.
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com



On Fri, Jul 22, 2011 at 11:12 AM, Cédric Beust ♔ <cedric [at] beust [dot] com> wrote:
On Fri, Jul 22, 2011 at 11:03 AM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:

Quote

 

 

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

 

… if you actually meant that, you would be kidding me. A web server helps deal with your concurrent issues how exactly?


By running all the servlets and queries in a thread pool that's completely hidden from you. When was last time you were writing a servlet and you had to worry about spawning threads to run them all in parallel?  

Application servers, all they do in this respect is provide basically an actor framework (MDB) and transactional extensions for synchronous calls (EJB) with the underlying thread and resource pools.

 

Concurrency is hard. It has been abstracted for the past 5 decades or more, in numerous dedicated languages, environments, libraries and it’s still hard! If it wasn’t, we wouldn’t be talking about it. And when you go distributed, it’s that much harder. If it wasn’t we wouldn’t be talking about it!


Nobody is saying concurrency is easy, just that it's a non-issue for a lot of developers.  

In my experience, most java developers screw up badly whenever approaching concurrency but luckily, they don’t have to, most of the time. So you’d be right to observe that most of the time they don’t have issues with concurrency J

 

I’m glad to see that so many folks in this thread are having an easy time with concurrency, but then 80% of us think are better drivers than average! I wonder how many actually use concurrency constructs on a monthly or weekly basis to justify said skill.


I don't have an easy time with concurrency. Never have, probably never will. It's always difficult to write correct multithreaded code, especially if you are writing a framework (meaning: you're exposing these facilities to others). The point is that *I* am going through these pains so that users of my framework won't have to. For example, I make it possible for them to test the thread safety of their code without having to even spawn a single thread, with features such as:
@Test(threadPoolSize = 10, invocationCount = 10000)public void test() { ... }
-- Cédric

Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: new language "Kotlin" from jetbrains

Sorry – I didn’t consider this as real help

 

listen (port, servlets) {

   request => new Thread {

      def run { servlets.foreach {_.matchAndProcess(request)} }

}

 

Add a thread pool in 10 more lines of code. Actually you don’t need one, just spawn new threads with an upper limit – it’s cleaner that way.

 

In my view, what the web server does is authorization, authentication, all the HTTP stuff, SSL, mapping, forwarding etc. concurrency is the last thing and close to nothing really. Just a thread pool.

 

Dealing with concurrency in the *implementation of the servlet* – that’s where the trouble lies. If the world was synchronous and instantaneous, we wouldn’t have this issue J

 

Sorry for forking the discussion. Fork over…

 

Cheers,

Razie

 

From: cbeust [at] gmail [dot] com [mailto:cbeust [at] gmail [dot] com] On Behalf Of Cédric Beust ?
Sent: July-22-11 2:12 PM
To: Razvan Cojocaru
Cc: Ðavîd Låndïs; Maxime Lévesque; Meredith Gregory; Sébastien Bocq; martin odersky; Ben Hutchison; Josh Suereth; John Nilsson; Rex Kerr; scala-debate
Subject: Re: [scala-debate] new language "Kotlin" from jetbrains

 

On Fri, Jul 22, 2011 at 11:03 AM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:

Quote

 

 

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

 

… if you actually meant that, you would be kidding me. A web server helps deal with your concurrent issues how exactly?

 

By running all the servlets and queries in a thread pool that's completely hidden from you. When was last time you were writing a servlet and you had to worry about spawning threads to run them all in parallel?

 

Application servers, all they do in this respect is provide basically an actor framework (MDB) and transactional extensions for synchronous calls (EJB) with the underlying thread and resource pools.

 

Concurrency is hard. It has been abstracted for the past 5 decades or more, in numerous dedicated languages, environments, libraries and it’s still hard! If it wasn’t, we wouldn’t be talking about it. And when you go distributed, it’s that much harder. If it wasn’t we wouldn’t be talking about it!

 

Nobody is saying concurrency is easy, just that it's a non-issue for a lot of developers.

  

In my experience, most java developers screw up badly whenever approaching concurrency but luckily, they don’t have to, most of the time. So you’d be right to observe that most of the time they don’t have issues with concurrency J

 

I’m glad to see that so many folks in this thread are having an easy time with concurrency, but then 80% of us think are better drivers than average! I wonder how many actually use concurrency constructs on a monthly or weekly basis to justify said skill.

 

I don't have an easy time with concurrency. Never have, probably never will. It's always difficult to write correct multithreaded code, especially if you are writing a framework (meaning: you're exposing these facilities to others). The point is that *I* am going through these pains so that users of my framework won't have to. For example, I make it possible for them to test the thread safety of their code without having to even spawn a single thread, with features such as:

 

@Test(threadPoolSize = 10, invocationCount = 10000)

public void test() { ... }

 

-- 

Cédric

 

nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: new language "Kotlin" from jetbrains
I think we agree to disagree on this one :)
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com



On Fri, Jul 22, 2011 at 11:51 AM, Justin du coeur <jducoeur [at] gmail [dot] com> wrote:
2011/7/22 Nikita Ivanov <nivanov [at] gridgain [dot] com>
Concurrency is most of the time hidden and well insulated these days.

True if and only if you are working on something that is structurally similar to a web application.  That's probably the single most common use case, sure -- but most interesting and complex problems aren't structured like that.
Looking at it a different way: I think that the majority of *programmers* today don't need to worry about concurrency much, because most of them are working on a very small category of problems.  But the majority of distinctly-different programming *problems* do involve concurrency rather deeply.  
Devs that need to deal with it accumulated enough proficiency by now - as well as JDK tools/frameworks matured dramatically over the last few years.

I don't buy it.  I am very good at concurrent programming -- the vast majority of the projects I've worked on in the past dozen years, both client- and server-side, have required serious multi-threading -- and I still find it difficult drudge-work.  Most frameworks are by no stretch of the imagination good enough for the general case, just for a few specific ones.  (The frameworks that *are* really powerful are the ones we're talking about here, like Actors...)

Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: new language "Kotlin" from jetbrains
2011/7/22 Nikita Ivanov <nivanov [at] gridgain [dot] com>
Concurrency is most of the time hidden and well insulated these days.

True if and only if you are working on something that is structurally similar to a web application.  That's probably the single most common use case, sure -- but most interesting and complex problems aren't structured like that.
Looking at it a different way: I think that the majority of *programmers* today don't need to worry about concurrency much, because most of them are working on a very small category of problems.  But the majority of distinctly-different programming *problems* do involve concurrency rather deeply.  
Devs that need to deal with it accumulated enough proficiency by now - as well as JDK tools/frameworks matured dramatically over the last few years.

I don't buy it.  I am very good at concurrent programming -- the vast majority of the projects I've worked on in the past dozen years, both client- and server-side, have required serious multi-threading -- and I still find it difficult drudge-work.  Most frameworks are by no stretch of the imagination good enough for the general case, just for a few specific ones.  (The frameworks that *are* really powerful are the ones we're talking about here, like Actors...)
jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: new language "Kotlin" from jetbrains

On Fri, Jul 22, 2011 at 11:51 AM, Justin du coeur wrote:
> 2011/7/22 Nikita Ivanov
>>
>> Concurrency is most of the time hidden and well insulated these days.
>
> True if and only if you are working on something that is structurally
> similar to a web application.  That's probably the single most common use
> case, sure -- but most interesting and complex problems aren't structured
> like that.
> Looking at it a different way: I think that the majority of *programmers*
> today don't need to worry about concurrency much, because most of them are
> working on a very small category of problems.  But the majority of
> distinctly-different programming *problems* do involve concurrency rather
> deeply.

The original claim being disputed here is "At the practical level,
this is what the vast majority of developers are facing in their day
jobs, now" and it appears that you dispute it too.

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

I would like to add my experience of what the average dev faces in the
financial world I inhabit from time to time, and where I think scala
fits in as a superior choice of language over Java/Kotlin/etc.

1. Concurrency / parallelism is not understood at all, but actually
doesn't matter, because...

2. Apps rely on frameworks (hibernate etc) and coarse transactions to
keep data out of trouble - kind of. When apps mysteriously misbehave,
an army of support people leap into action (because banks can afford
it) and fix/hack/slash until all is 'apparently' well.

3. Scaling and performance is not an issue except in some rare cases
such as high frequency trading or pricing. Most apps only need to deal
with a few thousand users at most if they are user facing. Back end
systems also rarely deal with much when compared with systems
operating at the internet scale. A database, a few queues and a few
processes is usually about it. Performance can be a problem simply
because people do stupid things.

4. Devs just follow the Java patterns as decreed by framework writers
and architects - its the law - and it usually works sufficiently well
for people to get their bonuses.

5. Now the problem. The biggest, most expense, ugliest, bug-ridden,
cut and paste mess is almost always in modelling the domain. 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.

Java is simply not up to the job of modelling these domains.
Furthermore, 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 point is that the average Java dev has absolutely no idea how a
type system like scala's together with FP can help them. Words like
monad, monoids and endofunctors make them run a mile.

Show these people how scala can model these nasty domains, explicitly,
and you might get the dev's attention and that of senior IT management
who lament the cost of building, maintaining and rewriting these
systems every 3-5 years.

But right now, a language like kotlin will be much more attractive to
them because it makes doing what they do now slightly easier.

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
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

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
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

fanf
Joined: 2009-03-17,
User offline. Last seen 2 years 30 weeks ago.
Re: Re: new language "Kotlin" from jetbrains

On 23/07/2011 23:07, Channing wrote:
> [...]
> 5. Now the problem. The biggest, most expense, ugliest, bug-ridden,
> cut and paste mess is almost always in modelling the domain. 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.
>
> Java is simply not up to the job of modelling these domains.
> Furthermore, 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 point is that the average Java dev has absolutely no idea how a
> type system like scala's together with FP can help them. Words like
> monad, monoids and endofunctors make them run a mile.
>
> Show these people how scala can model these nasty domains, explicitly,
> and you might get the dev's attention and that of senior IT management
> who lament the cost of building, maintaining and rewriting these
> systems every 3-5 years.

Now, that's intersting, and a sufficiently uncommon advantage of Scala
to be noticed. Well, Debasish has a blong full of such examples[1], but
nonetheless it's worth noticing.

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

[1]
http://debasishg.blogspot.com/2011/06/composing-heterogeneous-dsls-in-sc...
for example.

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