In the long run, what kind of developers do you think will make most use of scala?

[egervari]

In the long run, what kind of developers do you think will make most use of scala?

I see so much potential, it's great.

I am a bit concerned that the language is harder than a typical language like Java or C#. I know that is strange to say... because it's simpler. It's a strange conundrum. 

For example, the elegant and concise syntax would probably make the language easy to learn, but it's so different from the mainstream languages that for most, it might be a bit harder (at least at first).

There are number of concepts that I think make this language applicable to only university graduates+, or at least people who can think that way. The functional nature is pretty similar to many courses at the university I went to... and seeing things like case matching reminds me of my proof and computer science courses. I don't think I would have seen lists split up as x:xs anywhere else but university either.

Of course, I think one could get by without knowing any of those things, so here again we have a weird match of simplicity and something that could be intellectually challenging for a lot of people.

And of course, while the language definitely drops a lot of special cases and unneeded bloat from Java, I think the amount to learn compared to Java is far more. Scala does have it's own special cases that are perplexing. I find usages of _ to partial functions and curried functions... and wildcards in function calls and _* in pattern matching... and in packages... to be a little strange and I'm still not at a point where I get correctly guess how to use it all the time in those cases that don't come up very often. A lot of the times I'm just not even aware that I can use it... so I'm off doing something entirely different when it comes to functions.

I think pattern matching alone is more complicated than a lot of things in Java. It's remarkably powerful, and under the surface, it does follow a lot of Scala's fundamentals. Still, it doesn't appear that way when a person first approaches it.

Concepts like covariant and contravariant are not known to most developers either.

Then there's things that I see I can do in Scala that I don't think I would ever want to do... mainly because the power creates some confusion and things can become too concise that they are hard to understand. All this power definitely comes with great responsibility, and I don't think the average developer is up to the challenge.

What are your thoughts?

Ken

[Ricky Clarkson]

2009/10/23 Ken Egervari <ken.egervari@...>:
> In the long run, what kind of developers do you think will make most use of
> scala?

Competent developers who need to target the JVM for some reason.

> I am a bit concerned that the language is harder than a typical language
> like Java or C#. I know that is strange to say... because it's simpler. It's
> a strange conundrum.

It is harder in some respects.  For example, only its inventor
completely understands its type system enough to say what it should
(rather than what it does) do in all respects.  That said, the syntax
is smaller than Java's and C#'s, and the parts of the type system a
programmer normally interacts with are quite simple and most of the
complexity is because of the Java interop (boxing for arrays,
manifests, erasure, existential types).

> For example, the elegant and concise syntax would probably make the language
> easy to learn, but it's so different from the mainstream languages that for
> most, it might be a bit harder (at least at first).

That's ok.  There are problems with Java and C# that really need
addressing, and Scala addresses some of those.

> There are number of concepts that I think make this language applicable to
> only university graduates+, or at least people who can think that way.

Functional programming wasn't covered in the slightest in my degree.
To my knowledge, having studied at the University of Salford then then
worked there for 5 years, only one lecturer there knows what a lambda
is.

So in that respect I don't have any advantage and don't struggle with
functional programming concepts (until one goes further than monads
and arrows).

I don't think it's wrong to aim at people who can think that way.

> The
> functional nature is pretty similar to many courses at the university I went
> to... and seeing things like case matching reminds me of my proof and
> computer science courses. I don't think I would have seen lists split up as
> x:xs anywhere else but university either.

Because most mainstream languages don't emphasise immutability, the
linked list isn't used that much there.

> Of course, I think one could get by without knowing any of those things, so
> here again we have a weird match of simplicity and something that could be
> intellectually challenging for a lot of people.

That's two positives, doesn't sound like a weird match to me.

> I think pattern matching alone is more complicated than a lot of things in
> Java. It's remarkably powerful, and under the surface, it does follow a lot
> of Scala's fundamentals. Still, it doesn't appear that way when a person
> first approaches it.

Consider the alternatives to pattern matching in Java.  instanceof and
casts, or the Visitor pattern.  Given those I'll take pattern
matching, thanks.  The javac compiler is the best Java source code
I've ever read (it was there that I first encountered a fold), but
it's full of visitors that don't help readability because there's no
better way in Java.

> Concepts like covariant and contravariant are not known to most developers
> either.

C# 4 gains covariance and contravariance in type parameter
declarations.. interface IEnumerable<out T> ..
Java 5 gained covariant return types.
Java 5 wildcards added use-site covariance and contravariance.  The
concepts are known, or easy to understand, to competent developers.

> Then there's things that I see I can do in Scala that I don't think I would
> ever want to do... mainly because the power creates some confusion and
> things can become too concise that they are hard to understand.

That's not a fault of the language.  That said, I hope the IDEs
provide some refactors or views that help with comprehension.  E.g.,
my boss would benefit, in, say, list map (_ * 3) filter (_ % 2 != 0),
from seeing most of the missing dots (i.e., the ones for the
non-symbolic method names).

> All this
> power definitely comes with great responsibility, and I don't think the
> average developer is up to the challenge.
> What are your thoughts?

Employ or create better than average developers.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Jesper Nordenberg]

Ken Egervari wrote:
> For example, the elegant and concise syntax would probably make the
> language easy to learn, but it's so different from the mainstream
> languages that for most, it might be a bit harder (at least at first).

It's not really that different. C# has local type inference and
closures. Python and Ruby have closures.

The OO part is very similar to Java and C# with the addition of traits.

The things that are new to "mainstream programmers" are mainly pattern
matching, implicits and the advanced type system with type members,
higher order types etc. But you really don't have to have deep
understanding of the type system to use Scala effectively.

> Concepts like covariant and contravariant are not known to most
> developers either.

Well, variance exist in Java generics too, but it's much more
complicated to get right in Java than in Scala. C# chose the more simple
Scala variant.

> Then there's things that I see I can do in Scala that I don't think I
> would ever want to do... mainly because the power creates some confusion
> and things can become too concise that they are hard to understand. All
> this power definitely comes with great responsibility, and I don't think
> the average developer is up to the challenge.

Examples?

Yes, Scala is a complex language, but every feature adds value to the
language (with the possible exception of XML support). Could it be made
simpler? Yes, but then you would (in many cases) sacrifice either
performance or Java interoperability.

/Jesper Nordenberg

[Bill Ramsay]

Don't get me wrong, I love Scala and think it will be very successful, but much of it is too obscure and difficult for the 'real world'.    Most large systems in corporate America last a long time, which means that the people who wrote the system move on after it's done.   But software is never done - some junior programmer is usually assigned to update/maintain/change the code.   It better be clear or the poor person will end up changing careers.    Simple is ALWAYS better.   I think some of the 'elegance' so loved by academics will simply fade away in time.

Bill

[Goddard Jiri]

"Simple is ALWAYS better.   I think some of the 'elegance' so loved by
academics will simply fade away in time."

 

simple, but not too much simple. the "elegance" speaks about quality. quality comes with years of experience. today, things are maybe simple, but not elegant after all. it's like mcd's - you come, you choose, you pay, you eat. but what if you want breakfst menu after 11? plus you simply get fat :P

scala is not simple, but you don't get fat.

 

scala beginner, jiri

 

p. s.: i take scala pattern matching easy, it' like ls -l sca??

On Fri, Oct 23, 2009 at 3:47 PM, Bill Ramsay <ramsayw1@...> wrote:

Don't get me wrong, I love Scala and think it will be very successful, but
much of it is too obscure and difficult for the 'real world'.    Most large
systems in corporate America last a long time, which means that the people
who wrote the system move on after it's done.   But software is never done -
some junior programmer is usually assigned to update/maintain/change the
code.   It better be clear or the poor person will end up changing careers.
Simple is ALWAYS better.   I think some of the 'elegance' so loved by
academics will simply fade away in time.

Bill
--
View this message in context: http://www.nabble.com/In-the-long-run%2C-what-kind-of-developers-do-you-think-will-make-most--use-of-scala--tp26026053p26026769.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
web: http://dredwerkz.ic.cz
group: http://groups.google.com/group/dr3dwerkz
icq: 218 659 431

[Ricky Clarkson]

Simple is always better, sure.  And my Scala code is simpler than my Java code.

2009/10/23 Bill Ramsay <ramsayw1@...>:

>
>
> Don't get me wrong, I love Scala and think it will be very successful, but
> much of it is too obscure and difficult for the 'real world'.    Most large
> systems in corporate America last a long time, which means that the people
> who wrote the system move on after it's done.   But software is never done -
> some junior programmer is usually assigned to update/maintain/change the
> code.   It better be clear or the poor person will end up changing careers.
> Simple is ALWAYS better.   I think some of the 'elegance' so loved by
> academics will simply fade away in time.
>
> Bill
> --
> View this message in context: http://www.nabble.com/In-the-long-run%2C-what-kind-of-developers-do-you-think-will-make-most--use-of-scala--tp26026053p26026769.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[egervari]

On Fri, Oct 23, 2009 at 9:24 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

It is harder in some respects.  For example, only its inventor

completely understands its type system enough to say what it should
(rather than what it does) do in all respects.  That said, the syntax
is smaller than Java's and C#'s, and the parts of the type system a
programmer normally interacts with are quite simple and most of the
complexity is because of the Java interop (boxing for arrays,
manifests, erasure, existential types).

I would agree that all the high-level stuff and types are pretty basic and self-explanatory. It's also possible to use a lot of it without knowing how it works, which is a plus. I would disagree that it's simpler just because of the syntax - because scala definitely makes that up with libraries - and those have to be learned just the same. Also, for all the things scala makes easier, there's about an equal number of gotchas and quirks that replace them, especially in the functional side of things.

 

> For example, the elegant and concise syntax would probably make the language
> easy to learn, but it's so different from the mainstream languages that for
> most, it might be a bit harder (at least at first).

That's ok.  There are problems with Java and C# that really need
addressing, and Scala addresses some of those.

I totally agree. I am so happy that Scala has finally fixed them. I wonder if the masses will accept the changes though and we'll see a shift.

 

Functional programming wasn't covered in the slightest in my degree.

To my knowledge, having studied at the University of Salford then then
worked there for 5 years, only one lecturer there knows what a lambda
is.

So in that respect I don't have any advantage and don't struggle with
functional programming concepts (until one goes further than monads
and arrows).

I don't think it's wrong to aim at people who can think that way.

I don't think it's "wrong" either - just different. And of course, people resist things that are different, which I think may be a barrier to adoption. This is not scala's fault at all either. 

My university was pretty big on functional ideas. In fact, several of my first year courses were teaching languages like Miranda before they even taught C/C++ or Java. I also had a course where I did Scheme (I didn't like it at all though... so clunky and unnatural... at least for me at the time).

 

> The
> functional nature is pretty similar to many courses at the university I went
> to... and seeing things like case matching reminds me of my proof and
> computer science courses. I don't think I would have seen lists split up as
> x:xs anywhere else but university either.

Because most mainstream languages don't emphasise immutability, the
linked list isn't used that much there.

I think immutability is part of it - recursion and link lists in general are not concepts that people use in everyday, mainstream programming. Almost all the time people use ArrayList compared to a linked list. Algorithms on linked lists were only ever discussed in my computer science courses. I can't say I've used a Linked List many times in the last decade of my programming career, so writing recursive algorithms on them is something that I am out of practice with. A think a lot of developers, by and large, will have the same experiences.

 

> Of course, I think one could get by without knowing any of those things, so
> here again we have a weird match of simplicity and something that could be
> intellectually challenging for a lot of people.

That's two positives, doesn't sound like a weird match to me.

Again, I think they are positives too. I can see some people not getting the intellectually challenging aspects though, and wanting to revert back to more conventional programming ideas.

 

> I think pattern matching alone is more complicated than a lot of things in
> Java. It's remarkably powerful, and under the surface, it does follow a lot
> of Scala's fundamentals. Still, it doesn't appear that way when a person
> first approaches it.

Consider the alternatives to pattern matching in Java.  instanceof and
casts, or the Visitor pattern.  Given those I'll take pattern
matching, thanks.  The javac compiler is the best Java source code
I've ever read (it was there that I first encountered a fold), but
it's full of visitors that don't help readability because there's no
better way in Java.

Don't get me wrong, I think pattern matching is a wonderful addition and it's extremely powerful. At first though, it seems like "magic". It feels like it's a second language within a language - something akin to a computer science textbook than actually writing a real program.

I think it takes a solid understanding to see that it is naturally fits in scala, knowing how the partial functions are created and applied to each case, and viewing the world that way. Once I got this, patterns became a lot more natural for me to think and reason about. 

However, this is not apparent just by looking at it the first few times. I can see a lot of people getting bewildered by it, either trying to "memorize the magic" or just not using it.

 

> Concepts like covariant and contravariant are not known to most developers
> either.

C# 4 gains covariance and contravariance in type parameter
declarations.. interface IEnumerable<out T> ..
Java 5 gained covariant return types.
Java 5 wildcards added use-site covariance and contravariance.  The
concepts are known, or easy to understand, to competent developers.

I would argue that 97% (made up number) of Java developers don't care and have never heard of them. In Java, you can program and not care for the most part. In scala, I think one needs to learn these to use the language better.

 

> Then there's things that I see I can do in Scala that I don't think I would
> ever want to do... mainly because the power creates some confusion and
> things can become too concise that they are hard to understand.

That's not a fault of the language.  That said, I hope the IDEs
provide some refactors or views that help with comprehension.  E.g.,
my boss would benefit, in, say, list map (_ * 3) filter (_ % 2 != 0),
from seeing most of the missing dots (i.e., the ones for the
non-symbolic method names)

I don't think this is a fault of the language. It does however mean that "best practices", "patterns" and "conventions" need to come to light so that way developers can automatically know the exact small subset of things that "work" and will be "understood" rather than use everything available in their programs. This kind of thing takes time for the community to establish and make large circles of the community aware of it.

 

[Daniel Sobral]

On Fri, Oct 23, 2009 at 11:24 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

> Concepts like covariant and contravariant are not known to most developers
> either.

C# 4 gains covariance and contravariance in type parameter
declarations.. interface IEnumerable<out T> ..
Java 5 gained covariant return types.
Java 5 wildcards added use-site covariance and contravariance.  The
concepts are known, or easy to understand, to competent developers.

Actually, these concepts are hard. Particularly contravariance. I never thought of a good example of contravariance, until people started discussing making Ordering contravariant. That's a perfect example! Unfortunately, it wasn't made contravariant, so I can't use it to demonstrate contravariance... :-(

 

Back to Scala, though, at least Scala won't let you shoot yourself in the foot. Its error messages could suggest using the B1 >: B pattern to get around some common obstacles, though.

 

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Stefan Langer-4]

I think simple is a meaningless term. Define what is simple. From a beginners standpoint simple is a class that has tons of comments written all over it explaining each thing in detail while an experienced developer will curse at all the clutter going on.
The more experienced you get in a language the easier and more natural it will become to reading it. In the not so distant futures beginners will have a totally different view on programming then we do now ( hopefully ;) ) and it might be second nature to them to know pattern matching. When looking at code that used it they might say "This is very elegant and easy to understand" while the same code in a non functional OO style might seem to them clunky and awkward.

What I'm saying is basically simple has a different meaning to each individual and should not be used as a measure to choose one style over the other.

2009/10/23 Bill Ramsay <ramsayw1@...>

Don't get me wrong, I love Scala and think it will be very successful, but
much of it is too obscure and difficult for the 'real world'.    Most large
systems in corporate America last a long time, which means that the people
who wrote the system move on after it's done.   But software is never done -
some junior programmer is usually assigned to update/maintain/change the
code.   It better be clear or the poor person will end up changing careers.
Simple is ALWAYS better.   I think some of the 'elegance' so loved by
academics will simply fade away in time.

Bill
--
View this message in context: http://www.nabble.com/In-the-long-run%2C-what-kind-of-developers-do-you-think-will-make-most--use-of-scala--tp26026053p26026769.html
Sent from the Scala - User mailing list archive at Nabble.com.

[Ricky Clarkson]

Iterable and Comparable should suffice as examples for both.

2009/10/23 Daniel Sobral <dcsobral@...>:

> On Fri, Oct 23, 2009 at 11:24 AM, Ricky Clarkson <ricky.clarkson@...>
> wrote:
>>
>> > Concepts like covariant and contravariant are not known to most
>> > developers
>> > either.
>>
>> C# 4 gains covariance and contravariance in type parameter
>> declarations.. interface IEnumerable<out T> ..
>> Java 5 gained covariant return types.
>> Java 5 wildcards added use-site covariance and contravariance.  The
>> concepts are known, or easy to understand, to competent developers.
>>
> Actually, these concepts are hard. Particularly contravariance. I never
> thought of a good example of contravariance, until people started discussing
> making Ordering contravariant. That's a perfect example! Unfortunately, it
> wasn't made contravariant, so I can't use it to demonstrate
> contravariance... :-(
>
> Back to Scala, though, at least Scala won't let you shoot yourself in the
> foot. Its error messages could suggest using the B1 >: B pattern to get
> around some common obstacles, though.
>
>>
>> --
>> Daniel C. Sobral
>>
>> Something I learned in academia: there are three kinds of academic
>> reviews: review by name, review by reference and review by value.
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Ricky Clarkson]

>> That's ok.  There are problems with Java and C# that really need
>> addressing, and Scala addresses some of those.
>
> I totally agree. I am so happy that Scala has finally fixed them. I wonder
> if the masses will accept the changes though and we'll see a shift.

I regularly see C# developers in freenode's ##csharp idly wishing
their language supported immutability better, and wasn't verbose in
certain ways.  LINQ certainly began a shift.

>> Because most mainstream languages don't emphasise immutability, the
>> linked list isn't used that much there.
>
> I think immutability is part of it - recursion and link lists in general are
> not concepts that people use in everyday, mainstream programming.

Immutability is why recursion and linked lists are important.  The
x:xs is quite natural though, to many programmers.  Just rephrase it
as InputStream.read() and they'll know what you're talking about. :)

> Almost all
> the time people use ArrayList compared to a linked list.

Because immutability is at best an afterthought, and at worst
considered undesirable, in most programmers' minds.  To my mind, that
makes those programmers faulty.

> Algorithms on
> linked lists were only ever discussed in my computer science courses. I
> can't say I've used a Linked List many times in the last decade of my
> programming career, so writing recursive algorithms on them is something
> that I am out of practice with.

Technically you won't really need to do that in Scala either, thanks
to for-comprehensions and folds.

>> That's two positives, doesn't sound like a weird match to me.
>
> Again, I think they are positives too. I can see some people not getting
> the intellectually challenging aspects though, and wanting to revert back to
> more conventional programming ideas.

That's ok, and I hope the IDEs help if they need to do that.  In fact,
having the IDEs help in that might be enough to make some of them
understand the thing they were conventionalising.

> Don't get me wrong, I think pattern matching is a wonderful addition and
> it's extremely powerful. At first though, it seems like "magic".

That's ok, just make sure you give something at least two glances
before forming an opinion.  The preceding sentence sounds more harsh
than I intend it to.

> It feels
> like it's a second language within a language - something akin to a computer
> science textbook than actually writing a real program.
> I think it takes a solid understanding to see that it is naturally fits in
> scala, knowing how the partial functions are created and applied to each
> case, and viewing the world that way. Once I got this, patterns became a lot
> more natural for me to think and reason about.
> However, this is not apparent just by looking at it the first few times. I
> can see a lot of people getting bewildered by it, either trying to "memorize
> the magic" or just not using it.

I think using it for a while will fix that.

> I would argue that 97% (made up number) of Java developers don't care and
> have never heard of them. In Java, you can program and not care for the most
> part. In scala, I think one needs to learn these to use the language better.

I'm sorry you rate our fellow Java programmers so poorly.  Though I
must say, as I don't use subtyping very much in Scala, I rarely
actually touch covariance and contravariance.  It's a solution to a
mainstream problem.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Dave Griffith]

egervari wrote:

In the long run, what kind of developers do you think will make most use of scala?

In the long run, Scala will supplant Java as the standard language for back-end enterprise programming.   The advantages of Scala over Java in this realm are great, and will only become greater.   I'm guessing the tipping point will come as more open source and internal libraries get shipped in Scala, with features that can only be used profitably from Scala.  I'm thinking of stuff like actors, STM, decent I/O, extractors, pre-packaged mix-in traits and implicits.   Functionality will ship that theoretically could be used from Java, but would be too cumbersome, and organizations that don't jump on the bandwagon will lose out.    The fact that Scala let's you keep 100% of your organization's investment in Java technologies means this is a rare case where "better" can trump "standard".

There will be a "burn-in" time, where organizations mandate styles that limit some of Scala's power in an attempt to come to terms with it's complexity.  Expect to hear things like "No implicit params, or implicit conversions except to pimp" and "Only senior devs can implement filter/map/flatmap" and maybe  even "Folds must be done 'by hand'" and "No infinite streams".   This is natural, and to be expected.  Similar skill ramps occurred with C, C++ and Java in my professional lifetime.  

[Dimitris Andreou]

Lets hear what Guy Steele has to say about programming using things
like Scala's List (instead of arrays).

http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf

In short: "it's a fundamentally bad idea".

Dimitris

2009/10/23 Ricky Clarkson <ricky.clarkson@...>:

>>> That's ok.  There are problems with Java and C# that really need
>>> addressing, and Scala addresses some of those.
>>
>> I totally agree. I am so happy that Scala has finally fixed them. I wonder
>> if the masses will accept the changes though and we'll see a shift.
>
> I regularly see C# developers in freenode's ##csharp idly wishing
> their language supported immutability better, and wasn't verbose in
> certain ways.  LINQ certainly began a shift.
>
>>> Because most mainstream languages don't emphasise immutability, the
>>> linked list isn't used that much there.
>>
>> I think immutability is part of it - recursion and link lists in general are
>> not concepts that people use in everyday, mainstream programming.
>
> Immutability is why recursion and linked lists are important.  The
> x:xs is quite natural though, to many programmers.  Just rephrase it
> as InputStream.read() and they'll know what you're talking about. :)
>
>> Almost all
>> the time people use ArrayList compared to a linked list.
>
> Because immutability is at best an afterthought, and at worst
> considered undesirable, in most programmers' minds.  To my mind, that
> makes those programmers faulty.
>
>> Algorithms on
>> linked lists were only ever discussed in my computer science courses. I
>> can't say I've used a Linked List many times in the last decade of my
>> programming career, so writing recursive algorithms on them is something
>> that I am out of practice with.
>
> Technically you won't really need to do that in Scala either, thanks
> to for-comprehensions and folds.
>
>>> That's two positives, doesn't sound like a weird match to me.
>>
>> Again, I think they are positives too. I can see some people not getting
>> the intellectually challenging aspects though, and wanting to revert back to
>> more conventional programming ideas.
>
> That's ok, and I hope the IDEs help if they need to do that.  In fact,
> having the IDEs help in that might be enough to make some of them
> understand the thing they were conventionalising.
>
>> Don't get me wrong, I think pattern matching is a wonderful addition and
>> it's extremely powerful. At first though, it seems like "magic".
>
> That's ok, just make sure you give something at least two glances
> before forming an opinion.  The preceding sentence sounds more harsh
> than I intend it to.
>
>> It feels
>> like it's a second language within a language - something akin to a computer
>> science textbook than actually writing a real program.
>> I think it takes a solid understanding to see that it is naturally fits in
>> scala, knowing how the partial functions are created and applied to each
>> case, and viewing the world that way. Once I got this, patterns became a lot
>> more natural for me to think and reason about.
>> However, this is not apparent just by looking at it the first few times. I
>> can see a lot of people getting bewildered by it, either trying to "memorize
>> the magic" or just not using it.
>
> I think using it for a while will fix that.
>
>> I would argue that 97% (made up number) of Java developers don't care and
>> have never heard of them. In Java, you can program and not care for the most
>> part. In scala, I think one needs to learn these to use the language better.
>
> I'm sorry you rate our fellow Java programmers so poorly.  Though I
> must say, as I don't use subtyping very much in Scala, I rarely
> actually touch covariance and contravariance.  It's a solution to a
> mainstream problem.
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
> Google Wave: ricky.clarkson@...
>

[Detering Dirk-2]

Hi Ken,

> In the long run, what kind of developers do you think will
> make most use of scala?

In the long run, I can't say which kind of developers will
make least use of scala, to be honest.
Note: In the _long_ run.
I'll declare that.

> I am a bit concerned that the language is harder than a
> typical language like Java or C#. I know that is strange to
> say... because it's simpler. It's a strange conundrum.

Playing around a bit with Scala, reading the books and
articles, I came to the conclusion that Scala basically
is not harder that Java or any other typical language.

When I learned Java, I came from imperative programming
style and had to learn the OO-way, which was a paradigm
shift, but also changed the way I worked with C or the
like languages. Then after years of working with it,
Generics were introduced, so one was obliged to think
more about types a.s.o.

That was the long, long Java way.
And currently I have the opportunity to see what challenge
it is for trainees to understand the _current_ state of
Java....

> For example, the elegant and concise syntax would probably
> make the language easy to learn, but it's so different from
> the mainstream languages that for most, it might be a bit
> harder (at least at first).

... Beside my Java-line, trying to understand for-comprehensions
in Python was a challenge.

Then came Ruby. trying to understand advanced concepts
in Ruby (like closures, and continuation) was a challenge
too.
Not to mention new concepts _implemented in that language
(DSLs like Rake, RSpecs, ...)

Most of that stuff I did not use at that time, so
only closures were carried as present knowledge into
my mindset when Groovy came on stage.

Now everyone talks about concurrency (was not really
a topic on my table before) and functional programming
(did never really achieve to go into Lisp. Let's not talk
about Haskell!)....

> There are number of concepts that I think make this language
> applicable to only university graduates+, or at least people
> who can think that way. The functional nature is pretty
> similar to many courses at the university I went to... and
> seeing things like case matching reminds me of my proof and
> computer science courses. I don't think I would have seen
> lists split up as x:xs anywhere else but university either.

... All in all, Scala is in no way harder than any of that
languages.

What' hard is, when someone who stuck mostly to the
1.4 style of Java programming (avoiding Generics, forgetting
varargs shortly after reading about them, still using JUnit 3.8
 ...) suddenly is confronted with all those concepts at once,
which I experienced slowly, step by step, over time.

The problem is NOT the language, as all those concepts were
presented before, many of them even many years ago.

> Of course, I think one could get by without knowing any of
> those things, so here again we have a weird match of
> simplicity and something that could be intellectually
> challenging for a lot of people.

What is intellectually challenging are two points:

1.) Changing the mindset instead learning something from
    ground up.  FP is at first weird for someone coming from
    OO (I can tell you, because I am currently on that way).
    But it is doable.

2.) Not the language is the problem, but some sophisticated
    solutions to complex problems.
    It is the kind of domain people are talking about and
    using Scala for.
    Since I started with Scala I saw more and more people
    playing with it, and the more people did, the more common
    and known were the problems and solutions.


> I think pattern matching alone is more complicated than a lot
> of things in Java. It's remarkably powerful, and under the
> surface, it does follow a lot of Scala's fundamentals. Still,
> it doesn't appear that way when a person first approaches it.

I suppose it is with all those little electronic gadgets around.

Every knew invention was an awesome thing. Colour TV with remote
control. Wireless phones with keys instead dials. Mobile Phones.
PC/Internet/Email. CD/DVD. MP3 a.s.o.

My kids now grow up with all this stuff and learn to handle
it from childhood on. It is no problem for a six year old
to start DVD and TV. My nine year old knows to use playstation,
computer (internet/email) and phones with answering machines and
adress books. Not long and he will ask for a multi touch all-in-one
mobile device.

The kids are not complaining about complexity. They do not
even think about it when they use it.

> Concepts like covariant and contravariant are not known to
> most developers either.

It should be if they ever were interested in that Generics
stuff that came with Java 5 and had to create only a slightly
complex API.

> Then there's things that I see I can do in Scala that I don't
> think I would ever want to do... mainly because the power
> creates some confusion and things can become too concise that
> they are hard to understand. All this power definitely comes
> with great responsibility, and I don't think the average
> developer is up to the challenge.


The "average" developer of the (near) future will grow up
with all this stuff and will learn it from ground up, if
he wants to go into that profession.
Or he will never write software for actual multicore hardware,
upcoming distributed computing or future mobile devices.

It may be a big challenge for seniors like me, but it will be
just natural for future generations.

That's my opinion.

KR
Det

[Ricky Clarkson]

He's talking about sequential programming, not about x:xs or similar
concepts.  You can process a scala.List in parallel if you know n
points within it instead of just the head.

"Even arrays are suspect!" p.63.

Quote wars!

2009/10/23 Jim Andreou <jim.andreou@...>:

> Lets hear what Guy Steele has to say about programming using things
> like Scala's List (instead of arrays).
>
> http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf
>
> In short: "it's a fundamentally bad idea".
>
> Dimitris
>
> 2009/10/23 Ricky Clarkson <ricky.clarkson@...>:
>>>> That's ok.  There are problems with Java and C# that really need
>>>> addressing, and Scala addresses some of those.
>>>
>>> I totally agree. I am so happy that Scala has finally fixed them. I wonder
>>> if the masses will accept the changes though and we'll see a shift.
>>
>> I regularly see C# developers in freenode's ##csharp idly wishing
>> their language supported immutability better, and wasn't verbose in
>> certain ways.  LINQ certainly began a shift.
>>
>>>> Because most mainstream languages don't emphasise immutability, the
>>>> linked list isn't used that much there.
>>>
>>> I think immutability is part of it - recursion and link lists in general are
>>> not concepts that people use in everyday, mainstream programming.
>>
>> Immutability is why recursion and linked lists are important.  The
>> x:xs is quite natural though, to many programmers.  Just rephrase it
>> as InputStream.read() and they'll know what you're talking about. :)
>>
>>> Almost all
>>> the time people use ArrayList compared to a linked list.
>>
>> Because immutability is at best an afterthought, and at worst
>> considered undesirable, in most programmers' minds.  To my mind, that
>> makes those programmers faulty.
>>
>>> Algorithms on
>>> linked lists were only ever discussed in my computer science courses. I
>>> can't say I've used a Linked List many times in the last decade of my
>>> programming career, so writing recursive algorithms on them is something
>>> that I am out of practice with.
>>
>> Technically you won't really need to do that in Scala either, thanks
>> to for-comprehensions and folds.
>>
>>>> That's two positives, doesn't sound like a weird match to me.
>>>
>>> Again, I think they are positives too. I can see some people not getting
>>> the intellectually challenging aspects though, and wanting to revert back to
>>> more conventional programming ideas.
>>
>> That's ok, and I hope the IDEs help if they need to do that.  In fact,
>> having the IDEs help in that might be enough to make some of them
>> understand the thing they were conventionalising.
>>
>>> Don't get me wrong, I think pattern matching is a wonderful addition and
>>> it's extremely powerful. At first though, it seems like "magic".
>>
>> That's ok, just make sure you give something at least two glances
>> before forming an opinion.  The preceding sentence sounds more harsh
>> than I intend it to.
>>
>>> It feels
>>> like it's a second language within a language - something akin to a computer
>>> science textbook than actually writing a real program.
>>> I think it takes a solid understanding to see that it is naturally fits in
>>> scala, knowing how the partial functions are created and applied to each
>>> case, and viewing the world that way. Once I got this, patterns became a lot
>>> more natural for me to think and reason about.
>>> However, this is not apparent just by looking at it the first few times. I
>>> can see a lot of people getting bewildered by it, either trying to "memorize
>>> the magic" or just not using it.
>>
>> I think using it for a while will fix that.
>>
>>> I would argue that 97% (made up number) of Java developers don't care and
>>> have never heard of them. In Java, you can program and not care for the most
>>> part. In scala, I think one needs to learn these to use the language better.
>>
>> I'm sorry you rate our fellow Java programmers so poorly.  Though I
>> must say, as I don't use subtyping very much in Scala, I rarely
>> actually touch covariance and contravariance.  It's a solution to a
>> mainstream problem.
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> [phone]
>> Skype: ricky_clarkson
>> Google Talk: ricky.clarkson@...
>> Google Wave: ricky.clarkson@...
>>
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Dimitris Andreou]

You can only get these points if you sequentially traverse the list :)

2009/10/23 Ricky Clarkson <ricky.clarkson@...>:

> He's talking about sequential programming, not about x:xs or similar
> concepts.  You can process a scala.List in parallel if you know n
> points within it instead of just the head.
>
> "Even arrays are suspect!" p.63.
>
> Quote wars!
>
> 2009/10/23 Jim Andreou <jim.andreou@...>:
>> Lets hear what Guy Steele has to say about programming using things
>> like Scala's List (instead of arrays).
>>
>> http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf
>>
>> In short: "it's a fundamentally bad idea".
>>
>> Dimitris
>>
>> 2009/10/23 Ricky Clarkson <ricky.clarkson@...>:
>>>>> That's ok.  There are problems with Java and C# that really need
>>>>> addressing, and Scala addresses some of those.
>>>>
>>>> I totally agree. I am so happy that Scala has finally fixed them. I wonder
>>>> if the masses will accept the changes though and we'll see a shift.
>>>
>>> I regularly see C# developers in freenode's ##csharp idly wishing
>>> their language supported immutability better, and wasn't verbose in
>>> certain ways.  LINQ certainly began a shift.
>>>
>>>>> Because most mainstream languages don't emphasise immutability, the
>>>>> linked list isn't used that much there.
>>>>
>>>> I think immutability is part of it - recursion and link lists in general are
>>>> not concepts that people use in everyday, mainstream programming.
>>>
>>> Immutability is why recursion and linked lists are important.  The
>>> x:xs is quite natural though, to many programmers.  Just rephrase it
>>> as InputStream.read() and they'll know what you're talking about. :)
>>>
>>>> Almost all
>>>> the time people use ArrayList compared to a linked list.
>>>
>>> Because immutability is at best an afterthought, and at worst
>>> considered undesirable, in most programmers' minds.  To my mind, that
>>> makes those programmers faulty.
>>>
>>>> Algorithms on
>>>> linked lists were only ever discussed in my computer science courses. I
>>>> can't say I've used a Linked List many times in the last decade of my
>>>> programming career, so writing recursive algorithms on them is something
>>>> that I am out of practice with.
>>>
>>> Technically you won't really need to do that in Scala either, thanks
>>> to for-comprehensions and folds.
>>>
>>>>> That's two positives, doesn't sound like a weird match to me.
>>>>
>>>> Again, I think they are positives too. I can see some people not getting
>>>> the intellectually challenging aspects though, and wanting to revert back to
>>>> more conventional programming ideas.
>>>
>>> That's ok, and I hope the IDEs help if they need to do that.  In fact,
>>> having the IDEs help in that might be enough to make some of them
>>> understand the thing they were conventionalising.
>>>
>>>> Don't get me wrong, I think pattern matching is a wonderful addition and
>>>> it's extremely powerful. At first though, it seems like "magic".
>>>
>>> That's ok, just make sure you give something at least two glances
>>> before forming an opinion.  The preceding sentence sounds more harsh
>>> than I intend it to.
>>>
>>>> It feels
>>>> like it's a second language within a language - something akin to a computer
>>>> science textbook than actually writing a real program.
>>>> I think it takes a solid understanding to see that it is naturally fits in
>>>> scala, knowing how the partial functions are created and applied to each
>>>> case, and viewing the world that way. Once I got this, patterns became a lot
>>>> more natural for me to think and reason about.
>>>> However, this is not apparent just by looking at it the first few times. I
>>>> can see a lot of people getting bewildered by it, either trying to "memorize
>>>> the magic" or just not using it.
>>>
>>> I think using it for a while will fix that.
>>>
>>>> I would argue that 97% (made up number) of Java developers don't care and
>>>> have never heard of them. In Java, you can program and not care for the most
>>>> part. In scala, I think one needs to learn these to use the language better.
>>>
>>> I'm sorry you rate our fellow Java programmers so poorly.  Though I
>>> must say, as I don't use subtyping very much in Scala, I rarely
>>> actually touch covariance and contravariance.  It's a solution to a
>>> mainstream problem.
>>>
>>> --
>>> Ricky Clarkson
>>> Java and Scala Programmer, AD Holdings
>>> [phone]
>>> Skype: ricky_clarkson
>>> Google Talk: ricky.clarkson@...
>>> Google Wave: ricky.clarkson@...
>>>
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
> Google Wave: ricky.clarkson@...
>

[Luc Duponcheel]

All,

strange that nowadays Guy Steele loves catamorphisms

Years ago (when I was a researcher) he was not really a big fan of them

Luc

On Fri, Oct 23, 2009 at 4:48 PM, Jim Andreou <jim.andreou@...> wrote:

Lets hear what Guy Steele has to say about programming using things
like Scala's List (instead of arrays).

http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf

In short: "it's a fundamentally bad idea".

Dimitris

2009/10/23 Ricky Clarkson <ricky.clarkson@...>:
>>> That's ok.  There are problems with Java and C# that really need
>>> addressing, and Scala addresses some of those.
>>
>> I totally agree. I am so happy that Scala has finally fixed them. I wonder
>> if the masses will accept the changes though and we'll see a shift.
>
> I regularly see C# developers in freenode's ##csharp idly wishing
> their language supported immutability better, and wasn't verbose in
> certain ways.  LINQ certainly began a shift.
>
>>> Because most mainstream languages don't emphasise immutability, the
>>> linked list isn't used that much there.
>>
>> I think immutability is part of it - recursion and link lists in general are
>> not concepts that people use in everyday, mainstream programming.
>
> Immutability is why recursion and linked lists are important.  The
> x:xs is quite natural though, to many programmers.  Just rephrase it
> as InputStream.read() and they'll know what you're talking about. :)
>
>> Almost all
>> the time people use ArrayList compared to a linked list.
>
> Because immutability is at best an afterthought, and at worst
> considered undesirable, in most programmers' minds.  To my mind, that
> makes those programmers faulty.
>
>> Algorithms on
>> linked lists were only ever discussed in my computer science courses. I
>> can't say I've used a Linked List many times in the last decade of my
>> programming career, so writing recursive algorithms on them is something
>> that I am out of practice with.
>
> Technically you won't really need to do that in Scala either, thanks
> to for-comprehensions and folds.
>
>>> That's two positives, doesn't sound like a weird match to me.
>>
>> Again, I think they are positives too. I can see some people not getting
>> the intellectually challenging aspects though, and wanting to revert back to
>> more conventional programming ideas.
>
> That's ok, and I hope the IDEs help if they need to do that.  In fact,
> having the IDEs help in that might be enough to make some of them
> understand the thing they were conventionalising.
>
>> Don't get me wrong, I think pattern matching is a wonderful addition and
>> it's extremely powerful. At first though, it seems like "magic".
>
> That's ok, just make sure you give something at least two glances
> before forming an opinion.  The preceding sentence sounds more harsh
> than I intend it to.
>
>> It feels
>> like it's a second language within a language - something akin to a computer
>> science textbook than actually writing a real program.
>> I think it takes a solid understanding to see that it is naturally fits in
>> scala, knowing how the partial functions are created and applied to each
>> case, and viewing the world that way. Once I got this, patterns became a lot
>> more natural for me to think and reason about.
>> However, this is not apparent just by looking at it the first few times. I
>> can see a lot of people getting bewildered by it, either trying to "memorize
>> the magic" or just not using it.
>
> I think using it for a while will fix that.
>
>> I would argue that 97% (made up number) of Java developers don't care and
>> have never heard of them. In Java, you can program and not care for the most
>> part. In scala, I think one needs to learn these to use the language better.
>
> I'm sorry you rate our fellow Java programmers so poorly.  Though I
> must say, as I don't use subtyping very much in Scala, I rarely
> actually touch covariance and contravariance.  It's a solution to a
> mainstream problem.
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
> Google Wave: ricky.clarkson@...
>

--
  __~O
 -\ <,
(*)/ (*)

reality goes far beyond imagination

[Daniel Sobral]

Iterable would be meaningless. I'd look into Comparable, but I'm afraid it doesn't present as good an example as Ordering.

On Fri, Oct 23, 2009 at 12:28 PM, Ricky Clarkson <ricky.clarkson@...> wrote:

Iterable and Comparable should suffice as examples for both.

2009/10/23 Daniel Sobral <dcsobral@...>:

> On Fri, Oct 23, 2009 at 11:24 AM, Ricky Clarkson <ricky.clarkson@...>
> wrote:
>>
>> > Concepts like covariant and contravariant are not known to most
>> > developers
>> > either.
>>
>> C# 4 gains covariance and contravariance in type parameter
>> declarations.. interface IEnumerable<out T> ..
>> Java 5 gained covariant return types.
>> Java 5 wildcards added use-site covariance and contravariance.  The
>> concepts are known, or easy to understand, to competent developers.
>>
> Actually, these concepts are hard. Particularly contravariance. I never
> thought of a good example of contravariance, until people started discussing
> making Ordering contravariant. That's a perfect example! Unfortunately, it
> wasn't made contravariant, so I can't use it to demonstrate
> contravariance... :-(
>
> Back to Scala, though, at least Scala won't let you shoot yourself in the
> foot. Its error messages could suggest using the B1 >: B pattern to get
> around some common obstacles, though.
>
>>
>> --
>> Daniel C. Sobral
>>
>> Something I learned in academia: there are three kinds of academic
>> reviews: review by name, review by reference and review by value.
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Daniel Sobral]

Could you cut that "instead of arrays" out? He is not comparing lists to arrays, but to TREES!

On Fri, Oct 23, 2009 at 12:48 PM, Jim Andreou <jim.andreou@...> wrote:

Lets hear what Guy Steele has to say about programming using things
like Scala's List (instead of arrays).

http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf

In short: "it's a fundamentally bad idea".

Dimitris

2009/10/23 Ricky Clarkson <ricky.clarkson@...>:

>>> That's ok.  There are problems with Java and C# that really need
>>> addressing, and Scala addresses some of those.
>>
>> I totally agree. I am so happy that Scala has finally fixed them. I wonder
>> if the masses will accept the changes though and we'll see a shift.
>
> I regularly see C# developers in freenode's ##csharp idly wishing
> their language supported immutability better, and wasn't verbose in
> certain ways.  LINQ certainly began a shift.
>
>>> Because most mainstream languages don't emphasise immutability, the
>>> linked list isn't used that much there.
>>
>> I think immutability is part of it - recursion and link lists in general are
>> not concepts that people use in everyday, mainstream programming.
>
> Immutability is why recursion and linked lists are important.  The
> x:xs is quite natural though, to many programmers.  Just rephrase it
> as InputStream.read() and they'll know what you're talking about. :)
>
>> Almost all
>> the time people use ArrayList compared to a linked list.
>
> Because immutability is at best an afterthought, and at worst
> considered undesirable, in most programmers' minds.  To my mind, that
> makes those programmers faulty.
>
>> Algorithms on
>> linked lists were only ever discussed in my computer science courses. I
>> can't say I've used a Linked List many times in the last decade of my
>> programming career, so writing recursive algorithms on them is something
>> that I am out of practice with.
>
> Technically you won't really need to do that in Scala either, thanks
> to for-comprehensions and folds.
>
>>> That's two positives, doesn't sound like a weird match to me.
>>
>> Again, I think they are positives too. I can see some people not getting
>> the intellectually challenging aspects though, and wanting to revert back to
>> more conventional programming ideas.
>
> That's ok, and I hope the IDEs help if they need to do that.  In fact,
> having the IDEs help in that might be enough to make some of them
> understand the thing they were conventionalising.
>
>> Don't get me wrong, I think pattern matching is a wonderful addition and
>> it's extremely powerful. At first though, it seems like "magic".
>
> That's ok, just make sure you give something at least two glances
> before forming an opinion.  The preceding sentence sounds more harsh
> than I intend it to.
>
>> It feels
>> like it's a second language within a language - something akin to a computer
>> science textbook than actually writing a real program.
>> I think it takes a solid understanding to see that it is naturally fits in
>> scala, knowing how the partial functions are created and applied to each
>> case, and viewing the world that way. Once I got this, patterns became a lot
>> more natural for me to think and reason about.
>> However, this is not apparent just by looking at it the first few times. I
>> can see a lot of people getting bewildered by it, either trying to "memorize
>> the magic" or just not using it.
>
> I think using it for a while will fix that.
>
>> I would argue that 97% (made up number) of Java developers don't care and
>> have never heard of them. In Java, you can program and not care for the most
>> part. In scala, I think one needs to learn these to use the language better.
>
> I'm sorry you rate our fellow Java programmers so poorly.  Though I
> must say, as I don't use subtyping very much in Scala, I rarely
> actually touch covariance and contravariance.  It's a solution to a
> mainstream problem.
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
> Google Wave: ricky.clarkson@...
>

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Razvan Cojocaru]

Ricky Clarkson wrote:

Simple is always better, sure.  And my Scala code is simpler than my Java code.

Not so fast, Ricky - the functional aspect of Scala allows even worse contraptions than C++ did...

Here's some code I hapily wrote a few months ago and I'm having trouble following and debugging right now:

      def xpl (ctx:XqSolver[T,Any], root:T) : List[T] =
         for (e <- elements.foldLeft (List ((root,List(root).asInstanceOf[Any])) ) ( (x,y) => y.solve(ctx, x).asInstanceOf[List[(T,Any)]]) )
           yield e._1

      def xpa (ctx:XqSolver[T,Any], root:T) : String =   ctx.getAttr(
           (for (e <- elements.filter(_.attr!="@").foldLeft(List ((root,List(root).asInstanceOf[Any])) ) ( (x,y) => y.solve(ctx, x).asInstanceOf[List[(T,Any)]]) )
             yield e._1
          ).first, elements.last.name)

Enterprise-wise, maintenabilty of code is much more important than it's beauty or what one or other perceive as "simple".

Otherwise, yeah - Scala code is much simpler than Java code, agreed...the samples above take about two pages of Java code :))