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

2009/10/23 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 ..
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.

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

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

"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@comcast.net> 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

On Fri, Oct 23, 2009 at 9:24 AM, Ricky Clarkson <ricky.clarkson@gmail.com> 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.  

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

2009/10/23 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
> --
> View this message in context: http://www.nabble.com/In-the-long-run%2C-what-kind-of-developers-do-you-...
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

On Fri, Oct 23, 2009 at 11:24 AM, Ricky Clarkson <ricky.clarkson@gmail.com> 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.

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@comcast.net>

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.

Iterable and Comparable should suffice as examples for both.

2009/10/23 Daniel Sobral :
> On Fri, Oct 23, 2009 at 11:24 AM, 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 ..
>> 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.
>

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.

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

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

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/MITApril2009Ste...

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

Dimitris

2009/10/23 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
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@gmail.com
> Google Wave: ricky.clarkson@googlewave.com
>

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 :
> 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/MITApril2009Ste...
>
> In short: "it's a fundamentally bad idea".
>
> Dimitris
>
> 2009/10/23 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
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky.clarkson@gmail.com
>> Google Wave: ricky.clarkson@googlewave.com
>>
>

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@gmail.com> 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@gmail.com>:
>>> 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
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@gmail.com
> Google Wave: ricky.clarkson@googlewave.com
>

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

reality goes far beyond imagination

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@gmail.com> wrote:

Iterable and Comparable should suffice as examples for both.

2009/10/23 Daniel Sobral <dcsobral@gmail.com>:
> On Fri, Oct 23, 2009 at 11:24 AM, Ricky Clarkson <ricky.clarkson@gmail.com>
> 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
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
Google Wave: ricky.clarkson@googlewave.com

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

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@gmail.com> 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@gmail.com>:
>>> 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
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@gmail.com
> Google Wave: ricky.clarkson@googlewave.com
>

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

Sure, if you wish so. It's easy though to get such trees using arrays.
See ParallelArray of Doug Lea. (Could someone implement something like
that with scala.List? Allow me to have my reservations :) )

2009/10/23 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 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/MITApril2009Ste...
>>
>> In short: "it's a fundamentally bad idea".
>>
>> Dimitris
>>
>> 2009/10/23 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
>> > +44 1565 770804
>> > Skype: ricky_clarkson
>> > Google Talk: ricky.clarkson@gmail.com
>> > Google Wave: ricky.clarkson@googlewave.com
>> >
>
>
>
> --
> 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.
>

Not if I wish so. Trees, which he proposes, are extensible, and easy to copy parts of. One can pass references to subtrees, use the same subtree in for different trees, and things like that, which are not possible with arrays. And, in particular, immutable trees are more efficient than immutable arrays, because of these properties.   Look, it's not that difficult. Yes, he is telling us Lists are not good for concurrency, and that's true. But what is he used instead of them? Arrays? No, trees.
And I'll even grant that using immutable arrays to compose trees is very effective, as Clojure has shown.
On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

Sure, if you wish so. It's easy though to get such trees using arrays.
See ParallelArray of Doug Lea. (Could someone implement something like
that with scala.List? Allow me to have my reservations :) )

2009/10/23 Daniel Sobral <dcsobral@gmail.com>:
> 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@gmail.com> 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@gmail.com>:
>> >>> 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
>> > +44 1565 770804
>> > Skype: ricky_clarkson
>> > Google Talk: ricky.clarkson@gmail.com
>> > Google Wave: ricky.clarkson@googlewave.com
>> >
>
>
>
> --
> 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 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 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 :))

-----
Razie
http://feeds.razie.com/RazvanTech

The question of trees vs arrays is besides the point. Perhaps I should
have said "instead of some other representation _such as arrays_ (or
trees or whatever, that's not the point) which can yield computations
with minimal critical path" - still, all these are more appropriate
than LISPy lists, which yield linear critical paths, in the era of
multicores. This is a pretty basic point and we all agree on it as far
as I can see - so this should be moved out from "debate" :)

But I'm not sure where you see the difficulty in dividing an array in
2 parts, carry on recursively, and get a computation resembling a
balanced tree with critical path logN. What's the problem with that?
ParallelArray does it. Oh, scrap that. Even mergesort does it. It's
trivial, unless you meant something I miss. Can you clarify?

Regards,
Dimitris

2009/10/23 Daniel Sobral :
> Not if I wish so. Trees, which he proposes, are extensible, and easy to copy
> parts of. One can pass references to subtrees, use the same subtree in for
> different trees, and things like that, which are not possible with arrays.
> And, in particular, immutable trees are more efficient than immutable
> arrays, because of these properties.
>
> Look, it's not that difficult. Yes, he is telling us Lists are not good for
> concurrency, and that's true. But what is he used instead of them? Arrays?
> No, trees.
> And I'll even grant that using immutable arrays to compose trees is very
> effective, as Clojure has shown.
> On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou wrote:
>>
>> Sure, if you wish so. It's easy though to get such trees using arrays.
>> See ParallelArray of Doug Lea. (Could someone implement something like
>> that with scala.List? Allow me to have my reservations :) )
>>
>> 2009/10/23 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
>> > 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/MITApril2009Ste...
>> >>
>> >> In short: "it's a fundamentally bad idea".
>> >>
>> >> Dimitris
>> >>
>> >> 2009/10/23 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
>> >> > +44 1565 770804
>> >> > Skype: ricky_clarkson
>> >> > Google Talk: ricky.clarkson@gmail.com
>> >> > Google Wave: ricky.clarkson@googlewave.com
>> >> >
>> >
>> >
>> >
>> > --
>> > 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 C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>

Sure. Let's take an array [abcdefghijk], and a tree   Node(f, Node(c, Leaf(a,b), Leaf(d, e)), Node(i, Leaf(g, h), Leaf(j, k)))   Sorry, I suck at ASCII art. :-)   If I decide to replace "g" with something else, I need to copy two nodes and one leaf. To make things easier, assume all these letters are objects, so each node contains 3 references and leaf contain, two references. Total, I need to copy 8 references. If I need to (immutably) change the array, I need to copy the whole array, or 11 references.   As the tree gets deeper, the advantage of the trees get wider, as you only need to copy one object at each level.   We can go about this problem the other way too. If I have two arrays, I can only join them by copying them whole. If I have two trees, I just need a new node.
On Fri, Oct 23, 2009 at 4:11 PM, Jim Andreou <jim.andreou@gmail.com> wrote:

The question of trees vs arrays is besides the point. Perhaps I should
have said "instead of some other representation _such as arrays_ (or
trees or whatever, that's not the point) which can yield computations
with minimal critical path" - still, all these are more appropriate
than LISPy lists, which yield linear critical paths, in the era of
multicores. This is a pretty basic point and we all agree on it as far
as I can see - so this should be moved out from "debate" :)

But I'm not sure where you see the difficulty in dividing an array in
2 parts, carry on recursively, and get a computation resembling a
balanced tree with critical path logN. What's the problem with that?
ParallelArray does it. Oh, scrap that. Even mergesort does it. It's
trivial, unless you meant something I miss. Can you clarify?

Regards,
Dimitris

2009/10/23 Daniel Sobral <dcsobral@gmail.com>:
> Not if I wish so. Trees, which he proposes, are extensible, and easy to copy
> parts of. One can pass references to subtrees, use the same subtree in for
> different trees, and things like that, which are not possible with arrays.
> And, in particular, immutable trees are more efficient than immutable
> arrays, because of these properties.
>
> Look, it's not that difficult. Yes, he is telling us Lists are not good for
> concurrency, and that's true. But what is he used instead of them? Arrays?
> No, trees.
> And I'll even grant that using immutable arrays to compose trees is very
> effective, as Clojure has shown.
> On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou <jim.andreou@gmail.com> wrote:
>>
>> Sure, if you wish so. It's easy though to get such trees using arrays.
>> See ParallelArray of Doug Lea. (Could someone implement something like
>> that with scala.List? Allow me to have my reservations :) )
>>
>> 2009/10/23 Daniel Sobral <dcsobral@gmail.com>:
>> > 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@gmail.com>
>> > 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@gmail.com>:
>> >> >>> 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
>> >> > +44 1565 770804
>> >> > Skype: ricky_clarkson
>> >> > Google Talk: ricky.clarkson@gmail.com
>> >> > Google Wave: ricky.clarkson@googlewave.com
>> >> >
>> >
>> >
>> >
>> > --
>> > 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 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 C. Sobral

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

Oh, I see. Yes, I certainly agree with this. Persistent arrays that
don't suck are tough to achieve (I must have been the first to point
this out to someone who recently asked here for such a structure in
the scala library, thinking that in fact they are easy to have), while
persistent trees are so much easier to have.

I don't think I said anything about persistent structures or
mutability or anything that relates this to the previous discussion,
though. Is the link that I mentioned "arrays", so you responded that
"yeah, but persistent arrays suck"? If this is the case, it's quite
funny, I thought we were disagreeing on something while we were
agreeing on both accounts.

Anyway, all in all, I found that presentation very interesting when I
first saw it, and it's nice that apparently more people got to check
it out, even in as a controversial way as this :-)

ps: I didn't even bother reading your ascii tree, sorry, but I trust I
got your point!

2009/10/23 Daniel Sobral :
> Sure. Let's take an array [abcdefghijk], and a tree
>
> Node(f, Node(c, Leaf(a,b), Leaf(d, e)), Node(i, Leaf(g, h), Leaf(j, k)))
>
> Sorry, I suck at ASCII art. :-)
>
> If I decide to replace "g" with something else, I need to copy two nodes and
> one leaf. To make things easier, assume all these letters are objects, so
> each node contains 3 references and leaf contain, two references. Total, I
> need to copy 8 references. If I need to (immutably) change the array, I need
> to copy the whole array, or 11 references.
>
> As the tree gets deeper, the advantage of the trees get wider, as you only
> need to copy one object at each level.
>
> We can go about this problem the other way too. If I have two arrays, I can
> only join them by copying them whole. If I have two trees, I just need a new
> node.
> On Fri, Oct 23, 2009 at 4:11 PM, Jim Andreou wrote:
>>
>> The question of trees vs arrays is besides the point. Perhaps I should
>> have said "instead of some other representation _such as arrays_ (or
>> trees or whatever, that's not the point) which can yield computations
>> with minimal critical path" - still, all these are more appropriate
>> than LISPy lists, which yield linear critical paths, in the era of
>> multicores. This is a pretty basic point and we all agree on it as far
>> as I can see - so this should be moved out from "debate" :)
>>
>> But I'm not sure where you see the difficulty in dividing an array in
>> 2 parts, carry on recursively, and get a computation resembling a
>> balanced tree with critical path logN. What's the problem with that?
>> ParallelArray does it. Oh, scrap that. Even mergesort does it. It's
>> trivial, unless you meant something I miss. Can you clarify?
>>
>> Regards,
>> Dimitris
>>
>> 2009/10/23 Daniel Sobral :
>> > Not if I wish so. Trees, which he proposes, are extensible, and easy to
>> > copy
>> > parts of. One can pass references to subtrees, use the same subtree in
>> > for
>> > different trees, and things like that, which are not possible with
>> > arrays.
>> > And, in particular, immutable trees are more efficient than immutable
>> > arrays, because of these properties.
>> >
>> > Look, it's not that difficult. Yes, he is telling us Lists are not good
>> > for
>> > concurrency, and that's true. But what is he used instead of them?
>> > Arrays?
>> > No, trees.
>> > And I'll even grant that using immutable arrays to compose trees is very
>> > effective, as Clojure has shown.
>> > On Fri, Oct 23, 2009 at 2:09 PM, Jim Andreou
>> > wrote:
>> >>
>> >> Sure, if you wish so. It's easy though to get such trees using arrays.
>> >> See ParallelArray of Doug Lea. (Could someone implement something like
>> >> that with scala.List? Allow me to have my reservations :) )
>> >>
>> >> 2009/10/23 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
>> >> > 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/MITApril2009Ste...
>> >> >>
>> >> >> In short: "it's a fundamentally bad idea".
>> >> >>
>> >> >> Dimitris
>> >> >>
>> >> >> 2009/10/23 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
>> >> >> > +44 1565 770804
>> >> >> > Skype: ricky_clarkson
>> >> >> > Google Talk: ricky.clarkson@gmail.com
>> >> >> > Google Wave: ricky.clarkson@googlewave.com
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > 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 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 C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>

I said *my* Scala code is simpler than my Java code. I said nothing
about your code. :)

You don't have to write unreadable code.

2009/10/23 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 :))
>
>
>
> -----
> Razie
> http://feeds.razie.com/RazvanTech
> --
> View this message in context: http://www.nabble.com/In-the-long-run%2C-what-kind-of-developers-do-you-...
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

Dimitris 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/MITApril2009Ste...
>
> In short: "it's a fundamentally bad idea".
>
> Dimitris
>

Sorry - read the ppt and I have to say that The Guy's wrong. Let's be clear
- there is cost to parallelizing work. I'm not talking just about assigning
threads to cores and switching threads and contexts on the cores, but
there's also cost in forking and joining values from the different
cores/threads.

He's assuming that this cost is insignificant compared to the basic task of
adding one or a few numbers. He's wrong. His presentation becomes of value
when the task at hand is orders of magnitude higher than the cost of
paralelizing.

In real life, unless you're compressing mpegs, you're most likely fine using
sequential access collections... Parallelism can be used across tasks and
requests (i.e. http requests or whateveyou). Waiting for external systems
(like a file read or a data base read) is, in general, the most time
consuming of all tasks and the OS puts your threads to sleep anyhow.

So, while interesting, it's not very relevant...unless you're compressing
mpegs rather than adding numbers...but that's not every one's bread and
butter.

Hell, does anyone remember OCCAM? For now, as-needed use of the method below
is enough for me :)

/** fork a bunch of threads, then join them and return the results */
def forkjoin[A,B<:AnyRef] (as:Iterable[A]) (f:A =>B) : Iterable[B] = {

Cheers,

-----
Razie
http://feeds.razie.com/RazvanTech

On Fri, Oct 23, 2009 at 10:49:20AM -0700, Razvan Cojocaru wrote:
> 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)

PEBKAC. Extinguish your strawman before this whole place goes up.

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

I agree with this assessment, Ken. As stated in the Odersky book, ``with
power comes responsibility." This was true for C++ and for Perl, and it
is true for Scala. Where code becomes so concise that others might have
a hard time reading and understanding it, you will probably have to
write more comments (hopefully good comments) than in C# or Java. And
noone should ever be tempted to be ``too clever." Perl is a
write-once-and-never-read-again language: it's easy to shift mountains
with two lines of Perl code, and it's just as easy to lose control of
your own Perl sources: ``Mhm, I wrote this six months ago, and now I
forgot what it was supposed to be doing, sorry."

I wouldn't always recommend to switch from Java to Scala without
criticism. For a bigger Scala project to succeed, all developers
involved need some good knowledge about and some concrete experience
with Scala, otherwise you will not increase productivity but achieve the
opposite effect.

---Phil

On Fri, 2009-10-23 at 12:15 -0700, Razvan Cojocaru wrote:
>
> Dimitris 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/MITApril2009Ste...
> >
> > In short: "it's a fundamentally bad idea".
> >
> > Dimitris
> >
>
> Sorry - read the ppt and I have to say that The Guy's wrong. Let's be clear
> - there is cost to parallelizing work. I'm not talking just about assigning
> threads to cores and switching threads and contexts on the cores, but
> there's also cost in forking and joining values from the different
> cores/threads.
>
> He's assuming that this cost is insignificant compared to the basic task of
> adding one or a few numbers. He's wrong. His presentation becomes of value
> when the task at hand is orders of magnitude higher than the cost of
> paralelizing.

He isn't wrong, I think you are just over analysing the examples used in
a talk -- examples need to be inappropriately small for the
presentation.

You are right there is a cost to parallelizing work, but that is
assumed. The ideas behind his talk and Fortress are from HPC and highly
parallel computations. Whilst there may be infelicities in the slides,
the overall message is right. The era of sequential computation as the
whole application are now dead. The sooner we redefine algorithm to
remove the word sequence from the definition so as to automatically
assume parallel computation with sequential as a special case, the
better.

> In real life, unless you're compressing mpegs, you're most likely fine using
> sequential access collections... Parallelism can be used across tasks and
> requests (i.e. http requests or whateveyou). Waiting for external systems
> (like a file read or a data base read) is, in general, the most time
> consuming of all tasks and the OS puts your threads to sleep anyhow.

Indeed I/O is a Big Problem. Dealing with MPEGs is not the only highly
parallel problem, there are many, many others. Embedding sequential
access to collections as a principle is Bad Idea. Data parallelism is
where the real action is going to be which is why Haskell is forging
ahead with Data Parallel Haskell, and why Intel are forging ahead with C
++ Threading Building Blocks.

If you are programming using threads then I'm afraid you are still in
the computing dark ages ;-) They may be a way of realizing parallel
computation, but they are the wrong tool for programming. But then this
being Scala, I guess this is agreed.

> So, while interesting, it's not very relevant...unless you're compressing
> mpegs rather than adding numbers...but that's not every one's bread and
> butter.
>
> Hell, does anyone remember OCCAM? For now, as-needed use of the method below
> is enough for me :)
>
> /** fork a bunch of threads, then join them and return the results */
> def forkjoin[A,B<:AnyRef] (as:Iterable[A]) (f:A =>B) : Iterable[B] = {

Many of us do indeed remember occam (NB fully lower case name despite
being a proper noun). It was clearly a platform ahead of its time.
There are many lessons to be learned from CSP as well as Actor Model.
Also dataflow software architectures are on the rise and must no be
ignored.

(Coming a little late to this thread)

On Fri, Oct 23, 2009 at 6:01 AM, Ken Egervari wrote:
> In the long run, what kind of developers do you think will make most use of
> scala?

More advanced developers. Junior developers struggle with basic OO in
Java let alone functional style... The world has a lot of junior
developers tho' and the more advanced developers could be even more
productive with better tools / languages.

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

I don't think it's harder, just different. If you're a polyglot it's
likely to be easier than if you're used to just Java/C# style
languages.

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

I was at university from '79 to '86, including my PhD research.
Functional programming was "the big thing" back then and my thesis was
"Functional Programming Language Design and Implementation" (don't
look for it - in the end I never wrote it up). Lisp, SASL, Prolog were
"hot" back then - so that list notation was common in those circles.
It's just syntax... again, polyglots will pick this up faster than
"just Java" developers I suspect.

I've always liked the functional style and used it in other languages
where it was a clean and appropriate solution to a problem (and where
it was supported!).

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

Folks who've used Prolog won't find Scala's pattern matching strange
or complicated. I think it's fairly intuitive - I think that the
syntax is the thing that makes people think it's more complex than it
really is.

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

C++ has those concepts. Even CFML (ColdFusion Markup Language), which
I've been using a lot lately for web development, has had to introduce
those concepts for its definition of interface and valid
implementations (drawn from C++, partly through my influence). They're
not new concepts but I agree they're not widespread (but I think more
developers should understand them).

Overall?

Last year I built a fairly large project in Groovy rather than Java
for the same reasons that I would consider building it in Scala today
- faster development through a higher-level, more expressive language.

Personally I'm very pleased to see the resurgence of both functional
programming and pattern matching!
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."

> Folks who've used Prolog won't find Scala's pattern matching strange
> or complicated. I think it's fairly intuitive - I think that the
> syntax is the thing that makes people think it's more complex than it
> really is.

Folks who have used Prolog wonder why matching in Scala is sometimes
more complex that it should be :-) I mean, many of the conditions following
the match could be dropped if matching were implemented more like term
unification with Prolog like variables.

Job H.

On Fri, Oct 23, 2009 at 9:40 AM, Daniel Sobral wrote:
> 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
> wrote:
>>
>> Iterable and Comparable should suffice as examples for both.

Or better yet, Function1[-A,+B]. Covariance and contravariance in one
neat little package. Makes total sense that the first parameter must
be contravariant and that the second may be covariant, too.

Kris

Yeah? Can you draw pictures showing it?
I have found, repeatedly, that Function1's contravariance only makes sense after you understand it, which doesn't suit my purposes. :-)
On Tue, Oct 27, 2009 at 12:53 AM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote:

On Fri, Oct 23, 2009 at 9:40 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
> 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@gmail.com>
> wrote:
>>
>> Iterable and Comparable should suffice as examples for both.

Or better yet, Function1[-A,+B]. Covariance and contravariance in one
neat little package. Makes total sense that the first parameter must
be contravariant and that the second may be covariant, too.

Kris

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

Speaking of pictures: does anyone know if UML has any story or way of handling
* representation of contra- vs. co-variant extension?
* upper and lower bounds on type parameters? (to say nothing of self-types)

I'm assuming UML class diagrams have no support for these things. There's a lot of big orgs with architects that live and breathe UML -- I wonder if UML's (or at least the popular concept of UML class diagrams) lack of support for these things would make Scala adoption particularly difficult in these organizations.

Best regards,
Brian Maso
(949) 395-8551
brian@blumenfeld-maso.com
twitter: @bmaso
skype: brian.maso
LinkedIn: http://www.linkedin.com/in/brianmaso

On Mon, Oct 26, 2009 at 8:09 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Yeah? Can you draw pictures showing it?
I have found, repeatedly, that Function1's contravariance only makes sense after you understand it, which doesn't suit my purposes. :-)
On Tue, Oct 27, 2009 at 12:53 AM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote:

On Fri, Oct 23, 2009 at 9:40 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
> 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@gmail.com>
> wrote:
>>
>> Iterable and Comparable should suffice as examples for both.

Or better yet, Function1[-A,+B]. Covariance and contravariance in one
neat little package. Makes total sense that the first parameter must
be contravariant and that the second may be covariant, too.

Kris

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

> From: Daniel Sobral [mailto:dcsobral@gmail.com]
> I have found, repeatedly, that Function1's contravariance
> only makes sense after you understand it,

Can you declare that statement to me?

I must admit that I am now looking for quite some minutes
onto this sentence, stuck in some sort of inner-brain
philosophical endless loop...

- What makes sense, *before* you understand it?
- What can you understand, *before* it makes sense?
- So, in what way is *making sense* different from *understanding*

KR
Det

I think he means that it is not intuitive.

2009/10/27 Detering Dirk :
>> From: Daniel Sobral [mailto:dcsobral@gmail.com]
>> I have found, repeatedly, that Function1's contravariance
>> only makes sense after you understand it,
>
> Can you declare that statement to me?
>
> I must admit that I am now looking for quite some minutes
> onto this sentence, stuck in some sort of inner-brain
> philosophical endless loop...
>
> - What makes sense, *before* you understand it?
> - What can you understand, *before* it makes sense?
> - So, in what way is *making sense* different from *understanding*
>
> KR
> Det
>

On Mon, Oct 26, 2009 at 10:53 PM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote:

On Fri, Oct 23, 2009 at 9:40 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
> 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@gmail.com>
> wrote:
>>
>> Iterable and Comparable should suffice as examples for both.

Or better yet, Function1[-A,+B]. Covariance and contravariance in one
neat little package. Makes total sense that the first parameter must
be contravariant and that the second may be covariant, too.

To expand, suppose you have a function f that takes an A and returns a B, and you want a function g that can be used anywhere f can be used.

Well, f takes an A, so g has to take every A also.  But it could take other things, too, and that would still work out.  So it's contravariant.

Also, f returns a B, so g certainly has to return a B every time*, but the constraint is satisfied if it only returns a subset of Bs--in particular, if it returns only a subclass of B.  So it's covariant.

Thus, functions are both contravariant and covariant: a drop-in replacement for a function must have an equal or larger domain (inputs) and an equal or smaller range (outputs).

  --Rex

* Actually, the true requirement is that g[A] is a subset of B, not that g[whatever g can take] is a subset of B; if you're using a language with dynamic typing, things will break if g actually returns a non-B when you feed it an A.  With static typing, you make an even stronger guarantee about g: not only will it return a B every time you feed it an A, but it will return a B no matter what you feed it.

> Or better yet, Function1[-A,+B]. Covariance and
> contravariance in one
> neat little package. Makes total sense that the first
> parameter must
> be contravariant and that the second may be covariant, too.
>
>
>
> To expand, suppose you have a function f that takes an A and
> returns a B, and you want a function g that can be used
> anywhere f can be used.[...]

... or to take the question "can you draw a picture?" literally:

http://filebin.ca/bxmuwu/CoAndContraVariance.ppt

KR
Det

Since I asked that question, I'll answer here. This is a nice picture of abstract concepts. Most people can't use abstract concepts while trying to understand things(*), they need to come up with some concrete stuff do it. This picture is nice, but there are no horses (or ponies), ducks, house, beaches, trees, cars people or anything like it in it.
Now, if I say Manager is a subclass of Employee, everyone understands that. Next I say I have a sort function which receives an Ordering[T], so far so good. To sort a list of managers, I'd pass to it an Ordering[Manager], but if I don't have one, I can pass an Ordering[Employee]. It's easy to see that such an ordering can be applied to managers as well. And it's not difficult to see that, if I'm sorting managers, then I can only pass it if Ordering[Employee] is a subclass if Ordering[Manager]. And once I do that, tah-dah! Pictures to follow. :-)
I can then go further and say I have a VP class, subclass of Manager, for which there is an Ordering[VP] which is a fixed ordering based on the relative importance of each position. Naturally, I could never use that ordering to sort managers, so Ordering[VP] could never be a subclass of Ordering[Manager], even though VP is a subclass of Manager.
This is my goal. To find something very concrete with which to explain the kind of situation where contra-variance is naturally shows up.
So, having said all that... do put those powerpoints on some slideshow site, and blog or tweet about it! We'll take care of buzzing, digging, slashdotting or whatever it. :-)
(*) While teaching a deeply abstract concept, a math teacher of mine was asked "Can you give an example with numbers?" To which he answered "Ok. Then let a, b and c be three numbers, and ..."

On Wed, Oct 28, 2009 at 7:36 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

>       Or better yet, Function1[-A,+B]. Covariance and
> contravariance in one
>       neat little package. Makes total sense that the first
> parameter must
>       be contravariant and that the second may be covariant, too.
>
>
>
> To expand, suppose you have a function f that takes an A and
> returns a B, and you want a function g that can be used
> anywhere f can be used.[...]

... or to take the question "can you draw a picture?" literally:

http://filebin.ca/bxmuwu/CoAndContraVariance.ppt

KR
Det

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

On Wednesday October 28 2009, Detering Dirk wrote:
> ...
>
> ... or to take the question "can you draw a picture?" literally:
>
> http://filebin.ca/bxmuwu/CoAndContraVariance.ppt

PowerPoint's not good for me. I've attached a PDF.

> KR
> Det

Randall Schulz

On Tue, Oct 27, 2009 at 9:38 AM, Rex Kerr wrote:
> On Mon, Oct 26, 2009 at 10:53 PM, Kris Nuttycombe
> wrote:
>>
>> On Fri, Oct 23, 2009 at 9:40 AM, Daniel Sobral wrote:
>> > 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
>> >
>> > wrote:
>> >>
>> >> Iterable and Comparable should suffice as examples for both.
>>
>> Or better yet, Function1[-A,+B]. Covariance and contravariance in one
>> neat little package. Makes total sense that the first parameter must
>> be contravariant and that the second may be covariant, too.
>
> To expand, suppose you have a function f that takes an A and returns a B,
> and you want a function g that can be used anywhere f can be used.
>
> Well, f takes an A, so g has to take every A also.  But it could take other
> things, too, and that would still work out.  So it's contravariant.
>
> Also, f returns a B, so g certainly has to return a B every time*, but the
> constraint is satisfied if it only returns a subset of Bs--in particular, if
> it returns only a subclass of B.  So it's covariant.
>
> Thus, functions are both contravariant and covariant: a drop-in replacement
> for a function must have an equal or larger domain (inputs) and an equal or
> smaller range (outputs).
>
>   --Rex
>
> * Actually, the true requirement is that g[A] is a subset of B, not that
> g[whatever g can take] is a subset of B; if you're using a language with
> dynamic typing, things will break if g actually returns a non-B when you
> feed it an A.  With static typing, you make an even stronger guarantee about
> g: not only will it return a B every time you feed it an A, but it will
> return a B no matter what you feed it.

Exactly. I think this illustrates an important point: that thinking
about covariance and contravariance in terms of subtyping may be
incorrect. Instead, perhaps one should think of subtyping in terms of
covariance.

The essential information for the type system to capture is what
values can be applied where. Given B <: A, X[-B] then an X[A] is
applicable anywhere an X[B] is. Similarly, a B is applicable anywhere
an A is. But while B is a subtype of A, there's no particular reason
to consider X[A] a subtype of X[B] - it is merely applicable in the
same locations. Reasoning about it this way, variance is the more
general principle and subtyping is a special case of covariance.

Does this make sense?

Kris

Entirely. Which means, if taken to its logical conclusion, that subtyping and subclassing are two different things.

On Wed, Oct 28, 2009 at 2:45 PM, Kris Nuttycombe <kris.nuttycombe@gmail.com> wrote:

On Tue, Oct 27, 2009 at 9:38 AM, Rex Kerr <ichoran@gmail.com> wrote:
> On Mon, Oct 26, 2009 at 10:53 PM, Kris Nuttycombe
> <kris.nuttycombe@gmail.com> wrote:
>>
>> On Fri, Oct 23, 2009 at 9:40 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
>> > 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@gmail.com>
>> > wrote:
>> >>
>> >> Iterable and Comparable should suffice as examples for both.
>>
>> Or better yet, Function1[-A,+B]. Covariance and contravariance in one
>> neat little package. Makes total sense that the first parameter must
>> be contravariant and that the second may be covariant, too.
>
> To expand, suppose you have a function f that takes an A and returns a B,
> and you want a function g that can be used anywhere f can be used.
>
> Well, f takes an A, so g has to take every A also.  But it could take other
> things, too, and that would still work out.  So it's contravariant.
>
> Also, f returns a B, so g certainly has to return a B every time*, but the
> constraint is satisfied if it only returns a subset of Bs--in particular, if
> it returns only a subclass of B.  So it's covariant.
>
> Thus, functions are both contravariant and covariant: a drop-in replacement
> for a function must have an equal or larger domain (inputs) and an equal or
> smaller range (outputs).
>
>   --Rex
>
> * Actually, the true requirement is that g[A] is a subset of B, not that
> g[whatever g can take] is a subset of B; if you're using a language with
> dynamic typing, things will break if g actually returns a non-B when you
> feed it an A.  With static typing, you make an even stronger guarantee about
> g: not only will it return a B every time you feed it an A, but it will
> return a B no matter what you feed it.

Exactly. I think this illustrates an important point: that thinking
about covariance and contravariance in terms of subtyping may be
incorrect. Instead, perhaps one should think of subtyping in terms of
covariance.

The essential information for the type system to capture is what
values can be applied where. Given B <: A, X[-B] then an X[A] is
applicable anywhere an X[B] is. Similarly, a B is applicable anywhere
an A is. But while B is a subtype of A, there's no particular reason
to consider X[A] a subtype of X[B] - it is merely applicable in the
same locations. Reasoning about it this way, variance is the more
general principle and subtyping is a special case of covariance.

Does this make sense?

Kris

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

Sorry to remix the conversation threads, but that's what happens when
parallelising stuff :)

Good points - my point was that this is not everyone's daily bread and
butter. For 95%+ of developers out there, worrying about the overhead of a
paralelized collection and partial ordering is about as unnecessary and
counter-productive as worrying about a lazy Range (I'm still getting my head
around what exactly non-strict means). Not everyone works for Google :)

Thus drawing the generic conclusion that sequential access collections are
evil and should die - well, that's wrong! There are architectural and design
principles/patterns that may need upgrading, not every-day languages and
collection libraries.

Bottom line: it is utterly useless to start worrying about partial ordering
algorithms, to allow and benefit from a parallelization, when all I do is
put a Properties(name, value) of maybe 10 entries, into a web page, in
alphabetical sequence...

It is however utterly senseless that the Java compiler (or the scalac at
that) doesn't use both my cores when compiling my 1 million LOC project !
Yeah, +1+1+1+1+1+1+1 on that!

In terms of data flow and messaging (actors) - those are different
architectural styles that make efficient use of multithreading and
parallelism, agree.

Cheers

Russel Winder-4 wrote:
>
> On Fri, 2009-10-23 at 12:15 -0700, Razvan Cojocaru wrote:
>>
>> Dimitris 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/MITApril2009Ste...
>> >
>> > In short: "it's a fundamentally bad idea".
>> >
>> > Dimitris
>> >
>>
>> Sorry - read the ppt and I have to say that The Guy's wrong. Let's be
>> clear
>> - there is cost to parallelizing work. I'm not talking just about
>> assigning
>> threads to cores and switching threads and contexts on the cores, but
>> there's also cost in forking and joining values from the different
>> cores/threads.
>>
>> He's assuming that this cost is insignificant compared to the basic task
>> of
>> adding one or a few numbers. He's wrong. His presentation becomes of
>> value
>> when the task at hand is orders of magnitude higher than the cost of
>> paralelizing.
>
> He isn't wrong, I think you are just over analysing the examples used in
> a talk -- examples need to be inappropriately small for the
> presentation.
>
> You are right there is a cost to parallelizing work, but that is
> assumed. The ideas behind his talk and Fortress are from HPC and highly
> parallel computations. Whilst there may be infelicities in the slides,
> the overall message is right. The era of sequential computation as the
> whole application are now dead. The sooner we redefine algorithm to
> remove the word sequence from the definition so as to automatically
> assume parallel computation with sequential as a special case, the
> better.
>
>> In real life, unless you're compressing mpegs, you're most likely fine
>> using
>> sequential access collections... Parallelism can be used across tasks and
>> requests (i.e. http requests or whateveyou). Waiting for external systems
>> (like a file read or a data base read) is, in general, the most time
>> consuming of all tasks and the OS puts your threads to sleep anyhow.
>
> Indeed I/O is a Big Problem. Dealing with MPEGs is not the only highly
> parallel problem, there are many, many others. Embedding sequential
> access to collections as a principle is Bad Idea. Data parallelism is
> where the real action is going to be which is why Haskell is forging
> ahead with Data Parallel Haskell, and why Intel are forging ahead with C
> ++ Threading Building Blocks.
>
> If you are programming using threads then I'm afraid you are still in
> the computing dark ages ;-) They may be a way of realizing parallel
> computation, but they are the wrong tool for programming. But then this
> being Scala, I guess this is agreed.
>
>> So, while interesting, it's not very relevant...unless you're compressing
>> mpegs rather than adding numbers...but that's not every one's bread and
>> butter.
>>
>> Hell, does anyone remember OCCAM? For now, as-needed use of the method
>> below
>> is enough for me :)
>>
>> /** fork a bunch of threads, then join them and return the results */
>> def forkjoin[A,B<:AnyRef] (as:Iterable[A]) (f:A =>B) : Iterable[B] = {
>
> Many of us do indeed remember occam (NB fully lower case name despite
> being a proper noun). It was clearly a platform ahead of its time.
> There are many lessons to be learned from CSP as well as Actor Model.
> Also dataflow software architectures are on the rise and must no be
> ignored.
>

Daniel Sobral schrieb:
> This picture is nice, but there are no horses (or ponies), ducks,
> house, beaches, trees, cars people or anything like it in it.

Here you are:

http://www.hars.de/2009/10/variance-with-horses-and-people.html

- Florian.