Is Scala the Next C++

"My current plans are to start developing a facet of our code base with Scala without asking permission or approval - seeking forgiveness is always easier."

I suggest you create your own branch, write the same features that are being written in other language than Scala in Scala, write down the hours you spent on it and compare it in front of your colleagues after an iteration.
This way you'll do no harm to the team, you'll only need to sacrifice your own (outside of working hours) time, but that's going to be worth it :)

On Fri, Sep 9, 2011 at 9:40 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

I agree with Kevin that "Complex" and "Simple" are not the right terms
as there is no common definition and both depend on context and your
point of view.

I think what makes Scala harder to grasp then Java is not the language
itself as it has a very unified way of handling things. Not a lot of
special cases and let me say "regular".
Now what makes it "complex" is that Scala enables new Stuff paradigm
shift that Java Programmers are not accustomed to and that when first
discovered are hard to grasp.

An example:
Try explaining to someone who doesn't know what a closure is and how
he will benefit from it. Unless he has actually used one it will be
hard to grasp the construct and see why it is beneficial. After he has
used closures a couple of time he will soon realize how much easier it
is to code with them and how your code can be expressed more easily
and result in cleaner code.

Now take this up a notch by introducing Higherkinds enabling
Abstractions like Monads, Monoids, Semigroups, Applciatives, Functors
etc.. unless you have studied category theory it will be hard to grasp
these concepts and unless you actually have seen how to use them and
used them yourself you will not see the benefit they bring to the
table.But once you use them you will not live with out them and after
that the desire arises to actually understand them so you start
learning about monadic laws and suddenly Applicatives, Functors and
Monads start showing up all over the place making your code cleaner
easier to read and better to grasp for those that understands these
Abstractions. For those that don't your code looks like magic and they
say it is too complex.

But it is not the language that is complex it is the Abstractions that
are "complex" in the sense that they are not easy to grasp. I think it
would be beneficial if students would be taught these abstractions
instead of teaching them how to program Java. Hey if I learned Java by
myself so can you and if I can learn about categories and Monads,
Monoids etc so can you.

If you do not want to learn about these things then maybe you should
consider a different profession. In the End it does not matter
wheather Scala is the next C++, the next Java or will be lost in the
Ether because these Abstractions will prevail and can be applied to
any other language coming there after as long as it provides the
nessecary language constructs.

Just my 2cts.

Stefan

2011/9/9 Eric Kolotyluk <eric.kolotyluk@gmail.com>:
> OK, I think Kevin has a point - we can go back and forth about the semantics
> and philosophy of simple vs. complex - I think we need to find better words
> we can all agree on.
>
> Is it fair to say Scala is 'more sophisticated' (in the sense of refined as
> opposed to complicated) than Java?
>
> The reason for this particular discussion is that while there are some
> people very comfortable with Scala, there are many who are not.
>
> My personal experience with Scala is that it was harder for me learn Scala
> that it was for me to learn Java, even though Scala is not that different
> than Java. On the other hand, after gaining some competence with Scala, I
> was able to write 'cleaner code' much more readily than I was in Java. There
> are clearly trade-offs with Scala.
>
> The title of this discussion "Is Scala the Next C++" was intended to pose
> the question "in the future, can Scala get into the same sorts of difficulty
> that C++ did, and if so how can we avoid that?"
>
> It is one thing for me to learn Scala and use it for my personal needs.
> However, in the context of a person with considerable influence in my
> organization, am I ready to advocate and champion the use of Scala before my
> peers are ready for it? There are many of my peers who have turned their
> back on C++ even though they were quite competent with it at one time. Once
> they tasted Java they were extremely well motivated to avoid any further C++
> exposure. These same people have also avoided learning C# and .NET because
> they are content with Java. The number of developers in our ranks competent
> with C++ or willing to maintain the C++ code base continues to diminish.
>
> While I can see the compelling advantage of Scala, there are many who
> cannot, and will never. I still get criticism from some people because I
> integrated some Groovy into our product. We already have Pearl, Python and
> JavaScript - why do we need yet another scripting language - they ask? I
> have given several presentations on Scala to my peers - and they still ask -
> why do we need another language?
>
> My current plans are to start developing a facet of our code base with Scala
> without asking permission or approval - seeking forgiveness is always
> easier.
>
> Cheers, Eric
>
> On 2011-09-08 5:10 PM, Kevin Wright wrote:
>
> By any *objective* measurement of simplicity, Scala is definitely simpler
> than Java.
> EBNF productions in the language spec, number of defined keywords, etc.
> Then again, BrainF**k is one of the simplest languages going, based on those
> same measurements.
> So can we please stop talking about complexity and simplicity? They don't
> help a great deal, and you'd never get two people to agree 100% on the
> definition of the two terms.
>
> 2011/9/9 Cédric Beust ♔ <cedric@beust.com>
>>
>> 2011/9/8 Jörg W Mittag <2BUsenet [at] googlemail [dot] com" rel="nofollow">JoergWMittag+Usenet@googlemail.com>
>>>
>>> There is an important difference, though: C++ is more complex than C,
>>> but Scala is simpler than Java.
>>
>> A lot of people will probably disagree with you on this.
>> More expressive than Java, certainly. Simpler... definitely not.
>> --
>> Cédric
>
>
>

You've got a point Stefan, but then again - it resorts Scala into the academic community, making the learning curve steep for the "ordinary".

Next thing, I'd not compare Scala to Java or so, I think the best way how to teach Scala is to forget Java. Further, I'd go along with Martin Odersky's Scala Levels to teach it.
There're so many smart people in the Scala community and it needs more teachers and more focus on "new blood" - the beginners.
So far, my impression is that there's too much of focus on converts :)

jiri

--
web: http://www.dredwerkz.czblog: http://dr3dwerkz.blogspot.com/
code: https://github.com/g0dd4rd
group: http://groups.google.com/group/dr3dwerkz
music: http://profile.ultimate-guitar.com/g0dd4rd/
twitter: http://twitter.com/#!/g0dd4rd
profile: http://www.google.com/profiles/g0dd4rd
icq: 218 659 431

My experience of teaching Scala is that one of the more noteable "complexities" is the part where people have to unlearn Java patterns. e.g. You wouldn't get this from someone who didn't know about nulls:

"I already know how to use nulls, what's this 'Option' rubbish? Looks like some crazy idea from a bunch of academics that ctould never work in the real world" ~ Joe Programmer

There have been several blog posts and emails that find fault with `name: Type` and `Option[T]`, or want their statics and disjoint constructors back, which just shows that this is clearly an issue for some people.
I think there's an interesting article to be written here.  Taking a hypothetical person with some maths/algebra schooling, but no programming experience; then comparing the features that they would learn month-by-month in both Java and Scala



On 9 September 2011 09:49, Goddard Jiri <g0dd4rd@googlemail.com> wrote:

"My current plans are to start developing a facet of our code base with Scala without asking permission or approval - seeking forgiveness is always easier."

I suggest you create your own branch, write the same features that are being written in other language than Scala in Scala, write down the hours you spent on it and compare it in front of your colleagues after an iteration.
This way you'll do no harm to the team, you'll only need to sacrifice your own (outside of working hours) time, but that's going to be worth it :)

On Fri, Sep 9, 2011 at 9:40 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

I agree with Kevin that "Complex" and "Simple" are not the right terms
as there is no common definition and both depend on context and your
point of view.

I think what makes Scala harder to grasp then Java is not the language
itself as it has a very unified way of handling things. Not a lot of
special cases and let me say "regular".
Now what makes it "complex" is that Scala enables new Stuff paradigm
shift that Java Programmers are not accustomed to and that when first
discovered are hard to grasp.

An example:
Try explaining to someone who doesn't know what a closure is and how
he will benefit from it. Unless he has actually used one it will be
hard to grasp the construct and see why it is beneficial. After he has
used closures a couple of time he will soon realize how much easier it
is to code with them and how your code can be expressed more easily
and result in cleaner code.

Now take this up a notch by introducing Higherkinds enabling
Abstractions like Monads, Monoids, Semigroups, Applciatives, Functors
etc.. unless you have studied category theory it will be hard to grasp
these concepts and unless you actually have seen how to use them and
used them yourself you will not see the benefit they bring to the
table.But once you use them you will not live with out them and after
that the desire arises to actually understand them so you start
learning about monadic laws and suddenly Applicatives, Functors and
Monads start showing up all over the place making your code cleaner
easier to read and better to grasp for those that understands these
Abstractions. For those that don't your code looks like magic and they
say it is too complex.

But it is not the language that is complex it is the Abstractions that
are "complex" in the sense that they are not easy to grasp. I think it
would be beneficial if students would be taught these abstractions
instead of teaching them how to program Java. Hey if I learned Java by
myself so can you and if I can learn about categories and Monads,
Monoids etc so can you.

If you do not want to learn about these things then maybe you should
consider a different profession. In the End it does not matter
wheather Scala is the next C++, the next Java or will be lost in the
Ether because these Abstractions will prevail and can be applied to
any other language coming there after as long as it provides the
nessecary language constructs.

Just my 2cts.

Stefan

2011/9/9 Eric Kolotyluk <eric.kolotyluk@gmail.com>:
> OK, I think Kevin has a point - we can go back and forth about the semantics
> and philosophy of simple vs. complex - I think we need to find better words
> we can all agree on.
>
> Is it fair to say Scala is 'more sophisticated' (in the sense of refined as
> opposed to complicated) than Java?
>
> The reason for this particular discussion is that while there are some
> people very comfortable with Scala, there are many who are not.
>
> My personal experience with Scala is that it was harder for me learn Scala
> that it was for me to learn Java, even though Scala is not that different
> than Java. On the other hand, after gaining some competence with Scala, I
> was able to write 'cleaner code' much more readily than I was in Java. There
> are clearly trade-offs with Scala.
>
> The title of this discussion "Is Scala the Next C++" was intended to pose
> the question "in the future, can Scala get into the same sorts of difficulty
> that C++ did, and if so how can we avoid that?"
>
> It is one thing for me to learn Scala and use it for my personal needs.
> However, in the context of a person with considerable influence in my
> organization, am I ready to advocate and champion the use of Scala before my
> peers are ready for it? There are many of my peers who have turned their
> back on C++ even though they were quite competent with it at one time. Once
> they tasted Java they were extremely well motivated to avoid any further C++
> exposure. These same people have also avoided learning C# and .NET because
> they are content with Java. The number of developers in our ranks competent
> with C++ or willing to maintain the C++ code base continues to diminish.
>
> While I can see the compelling advantage of Scala, there are many who
> cannot, and will never. I still get criticism from some people because I
> integrated some Groovy into our product. We already have Pearl, Python and
> JavaScript - why do we need yet another scripting language - they ask? I
> have given several presentations on Scala to my peers - and they still ask -
> why do we need another language?
>
> My current plans are to start developing a facet of our code base with Scala
> without asking permission or approval - seeking forgiveness is always
> easier.
>
> Cheers, Eric
>
> On 2011-09-08 5:10 PM, Kevin Wright wrote:
>
> By any *objective* measurement of simplicity, Scala is definitely simpler
> than Java.
> EBNF productions in the language spec, number of defined keywords, etc.
> Then again, BrainF**k is one of the simplest languages going, based on those
> same measurements.
> So can we please stop talking about complexity and simplicity? They don't
> help a great deal, and you'd never get two people to agree 100% on the
> definition of the two terms.
>
> 2011/9/9 Cédric Beust ♔ <cedric@beust.com>
>>
>> 2011/9/8 Jörg W Mittag <2BUsenet [at] googlemail [dot] com" target="_blank" rel="nofollow">JoergWMittag+Usenet@googlemail.com>
>>>
>>> There is an important difference, though: C++ is more complex than C,
>>> but Scala is simpler than Java.
>>
>> A lot of people will probably disagree with you on this.
>> More expressive than Java, certainly. Simpler... definitely not.
>> --
>> Cédric
>
>
>

You've got a point Stefan, but then again - it resorts Scala into the academic community, making the learning curve steep for the "ordinary".

Next thing, I'd not compare Scala to Java or so, I think the best way how to teach Scala is to forget Java. Further, I'd go along with Martin Odersky's Scala Levels to teach it.
There're so many smart people in the Scala community and it needs more teachers and more focus on "new blood" - the beginners.
So far, my impression is that there's too much of focus on converts :)

jiri

On 9 Sep 2011, at 10:10, Kevin Wright wrote:
> I think there's an interesting article to be written here. Taking a hypothetical person with some maths/algebra schooling, but no programming experience; then comparing the features that they would learn month-by-month in both Java and Scala

This isn't quite the same as what you're proposing, but the university at which I did my degree (Durham, UK) did experiment with introducing students to functional, instead of procedural, programming way back in the 1980s (I was there from 1986-1989).

My year did the "normal" stuff - we started with Pascal and then moved on to ML and Prolog.

The year immediately after us, by contrast, started off with functional programming (Miranda), only coming to a more traditional language (Modula 2) afterwards.

I didn't have any direct experience of this, so everything I know is anecdotal, but I do know that this approach was very unpopular with the students, with half of them dropping out at or before the end of the first year of the course. The following year, the university reverted to a more traditional approach of introducing programming with a procedural language first before moving on to talking about functional languages.

Of course, this might say more about Miranda, or how it was taught, or the students who happened to be in that year, or...

But it's a data point :-)

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

Joe Programmer hasn't heard of patterns either, probably :)
I remember there was the same schism when Java came around and people got the problem like "OMG OO, WTF?" etc.

jiri

On Fri, Sep 9, 2011 at 11:10 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

My experience of teaching Scala is that one of the more noteable "complexities" is the part where people have to unlearn Java patterns. e.g. You wouldn't get this from someone who didn't know about nulls:

"I already know how to use nulls, what's this 'Option' rubbish? Looks like some crazy idea from a bunch of academics that ctould never work in the real world" ~ Joe Programmer

There have been several blog posts and emails that find fault with `name: Type` and `Option[T]`, or want their statics and disjoint constructors back, which just shows that this is clearly an issue for some people.
I think there's an interesting article to be written here.  Taking a hypothetical person with some maths/algebra schooling, but no programming experience; then comparing the features that they would learn month-by-month in both Java and Scala



On 9 September 2011 09:49, Goddard Jiri <g0dd4rd@googlemail.com> wrote:

"My current plans are to start developing a facet of our code base with Scala without asking permission or approval - seeking forgiveness is always easier."

I suggest you create your own branch, write the same features that are being written in other language than Scala in Scala, write down the hours you spent on it and compare it in front of your colleagues after an iteration.
This way you'll do no harm to the team, you'll only need to sacrifice your own (outside of working hours) time, but that's going to be worth it :)

On Fri, Sep 9, 2011 at 9:40 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

I agree with Kevin that "Complex" and "Simple" are not the right terms
as there is no common definition and both depend on context and your
point of view.

I think what makes Scala harder to grasp then Java is not the language
itself as it has a very unified way of handling things. Not a lot of
special cases and let me say "regular".
Now what makes it "complex" is that Scala enables new Stuff paradigm
shift that Java Programmers are not accustomed to and that when first
discovered are hard to grasp.

An example:
Try explaining to someone who doesn't know what a closure is and how
he will benefit from it. Unless he has actually used one it will be
hard to grasp the construct and see why it is beneficial. After he has
used closures a couple of time he will soon realize how much easier it
is to code with them and how your code can be expressed more easily
and result in cleaner code.

Now take this up a notch by introducing Higherkinds enabling
Abstractions like Monads, Monoids, Semigroups, Applciatives, Functors
etc.. unless you have studied category theory it will be hard to grasp
these concepts and unless you actually have seen how to use them and
used them yourself you will not see the benefit they bring to the
table.But once you use them you will not live with out them and after
that the desire arises to actually understand them so you start
learning about monadic laws and suddenly Applicatives, Functors and
Monads start showing up all over the place making your code cleaner
easier to read and better to grasp for those that understands these
Abstractions. For those that don't your code looks like magic and they
say it is too complex.

But it is not the language that is complex it is the Abstractions that
are "complex" in the sense that they are not easy to grasp. I think it
would be beneficial if students would be taught these abstractions
instead of teaching them how to program Java. Hey if I learned Java by
myself so can you and if I can learn about categories and Monads,
Monoids etc so can you.

If you do not want to learn about these things then maybe you should
consider a different profession. In the End it does not matter
wheather Scala is the next C++, the next Java or will be lost in the
Ether because these Abstractions will prevail and can be applied to
any other language coming there after as long as it provides the
nessecary language constructs.

Just my 2cts.

Stefan

2011/9/9 Eric Kolotyluk <eric.kolotyluk@gmail.com>:
> OK, I think Kevin has a point - we can go back and forth about the semantics
> and philosophy of simple vs. complex - I think we need to find better words
> we can all agree on.
>
> Is it fair to say Scala is 'more sophisticated' (in the sense of refined as
> opposed to complicated) than Java?
>
> The reason for this particular discussion is that while there are some
> people very comfortable with Scala, there are many who are not.
>
> My personal experience with Scala is that it was harder for me learn Scala
> that it was for me to learn Java, even though Scala is not that different
> than Java. On the other hand, after gaining some competence with Scala, I
> was able to write 'cleaner code' much more readily than I was in Java. There
> are clearly trade-offs with Scala.
>
> The title of this discussion "Is Scala the Next C++" was intended to pose
> the question "in the future, can Scala get into the same sorts of difficulty
> that C++ did, and if so how can we avoid that?"
>
> It is one thing for me to learn Scala and use it for my personal needs.
> However, in the context of a person with considerable influence in my
> organization, am I ready to advocate and champion the use of Scala before my
> peers are ready for it? There are many of my peers who have turned their
> back on C++ even though they were quite competent with it at one time. Once
> they tasted Java they were extremely well motivated to avoid any further C++
> exposure. These same people have also avoided learning C# and .NET because
> they are content with Java. The number of developers in our ranks competent
> with C++ or willing to maintain the C++ code base continues to diminish.
>
> While I can see the compelling advantage of Scala, there are many who
> cannot, and will never. I still get criticism from some people because I
> integrated some Groovy into our product. We already have Pearl, Python and
> JavaScript - why do we need yet another scripting language - they ask? I
> have given several presentations on Scala to my peers - and they still ask -
> why do we need another language?
>
> My current plans are to start developing a facet of our code base with Scala
> without asking permission or approval - seeking forgiveness is always
> easier.
>
> Cheers, Eric
>
> On 2011-09-08 5:10 PM, Kevin Wright wrote:
>
> By any *objective* measurement of simplicity, Scala is definitely simpler
> than Java.
> EBNF productions in the language spec, number of defined keywords, etc.
> Then again, BrainF**k is one of the simplest languages going, based on those
> same measurements.
> So can we please stop talking about complexity and simplicity? They don't
> help a great deal, and you'd never get two people to agree 100% on the
> definition of the two terms.
>
> 2011/9/9 Cédric Beust ♔ <cedric@beust.com>
>>
>> 2011/9/8 Jörg W Mittag <2BUsenet [at] googlemail [dot] com" target="_blank" rel="nofollow">JoergWMittag+Usenet@googlemail.com>
>>>
>>> There is an important difference, though: C++ is more complex than C,
>>> but Scala is simpler than Java.
>>
>> A lot of people will probably disagree with you on this.
>> More expressive than Java, certainly. Simpler... definitely not.
>> --
>> Cédric
>
>
>

You've got a point Stefan, but then again - it resorts Scala into the academic community, making the learning curve steep for the "ordinary".

Next thing, I'd not compare Scala to Java or so, I think the best way how to teach Scala is to forget Java. Further, I'd go along with Martin Odersky's Scala Levels to teach it.
There're so many smart people in the Scala community and it needs more teachers and more focus on "new blood" - the beginners.
So far, my impression is that there's too much of focus on converts :)

jiri

--
web: http://www.dredwerkz.czblog: http://dr3dwerkz.blogspot.com/
code: https://github.com/g0dd4rd
group: http://groups.google.com/group/dr3dwerkz
music: http://profile.ultimate-guitar.com/g0dd4rd/
twitter: http://twitter.com/#!/g0dd4rd
profile: http://www.google.com/profiles/g0dd4rd
icq: 218 659 431

Interesting, I wonder how many of those who succeeded in the non-functional course later discovered that programming really wasn't "for them", and would have discovered this sooner given the functional approach.
It's not so good for the university to have dropouts, but perhaps we're not doing the students any favours by lulling them into a false sense of confidence because it boosts pass rates.
The possible explanations are too varied as well:- FP was too familiar with people who already had prior experience of programming via basic and scripting- The instructors were less familiar with teaching in that style - miranda was perceived as having no commercial relevance- etc.
Still, it *is* an interesting data point!  We need more...
Personally, I was lucky to get early exposure to FP. I started with Logo :)

On 9 September 2011 10:35, Paul Butcher <paul@paulbutcher.com> wrote:

On 9 Sep 2011, at 10:10, Kevin Wright wrote:
> I think there's an interesting article to be written here.  Taking a hypothetical person with some maths/algebra schooling, but no programming experience; then comparing the features that they would learn month-by-month in both Java and Scala

This isn't quite the same as what you're proposing, but the university at which I did my degree (Durham, UK) did experiment with introducing students to functional, instead of procedural, programming way back in the 1980s (I was there from 1986-1989).

My year did the "normal" stuff - we started with Pascal and then moved on to ML and Prolog.

The year immediately after us, by contrast, started off with functional programming (Miranda), only coming to a more traditional language (Modula 2) afterwards.

I didn't have any direct experience of this, so everything I know is anecdotal, but I do know that this approach was very unpopular with the students, with half of them dropping out at or before the end of the first year of the course. The following year, the university reverted to a more traditional approach of introducing programming with a procedural language first before moving on to talking about functional languages.

Of course, this might say more about Miranda, or how it was taught, or the students who happened to be in that year, or...

But it's a data point :-)

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On 09/09/2011 11:35, Paul Butcher wrote:
> [...]
> I didn't have any direct experience of this, so everything I know is anecdotal, but I do know that this approach was very unpopular with the students, with half of them dropping out at or before the end of the first year of the course. The following year, the university reverted to a more traditional approach of introducing programming with a procedural language first before moving on to talking about functional languages.
>
> Of course, this might say more about Miranda, or how it was taught, or the students who happened to be in that year, or...

As said elsewhere, my school do teach OCaml as first language for
programming introduction, algorithms and the like, and just afterward
(so that the two courses are more or less at the same time of the year,
in the first semester), C is introduce for system programming.

What I do exeriment was that OCaml was quite like for among student with
no prior exeriment of programming (I was such a student): it allows to
rather directly map algorithms to code and let accidental complexity
(for that kind of stuff) like memory management apart.

On the other hand, it was hated by other. More preciselly, the more
experienced the student was with a prior language (we had first year
student who were C or Java killers), the more he hated OCaml.

For my personnal experience: I loved OCaml, and that lead me to love
programming, and choose the most semantic oriented cursus in my school,
ending in a Coq project proving compiler. But I liked a lot C too, which
was the right tool for our kernel implementation project. But I never
succeed in understanding what C++ was aim for (unlike PHP, even if it
was also in my "fly from it" category of language to use).

On 09/09/2011 06:34, Raoul Duke wrote:
> On Thu, Sep 8, 2011 at 6:58 PM, Eric Kolotyluk wrote:
>> have given several presentations on Scala to my peers - and they still ask -
>> why do we need another language?
>
> heck, i love programming languages, but to some degree these folks do
> have a valid point!

Yes and no...
Why do we need hybrid cars, we have already fossil fuel ones.
Why do we need smartphones, dumb phones already work well.
Why make metallic rawplugs, the plastic ones were working well enough.

So, basically, why make innovations, the old ways are good enough...

Now, I reckon than, among other things, the flurry of new programmings languages (in JVM
and outside (Go, Rusty...)) is dizzying!

And the reason Scala was harder to learn than to learn Java is that we learn not only a
new syntax, but also (for lot of us), new paradigms.
Likewise, even after learning several (imperative) programming languages, I found hard to
learn C++, even if the syntax was familiar (I coded lot of C), because I struggled to get
the OOP paradigm, vocabulary, concepts, way of thinking. Idem, now, for functional
programming, and using immutability. Currently, I take baby steps, not thinking too hard
how to make all my variables immutable[1], although being aware of the challenges, and
going on with my Scala discovery. I know that with experience, it will feel more natural.

[1] If you search var in the Scala sources, you will still find a number of occurrences,
like, unsurprisingly, in iterators. Sometime, performance wins over purity... :-)

On 09/09/2011 09:40, Stefan Langer wrote:
> If you do not want to learn about these things then maybe you should
> consider a different profession.

Not necessarily. Lot of programmers are successful using Visual Basic, PHP or JavaScript
(nothing about these languages, I used or use them).

I did Miranda at university (Kent, UK), and I will freely admit that
it was very challenging. I seem to remember thinking "neat, but
useless" at the time. Oh if only if I knew then what I know now. ;)

But actually, although that course was hard, it was rather tempered by
the fact that Miranda was only one of many languages taught. We also
did Occam, assembler and Java the first year, and others like Prolog
in later years. (I think they dropped Miranda for Haskell and have
also taken up Erlang these days.)

Perhaps unsurprisingly, I now think showing students many different
paradigms is really key for a CS degree. I'm quite surprised this is
not something that all CS courses do (I have no numbers on that).

Kieron

On Sep 9, 10:35 am, Paul Butcher

wrote:
> On 9 Sep 2011, at 10:10, Kevin Wright wrote:
>
> > I think there's an interesting article to be written here.  Taking a hypothetical person with some maths/algebra schooling, but no programming experience; then comparing the features that they would learn month-by-month in both Java and Scala
>
> This isn't quite the same as what you're proposing, but the university at which I did my degree (Durham, UK) did experiment with introducing students to functional, instead of procedural, programming way back in the 1980s (I was there from 1986-1989).
>
> My year did the "normal" stuff - we started with Pascal and then moved on to ML and Prolog.
>
> The year immediately after us, by contrast, started off with functional programming (Miranda), only coming to a more traditional language (Modula 2) afterwards.
>
> I didn't have any direct experience of this, so everything I know is anecdotal, but I do know that this approach was very unpopular with the students, with half of them dropping out at or before the end of the first year of the course. The following year, the university reverted to a more traditional approach of introducing programming with a procedural language first before moving on to talking about functional languages.
>
> Of course, this might say more about Miranda, or how it was taught, or the students who happened to be in that year, or...
>
> But it's a data point :-)
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn:http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher

And it is those programmers that produce lots of problems in big teams
but now I'm just ranting along

2011/9/9 Philippe Lhoste :
> On 09/09/2011 09:40, Stefan Langer wrote:
>>
>> If you do not want to learn about these things then maybe you should
>> consider a different profession.
>
> Not necessarily. Lot of programmers are successful using Visual Basic, PHP
> or JavaScript (nothing about these languages, I used or use them).
>
> --
> Philippe Lhoste

On 2011-09-08 9:34 PM, Raoul Duke wrote:
> On Thu, Sep 8, 2011 at 6:58 PM, Eric Kolotyluk wrote:
>> integrated some Groovy into our product. We already have Pearl, Python and
>> JavaScript - why do we need yet another scripting language - they ask? I
>> have given several presentations on Scala to my peers - and they still ask -
>> why do we need another language?
> heck, i love programming languages, but to some degree these folks do
> have a valid point!
Well, the Pearl was for a utility for decoding our error reports, that
written by someone who left long ago. A few of us have had to go in and
try enhance the code every now and then, but I personally find it a
nightmare to try to figure out. I started rewriting this in Java, but
never got around to finishing.

The Python is used by our test team for automated test scripts, and it
not exactly part of our product.

The JavaScript was used by one of our support guys to make changes to
the firmware on a piece of custom hardware we used to build. Since we no
longer manufacture that hardware any more there is no need for this anymore.

The Groovy was embedded in our client UI for the test team to automate
launching the client in particular scenarios. Groovy was chosen because
it is a scripting language, and it makes it easy to call Java directly,
which our client is written in. In particular, you can customize the
start-up of our client, as a released product, without having to
actually change the source code of the product. I probably could have
done something similar with JPython, but I wanted to assess the efficacy
of Groovy in a real situation. I could have used Scala at the time, but
was having trouble understanding Scala at the time and settled on Groovy
instead because it was so easy to learn.

The main body of our client UI is Java, and our server is C++/COM, with
increasing usage of C#/.NET. It would still all be C++/COM if not for
one person (not me) who pioneered and championed its use. Since then it
has allowed other people (like me) to contribute to our server features
without having to enter the C++/COM world. Very little new work is done
in C++/COM. I have pointed out on several occasions that almost
everything done in C#/.NET could have been just as easily done in Java -
or more easily from my perspective - and we could have avoided yet
another language/platform. On the other hand it did force me to learn
C#/.NET.

We are not exactly language maniacs, and the core of our product is
still just 3 languages, with active development in 2. By now you may
have guessed by now our product is not a web application ;-)

Cheers, Eric

First, apologies for sending this direct... I thought I hit undo fast
enough, evidently not. :(

On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
wrote:
> And it is those programmers that produce lots of problems in big teams
> but now I'm just ranting along

I was going to chime in on this topic. I'll pick up here. I think it
is somewhat misleading to think that everyone must learn the theory
behind programming to learn their tools better. My analogy of choice
is to music. There are some very talented guitarist out there that
don't know music theory at all. They got really good with their
instrument. Likely they discovered some of the underlying things that
you would understand from theory, but they did not have to go the
theory route.

I liken this to patterns. Patterns are just recognizing some common
elements seen throughout varied programs. The "theory" grounded
topics explain why certain things work. (Similarly, the theory can
help explain why some tempting anti-patterns do not work.)

So, it is not necessary to have people become fluent in other topics
than the language they are using. Just don't expect them to do things
that are not "in the language" easily. Specifically, do not try and
force abstractions on them that are not easily expressed in the
language. (I personally think this is what makes some stuff difficult
to understand from Scala. There is no easy equivalent in Java. There
are often approximations, but those often cause as much harm as they
solve.)

"The JavaScript was used by one of our support guys to make changes to the firmware on a piece of custom hardware we used to build. Since we no longer manufacture that hardware any more there is no need for this anymore." - very interesting choice

jiri


--
web: http://www.dredwerkz.czblog: http://dr3dwerkz.blogspot.com/
code: https://github.com/g0dd4rd
group: http://groups.google.com/group/dr3dwerkz
music: http://profile.ultimate-guitar.com/g0dd4rd/
twitter: http://twitter.com/#!/g0dd4rd
profile: http://www.google.com/profiles/g0dd4rd
icq: 218 659 431

On 9 September 2011 14:36, Josh Berry <taeric@gmail.com> wrote:

First, apologies for sending this direct...  I thought I hit undo fast
enough, evidently not. :(

On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
<mailtolanger@googlemail.com> wrote:
> And it is those programmers that produce lots of problems in big teams
> but now I'm just ranting along

I was going to chime in on this topic.  I'll pick up here.  I think it
is somewhat misleading to think that everyone must learn the theory
behind programming to learn their tools better.  My analogy of choice
is to music.  There are some very talented guitarist out there that
don't know music theory at all.  They got really good with their
instrument.  Likely they discovered some of the underlying things that
you would understand from theory, but they did not have to go the
theory route.

I liken this to patterns.  Patterns are just recognizing some common
elements seen throughout varied programs.  The "theory" grounded
topics explain why certain things work.  (Similarly, the theory can
help explain why some tempting anti-patterns do not work.)

So, it is not necessary to have people become fluent in other topics
than the language they are using.  Just don't expect them to do things
that are not "in the language" easily.   Specifically, do not try and
force abstractions on them that are not easily expressed in the
language.  (I personally think this is what makes some stuff difficult
to understand from Scala.  There is no easy equivalent in Java.  There
are often approximations, but those often cause as much harm as they
solve.)

Music is a much better analogy than you might have first thought.  Imagine only learning music in C-major on a non-polyphonic electric keyboard, with all the black keys removed for the sake of simplicity, and because they're not all that necessary in C-major.
Sure, you can play other scales by transposing. The only difference between C-major and A-minor is what note you start on (useful tidbit there for anyone who wondered why we start at C - We don't! minor scales were more common when the system came about).  But that assumes you know the existence of other scales in the first place, and transposing requires more technical ability than just playing directly in C-minor to start with.
Even then, it doesn't sound quite right.  Pianos and keyboards are a so-called "tempered" instrument, which means that transposing won't shift the frequency of the scale evenly.  Composers use this property of different keys to subtly shift the feel of a piece, above and beyond the more obvious major/minor distinction.
I won't even get into the subject of modes :)
For polyphonic music, it gets even harder.  You *need* those black keys when playing chord sequences.
Key:black keys = FP constructspolyphony = concurrency"My First Keyboard"(tm) = java
note: A good musician will tell you that c-sharp (for example) is ever so slightly lower in pitch than d-flat.  Violinists know this, as do really good woodwind players.  Tempering is when you force them to be the same.
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On 2011-09-09 1:48 AM, Francois wrote:
> On 09/09/2011 09:40, Stefan Langer wrote:
>> [...]
>>
>> But it is not the language that is complex it is the Abstractions that
>> are "complex" in the sense that they are not easy to grasp. I think it
>> would be beneficial if students would be taught these abstractions
>> instead of teaching them how to program Java. Hey if I learned Java by
>> myself so can you and if I can learn about categories and Monads,
>> Monoids etc so can you.
>>
>> If you do not want to learn about these things then maybe you should
>> consider a different profession. In the End it does not matter
>> wheather Scala is the next C++, the next Java or will be lost in the
>> Ether because these Abstractions will prevail and can be applied to
>> any other language coming there after as long as it provides the
>> nessecary language constructs.
>>
>
>
> Wow, I'm really impressed: you succeeded to make a really well argued,
> clear and interesting answer to a quite trolling subject. Thanks for
> that!
>
>
Yes, add my praise to that of Francios

Cheers, Eric

I completely agree with Stefan!

This may be a bad analogy, but asking some to learn Scala is like asking
them to learn calculus while learning Java is like learning algebra. The
point is that calculus is able to express many problems more elegantly
(simply) than algebra, but the student has to learn calculus when they
are already content with algebra.

How you present things is important too. I had trouble with closures
until I saw the similarity to anonymous inner classes in Java, but once
I made the connection I was able to grok closures, and how much better
they were than anonymous inner classes. I just heard that the Java
language designers finally chose the C# and Scala syntax for closures in
Java 8, which is extremely fortunate. As Java 8 programmers learn to use
closures, they will find one less intimidating thing about Scala.

From my perspective Scala is like swimming on the beach in the ocean -
you can swim around in the shallow end all you like, but there is a
whole ocean out there to explore still -- while Java is like swimming on
the beach in a large lake. My hope is more people will realize you can
still be productive in Scala without requiring to master functional
programming and higher levels of abstraction. Swimming in shallow water
is the same whether it is an ocean or a lake - although you can float a
little better in the salt water of Scala :-)

The reason I still try to contrast Scala's future with C++'s past, is
that you are more likely to find pirates sea monsters in the ocean than
a lake :-)

I have been writing code for over 40 years, and I am struggling a little
with these new higher abstractions, but they are also what makes Scala
so seductive. Some old dogs can learn new tricks. Maybe younger coders
with a fresher computing science education will fair better with Scala,
but I believe all serious coders need to learn the new abstractions (or
try to learn) because they are a step in the right direction to writing
better code.

Cheers, Eric

On 2011-09-09 12:40 AM, Stefan Langer wrote:
> I agree with Kevin that "Complex" and "Simple" are not the right terms
> as there is no common definition and both depend on context and your
> point of view.
>
> I think what makes Scala harder to grasp then Java is not the language
> itself as it has a very unified way of handling things. Not a lot of
> special cases and let me say "regular".
> Now what makes it "complex" is that Scala enables new Stuff paradigm
> shift that Java Programmers are not accustomed to and that when first
> discovered are hard to grasp.
>
> An example:
> Try explaining to someone who doesn't know what a closure is and how
> he will benefit from it. Unless he has actually used one it will be
> hard to grasp the construct and see why it is beneficial. After he has
> used closures a couple of time he will soon realize how much easier it
> is to code with them and how your code can be expressed more easily
> and result in cleaner code.
>
> Now take this up a notch by introducing Higherkinds enabling
> Abstractions like Monads, Monoids, Semigroups, Applciatives, Functors
> etc.. unless you have studied category theory it will be hard to grasp
> these concepts and unless you actually have seen how to use them and
> used them yourself you will not see the benefit they bring to the
> table.But once you use them you will not live with out them and after
> that the desire arises to actually understand them so you start
> learning about monadic laws and suddenly Applicatives, Functors and
> Monads start showing up all over the place making your code cleaner
> easier to read and better to grasp for those that understands these
> Abstractions. For those that don't your code looks like magic and they
> say it is too complex.
>
> But it is not the language that is complex it is the Abstractions that
> are "complex" in the sense that they are not easy to grasp. I think it
> would be beneficial if students would be taught these abstractions
> instead of teaching them how to program Java. Hey if I learned Java by
> myself so can you and if I can learn about categories and Monads,
> Monoids etc so can you.
>
> If you do not want to learn about these things then maybe you should
> consider a different profession. In the End it does not matter
> wheather Scala is the next C++, the next Java or will be lost in the
> Ether because these Abstractions will prevail and can be applied to
> any other language coming there after as long as it provides the
> nessecary language constructs.
>
> Just my 2cts.
>
> Stefan
>
> 2011/9/9 Eric Kolotyluk:
>> OK, I think Kevin has a point - we can go back and forth about the semantics
>> and philosophy of simple vs. complex - I think we need to find better words
>> we can all agree on.
>>
>> Is it fair to say Scala is 'more sophisticated' (in the sense of refined as
>> opposed to complicated) than Java?
>>
>> The reason for this particular discussion is that while there are some
>> people very comfortable with Scala, there are many who are not.
>>
>> My personal experience with Scala is that it was harder for me learn Scala
>> that it was for me to learn Java, even though Scala is not that different
>> than Java. On the other hand, after gaining some competence with Scala, I
>> was able to write 'cleaner code' much more readily than I was in Java. There
>> are clearly trade-offs with Scala.
>>
>> The title of this discussion "Is Scala the Next C++" was intended to pose
>> the question "in the future, can Scala get into the same sorts of difficulty
>> that C++ did, and if so how can we avoid that?"
>>
>> It is one thing for me to learn Scala and use it for my personal needs.
>> However, in the context of a person with considerable influence in my
>> organization, am I ready to advocate and champion the use of Scala before my
>> peers are ready for it? There are many of my peers who have turned their
>> back on C++ even though they were quite competent with it at one time. Once
>> they tasted Java they were extremely well motivated to avoid any further C++
>> exposure. These same people have also avoided learning C# and .NET because
>> they are content with Java. The number of developers in our ranks competent
>> with C++ or willing to maintain the C++ code base continues to diminish.
>>
>> While I can see the compelling advantage of Scala, there are many who
>> cannot, and will never. I still get criticism from some people because I
>> integrated some Groovy into our product. We already have Pearl, Python and
>> JavaScript - why do we need yet another scripting language - they ask? I
>> have given several presentations on Scala to my peers - and they still ask -
>> why do we need another language?
>>
>> My current plans are to start developing a facet of our code base with Scala
>> without asking permission or approval - seeking forgiveness is always
>> easier.
>>
>> Cheers, Eric
>>
>> On 2011-09-08 5:10 PM, Kevin Wright wrote:
>>
>> By any *objective* measurement of simplicity, Scala is definitely simpler
>> than Java.
>> EBNF productions in the language spec, number of defined keywords, etc.
>> Then again, BrainF**k is one of the simplest languages going, based on those
>> same measurements.
>> So can we please stop talking about complexity and simplicity? They don't
>> help a great deal, and you'd never get two people to agree 100% on the
>> definition of the two terms.
>>
>> 2011/9/9 Cédric Beust ♔
>>> 2011/9/8 Jörg W Mittag
>>>> There is an important difference, though: C++ is more complex than C,
>>>> but Scala is simpler than Java.
>>> A lot of people will probably disagree with you on this.
>>> More expressive than Java, certainly. Simpler... definitely not.
>>> --
>>> Cédric
>>
>>

On Fri, Sep 9, 2011 at 9:56 AM, Kevin Wright wrote:
> Music is a much better analogy than you might have first thought.  Imagine
> only learning music in C-major on a non-polyphonic electric keyboard, with
> all the black keys removed for the sake of simplicity, and because they're
> not all that necessary in C-major.

You are still hitting the theory, though. Go more basic. Imagine
learning to play on a Ukulele without any training in music theory at
all. It can probably be done. I bet there are some folks that make
really good music that way.

Now, the question I have comes down to this. Which would allow these
people to make better music. Investing in a more capable
tool/language, or deepening their understanding of what they are
doing? My gut guess is it will depend largely on the individual, with
the learning of "what they are doing" having an edge. And,
eventually, they will hit the limitations of the tools they are
currently using, of course.

This is akin to my current skepticism of IDEs helping make people more
productive. I think learning what you are trying to do helps more.
(I had a subthread about this on Cedric's blog recently.)

LOL

Yes, I know a few Joes, and I totally understand where they are coming from.

It took me a while to understand Option, but I do appreciate why it is better than null, the same way returning an empty collection is usually better than returning null. I am lazy sometimes, and need to learn to use Option more often than I do.

Using Option is like brushing your teeth - to prevent problems later on. Using null is like not brushing your teeth - it is easier now, but more troublesome later.

Thanks for that insight Kevin.

Cheer,s Eric

On 2011-09-09 2:10 AM, Kevin Wright wrote:

CABHxxC2naj80Azbd9X0QOMZJ2HqHdd9_4YR77c907xLhEkWwcw [at] mail [dot] gmail [dot] com" type="cite">My experience of teaching Scala is that one of the more noteable "complexities" is the part where people have to unlearn Java patterns. e.g. You wouldn't get this from someone who didn't know about nulls:

"I already know how to use nulls, what's this 'Option' rubbish? Looks like some crazy idea from a bunch of academics that ctould never work in the real world" ~ Joe Programmer

There have been several blog posts and emails that find fault with `name: Type` and `Option[T]`, or want their statics and disjoint constructors back, which just shows that this is clearly an issue for some people.
I think there's an interesting article to be written here.  Taking a hypothetical person with some maths/algebra schooling, but no programming experience; then comparing the features that they would learn month-by-month in both Java and Scala



On 9 September 2011 09:49, Goddard Jiri <g0dd4rd [at] googlemail [dot] com" rel="nofollow">g0dd4rd@googlemail.com> wrote:

"My current plans are to start developing a facet of our code base with Scala without asking permission or approval - seeking forgiveness is always easier."

I suggest you create your own branch, write the same features that are being written in other language than Scala in Scala, write down the hours you spent on it and compare it in front of your colleagues after an iteration.
This way you'll do no harm to the team, you'll only need to sacrifice your own (outside of working hours) time, but that's going to be worth it :)

On Fri, Sep 9, 2011 at 9:40 AM, Stefan Langer <mailtolanger [at] googlemail [dot] com" target="_blank" rel="nofollow">mailtolanger@googlemail.com> wrote:

I agree with Kevin that "Complex" and "Simple" are not the right terms
as there is no common definition and both depend on context and your
point of view.

I think what makes Scala harder to grasp then Java is not the language
itself as it has a very unified way of handling things. Not a lot of
special cases and let me say "regular".
Now what makes it "complex" is that Scala enables new Stuff paradigm
shift that Java Programmers are not accustomed to and that when first
discovered are hard to grasp.

An example:
Try explaining to someone who doesn't know what a closure is and how
he will benefit from it. Unless he has actually used one it will be
hard to grasp the construct and see why it is beneficial. After he has
used closures a couple of time he will soon realize how much easier it
is to code with them and how your code can be expressed more easily
and result in cleaner code.

Now take this up a notch by introducing Higherkinds enabling
Abstractions like Monads, Monoids, Semigroups, Applciatives, Functors
etc.. unless you have studied category theory it will be hard to grasp
these concepts and unless you actually have seen how to use them and
used them yourself you will not see the benefit they bring to the
table.But once you use them you will not live with out them and after
that the desire arises to actually understand them so you start
learning about monadic laws and suddenly Applicatives, Functors and
Monads start showing up all over the place making your code cleaner
easier to read and better to grasp for those that understands these
Abstractions. For those that don't your code looks like magic and they
say it is too complex.

But it is not the language that is complex it is the Abstractions that
are "complex" in the sense that they are not easy to grasp. I think it
would be beneficial if students would be taught these abstractions
instead of teaching them how to program Java. Hey if I learned Java by
myself so can you and if I can learn about categories and Monads,
Monoids etc so can you.

If you do not want to learn about these things then maybe you should
consider a different profession. In the End it does not matter
wheather Scala is the next C++, the next Java or will be lost in the
Ether because these Abstractions will prevail and can be applied to
any other language coming there after as long as it provides the
nessecary language constructs.

Just my 2cts.

Stefan

2011/9/9 Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" target="_blank" rel="nofollow">eric.kolotyluk@gmail.com>:
> OK, I think Kevin has a point - we can go back and forth about the semantics
> and philosophy of simple vs. complex - I think we need to find better words
> we can all agree on.
>
> Is it fair to say Scala is 'more sophisticated' (in the sense of refined as
> opposed to complicated) than Java?
>
> The reason for this particular discussion is that while there are some
> people very comfortable with Scala, there are many who are not.
>
> My personal experience with Scala is that it was harder for me learn Scala
> that it was for me to learn Java, even though Scala is not that different
> than Java. On the other hand, after gaining some competence with Scala, I
> was able to write 'cleaner code' much more readily than I was in Java. There
> are clearly trade-offs with Scala.
>
> The title of this discussion "Is Scala the Next C++" was intended to pose
> the question "in the future, can Scala get into the same sorts of difficulty
> that C++ did, and if so how can we avoid that?"
>
> It is one thing for me to learn Scala and use it for my personal needs.
> However, in the context of a person with considerable influence in my
> organization, am I ready to advocate and champion the use of Scala before my
> peers are ready for it? There are many of my peers who have turned their
> back on C++ even though they were quite competent with it at one time. Once
> they tasted Java they were extremely well motivated to avoid any further C++
> exposure. These same people have also avoided learning C# and .NET because
> they are content with Java. The number of developers in our ranks competent
> with C++ or willing to maintain the C++ code base continues to diminish.
>
> While I can see the compelling advantage of Scala, there are many who
> cannot, and will never. I still get criticism from some people because I
> integrated some Groovy into our product. We already have Pearl, Python and
> JavaScript - why do we need yet another scripting language - they ask? I
> have given several presentations on Scala to my peers - and they still ask -
> why do we need another language?
>
> My current plans are to start developing a facet of our code base with Scala
> without asking permission or approval - seeking forgiveness is always
> easier.
>
> Cheers, Eric
>
> On 2011-09-08 5:10 PM, Kevin Wright wrote:
>
> By any *objective* measurement of simplicity, Scala is definitely simpler
> than Java.
> EBNF productions in the language spec, number of defined keywords, etc.
> Then again, BrainF**k is one of the simplest languages going, based on those
> same measurements.
> So can we please stop talking about complexity and simplicity? They don't
> help a great deal, and you'd never get two people to agree 100% on the
> definition of the two terms.
>
> 2011/9/9 Cédric Beust ♔ <cedric [at] beust [dot] com" target="_blank" rel="nofollow">cedric@beust.com>
>>
>> 2011/9/8 Jörg W Mittag <2BUsenet [at] googlemail [dot] com" target="_blank" rel="nofollow">JoergWMittag+Usenet@googlemail.com>
>>>
>>> There is an important difference, though: C++ is more complex than C,
>>> but Scala is simpler than Java.
>>
>> A lot of people will probably disagree with you on this.
>> More expressive than Java, certainly. Simpler... definitely not.
>> --
>> Cédric
>
>
>

You've got a point Stefan, but then again - it resorts Scala into the academic community, making the learning curve steep for the "ordinary".

Next thing, I'd not compare Scala to Java or so, I think the best way how to teach Scala is to forget Java. Further, I'd go along with Martin Odersky's Scala Levels to teach it.
There're so many smart people in the Scala community and it needs more teachers and more focus on "new blood" - the beginners.
So far, my impression is that there's too much of focus on converts :)

jiri

On 2011-09-09 3:11 AM, Francois wrote:
> On 09/09/2011 11:35, Paul Butcher wrote:
>> [...]
>> I didn't have any direct experience of this, so everything I know is
>> anecdotal, but I do know that this approach was very unpopular with
>> the students, with half of them dropping out at or before the end of
>> the first year of the course. The following year, the university
>> reverted to a more traditional approach of introducing programming
>> with a procedural language first before moving on to talking about
>> functional languages.
>>
>> Of course, this might say more about Miranda, or how it was taught,
>> or the students who happened to be in that year, or...
>
> As said elsewhere, my school do teach OCaml as first language for
> programming introduction, algorithms and the like, and just afterward
> (so that the two courses are more or less at the same time of the
> year, in the first semester), C is introduce for system programming.
>
> What I do exeriment was that OCaml was quite like for among student
> with no prior exeriment of programming (I was such a student): it
> allows to rather directly map algorithms to code and let accidental
> complexity (for that kind of stuff) like memory management apart.
>
> On the other hand, it was hated by other. More preciselly, the more
> experienced the student was with a prior language (we had first year
> student who were C or Java killers), the more he hated OCaml.
>
> For my personnal experience: I loved OCaml, and that lead me to love
> programming, and choose the most semantic oriented cursus in my
> school, ending in a Coq project proving compiler. But I liked a lot C
> too, which was the right tool for our kernel implementation project.
> But I never succeed in understanding what C++ was aim for (unlike PHP,
> even if it was also in my "fly from it" category of language to use).
>
I created and taught SFU's first course in UI Design and Implementation.
This was a third year course; I used NeXT computers, and most of my
students had no prior experience with OO, and some of my peers had
concerns that this would be a problem. In the end, no-one in the class
had any trouble with Objective-C, and having to design and implement GUI
gave them a deep appreciation for why OO was so useful. After the course
several students approached me to say it was the best, and most fun
university course they had ever taken - and the hardest course too
because the workload was so high, but no-one struggled with the technology.

The point is, successful teaching and learning has a lot to do with
context and relevance.

In those days I was also part of the debate on whether to teach C++ or
Scheme as a first language. While I was lobbying for Java - the more
conservative professors lobbied for C++ while the more progressive ones
lobbied for Scheme. In the end I was not winning the Java argument,
because I was not a professor, so I threw in with the Scheme camp
because by then my C++ experience was that newbie programmers should not
have to face pointers (among the other horrors of C++).

Cheers, Eric

On 2011-09-09 6:36 AM, Josh Berry wrote:
> First, apologies for sending this direct... I thought I hit undo fast
> enough, evidently not. :(
>
> On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
> wrote:
>> And it is those programmers that produce lots of problems in big teams
>> but now I'm just ranting along
> I was going to chime in on this topic. I'll pick up here. I think it
> is somewhat misleading to think that everyone must learn the theory
> behind programming to learn their tools better. My analogy of choice
> is to music. There are some very talented guitarist out there that
> don't know music theory at all. They got really good with their
> instrument. Likely they discovered some of the underlying things that
> you would understand from theory, but they did not have to go the
> theory route.
>
> I liken this to patterns. Patterns are just recognizing some common
> elements seen throughout varied programs. The "theory" grounded
> topics explain why certain things work. (Similarly, the theory can
> help explain why some tempting anti-patterns do not work.)
>
> So, it is not necessary to have people become fluent in other topics
> than the language they are using. Just don't expect them to do things
> that are not "in the language" easily. Specifically, do not try and
> force abstractions on them that are not easily expressed in the
> language. (I personally think this is what makes some stuff difficult
> to understand from Scala. There is no easy equivalent in Java. There
> are often approximations, but those often cause as much harm as they
> solve.)
I like your analogy Josh. I struggled to learn to play guitar as a
child, but I am tone deaf and could not even tune my own guitar. I
cannot carry a tune to save my life. Most of my life I felt I had no
musical gifts, but before my father died he said "to be able to
appreciate music is also a gift." Now I am a DJ once a week an my fans
love my playlists.

We all have different gifts, and while some gifts are not a 'cool' as
others, we can still be productive.

Sigh - I will never get to enjoy the groupies the way the Scala
rock-stars will ;-)

Cheers, Eric

On 2011-09-09 6:56 AM, Kevin Wright wrote:

CABHxxC2nkvwvnnzC4b07y6MD6+kVm2Q0GhReqJviy5kjwpzXvw [at] mail [dot] gmail [dot] com" type="cite">

On 9 September 2011 14:36, Josh Berry <taeric [at] gmail [dot] com" rel="nofollow">taeric@gmail.com> wrote:

First, apologies for sending this direct...  I thought I hit undo fast
enough, evidently not. :(

On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
<mailtolanger [at] googlemail [dot] com" rel="nofollow">mailtolanger@googlemail.com> wrote:
> And it is those programmers that produce lots of problems in big teams
> but now I'm just ranting along

I was going to chime in on this topic.  I'll pick up here.  I think it
is somewhat misleading to think that everyone must learn the theory
behind programming to learn their tools better.  My analogy of choice
is to music.  There are some very talented guitarist out there that
don't know music theory at all.  They got really good with their
instrument.  Likely they discovered some of the underlying things that
you would understand from theory, but they did not have to go the
theory route.

I liken this to patterns.  Patterns are just recognizing some common
elements seen throughout varied programs.  The "theory" grounded
topics explain why certain things work.  (Similarly, the theory can
help explain why some tempting anti-patterns do not work.)

So, it is not necessary to have people become fluent in other topics
than the language they are using.  Just don't expect them to do things
that are not "in the language" easily.   Specifically, do not try and
force abstractions on them that are not easily expressed in the
language.  (I personally think this is what makes some stuff difficult
to understand from Scala.  There is no easy equivalent in Java.  There
are often approximations, but those often cause as much harm as they
solve.)

Music is a much better analogy than you might have first thought.  Imagine only learning music in C-major on a non-polyphonic electric keyboard, with all the black keys removed for the sake of simplicity, and because they're not all that necessary in C-major.
Sure, you can play other scales by transposing. The only difference between C-major and A-minor is what note you start on (useful tidbit there for anyone who wondered why we start at C - We don't! minor scales were more common when the system came about).  But that assumes you know the existence of other scales in the first place, and transposing requires more technical ability than just playing directly in C-minor to start with.
Even then, it doesn't sound quite right.  Pianos and keyboards are a so-called "tempered" instrument, which means that transposing won't shift the frequency of the scale evenly.  Composers use this property of different keys to subtly shift the feel of a piece, above and beyond the more obvious major/minor distinction.
I won't even get into the subject of modes :)
For polyphonic music, it gets even harder.  You *need* those black keys when playing chord sequences.
Key: black keys = FP constructs polyphony = concurrency "My First Keyboard"(tm) = java
note: A good musician will tell you that c-sharp (for example) is ever so slightly lower in pitch than d-flat.  Violinists know this, as do really good woodwind players.  Tempering is when you force them to be the same.
--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com" target="_blank" rel="nofollow">kevin.wright@scalatechnology.com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com" target="_blank" rel="nofollow">kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda
twitter: @thecoda
vibe / skype: kev.lee.wright steam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

<envy>
    Dam - Kevin is going to get both the music groupies and the Scala groupies too!
</envy>

Not even mentioning the circle of 4ths and 5ths :)

jiri

On Fri, Sep 9, 2011 at 3:56 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 9 September 2011 14:36, Josh Berry <taeric@gmail.com> wrote:

First, apologies for sending this direct...  I thought I hit undo fast
enough, evidently not. :(

On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
<mailtolanger@googlemail.com> wrote:
> And it is those programmers that produce lots of problems in big teams
> but now I'm just ranting along

I was going to chime in on this topic.  I'll pick up here.  I think it
is somewhat misleading to think that everyone must learn the theory
behind programming to learn their tools better.  My analogy of choice
is to music.  There are some very talented guitarist out there that
don't know music theory at all.  They got really good with their
instrument.  Likely they discovered some of the underlying things that
you would understand from theory, but they did not have to go the
theory route.

I liken this to patterns.  Patterns are just recognizing some common
elements seen throughout varied programs.  The "theory" grounded
topics explain why certain things work.  (Similarly, the theory can
help explain why some tempting anti-patterns do not work.)

So, it is not necessary to have people become fluent in other topics
than the language they are using.  Just don't expect them to do things
that are not "in the language" easily.   Specifically, do not try and
force abstractions on them that are not easily expressed in the
language.  (I personally think this is what makes some stuff difficult
to understand from Scala.  There is no easy equivalent in Java.  There
are often approximations, but those often cause as much harm as they
solve.)

Music is a much better analogy than you might have first thought.  Imagine only learning music in C-major on a non-polyphonic electric keyboard, with all the black keys removed for the sake of simplicity, and because they're not all that necessary in C-major.
Sure, you can play other scales by transposing. The only difference between C-major and A-minor is what note you start on (useful tidbit there for anyone who wondered why we start at C - We don't! minor scales were more common when the system came about).  But that assumes you know the existence of other scales in the first place, and transposing requires more technical ability than just playing directly in C-minor to start with.
Even then, it doesn't sound quite right.  Pianos and keyboards are a so-called "tempered" instrument, which means that transposing won't shift the frequency of the scale evenly.  Composers use this property of different keys to subtly shift the feel of a piece, above and beyond the more obvious major/minor distinction.
I won't even get into the subject of modes :)
For polyphonic music, it gets even harder.  You *need* those black keys when playing chord sequences.
Key:black keys = FP constructspolyphony = concurrency"My First Keyboard"(tm) = java
note: A good musician will tell you that c-sharp (for example) is ever so slightly lower in pitch than d-flat.  Violinists know this, as do really good woodwind players.  Tempering is when you force them to be the same.
--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

--
web: http://www.dredwerkz.czblog: http://dr3dwerkz.blogspot.com/
code: https://github.com/g0dd4rd
group: http://groups.google.com/group/dr3dwerkz
music: http://profile.ultimate-guitar.com/g0dd4rd/
twitter: http://twitter.com/#!/g0dd4rd
profile: http://www.google.com/profiles/g0dd4rd
icq: 218 659 431

On Fri, Sep 9, 2011 at 1:48 AM, Francois <fanf42@gmail.com> wrote:

If you do not want to learn about these things then maybe you should
consider a different profession. In the End it does not matter
wheather Scala is the next C++, the next Java or will be lost in the
Ether because these Abstractions will prevail and can be applied to
any other language coming there after as long as it provides the
nessecary language constructs.

Wow, I'm really impressed: you succeeded to make a really well argued, clear and interesting answer to a quite trolling subject. Thanks for that!

Agreed, except for the "If you do not want to learn about these things then maybe you should consider a different profession" part, which I find very condescending.
I know a lot of terrific developers who have no idea what these concepts are and yet, who continually deliver top notch code, are creative, know how to work under pressure while remaining great innovators, are great at explaining their code or communicating with their team, etc... They are smart and they would have no problem learning these abstract concepts if they wanted to, they just either don't feel the need to, have never been exposed to them or just choose to focus their learning on different aspects of the profession.
A lot of the code you use on daily basis on your computer is created by these types of developers. Keep this in mind.
--  Cédric

On Fri, Sep 9, 2011 at 7:06 AM, Josh Berry <taeric@gmail.com> wrote:

On Fri, Sep 9, 2011 at 9:56 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
> Music is a much better analogy than you might have first thought.  Imagine
> only learning music in C-major on a non-polyphonic electric keyboard, with
> all the black keys removed for the sake of simplicity, and because they're
> not all that necessary in C-major.


You are still hitting the theory, though.  Go more basic.  Imagine
learning to play on a Ukulele without any training in music theory at
all.  It can probably be done.  I bet there are some folks that make
really good music that way.

Absolutely. I think a more accurate analogy would be learning the guitar with tabs only and no music sheet, ever. You can go very far this way. You have access to the entire spectrum of possibilities and you will most likely reinvent existing concepts along the way. I wouldn't consider such a guitar player any less of a musician than someone who knows music theory inside and out. At the end of the day, you are both producing music and you could probably learn from each other.
-- Cédric

2011/9/9 Cédric Beust ♔ <cedric@beust.com>

Agreed, except for the "If you do not want to learn about these things then maybe you should consider a different profession" part, which I find very condescending.

On the one hand, it is.  And on the other hand, I think it's true, at least in the long run.
The thing is, these abstraction shifts have an inexorable pull to them.  They take a lot of time -- typically a decade or two -- but wind up taking over the industry.  They become more and more necessary to understand, and if you've resisted doing so, you gradually find yourself unemployable.
This isn't airy theory -- I've watched it happen to friends.  The people who didn't get into object-oriented programming have found their opportunities shrink steadily over the years, and the ones who took too long to pick up the paradigm shift often found it to be too late by the time they woke to the need: even once they accepted that they needed to do OO, they couldn't wrap their heads around it.  These were, by and large, good programmers in the older paradigm, but they had allowed their ability to learn to atrophy, and they went from being good procedural programmers to pretty bad OO ones.
My feeling is that the same is true of functional programming today.  You can make do just fine without learning the newer paradigms; if all you know if traditional OO, you'll still be employable and able to do good work for another ten years or more.  But eventually, the new abstractions *are* going to take over, slow bit by bit.  And those who refuse to learn them today are likely to find themselves penned in by that decision over the years.
(Note that I am *not* a serious functional guru myself yet.  But I can tell which way the wind is blowing.  This conversation is by no means confined to Scala -- it's happening all over the industry, both in established languages and new ones.  Heck, I was reading a fine article yesterday, explaining how C#'s LINQ system is, basically, trying to be an implementation of monads...)

In general I agree with Justin. 
I would also add that the functional paradigm is taking over the field from another direction as well. A lot of younger programers started their serious volume development in "scripting" languages such as Python, Ruby, and JavaScript, all of which contain a fair amount of functional features.
These younger folks developed strong distaste for C/C++/Java still taught in CS curriculum in most colleges. The "scripting" languages and tools associated with them are drastically more productive for relatively small projects they did so far. They just don't see a point in using the "dinosaur" languages, other than perhaps for improving performance in limited number of critical parts of a system.
As this generation moves on to bigger responsibilities and larger-scale projects, they will run into limitations of "scripting" languages, and more and more of them will discover the value of statically compiled functional languages. It is not a coincidence that bold decisions to use Scala at scale in companies like Twitter, LinkedIn, and FourSquare were made by the representatives of this newer generation.

2011/9/9 Justin du coeur <jducoeur@gmail.com>

2011/9/9 Cédric Beust ♔ <cedric@beust.com>

Agreed, except for the "If you do not want to learn about these things then maybe you should consider a different profession" part, which I find very condescending.

On the one hand, it is.  And on the other hand, I think it's true, at least in the long run.
The thing is, these abstraction shifts have an inexorable pull to them.  They take a lot of time -- typically a decade or two -- but wind up taking over the industry.  They become more and more necessary to understand, and if you've resisted doing so, you gradually find yourself unemployable.
This isn't airy theory -- I've watched it happen to friends.  The people who didn't get into object-oriented programming have found their opportunities shrink steadily over the years, and the ones who took too long to pick up the paradigm shift often found it to be too late by the time they woke to the need: even once they accepted that they needed to do OO, they couldn't wrap their heads around it.  These were, by and large, good programmers in the older paradigm, but they had allowed their ability to learn to atrophy, and they went from being good procedural programmers to pretty bad OO ones.
My feeling is that the same is true of functional programming today.  You can make do just fine without learning the newer paradigms; if all you know if traditional OO, you'll still be employable and able to do good work for another ten years or more.  But eventually, the new abstractions *are* going to take over, slow bit by bit.  And those who refuse to learn them today are likely to find themselves penned in by that decision over the years.
(Note that I am *not* a serious functional guru myself yet.  But I can tell which way the wind is blowing.  This conversation is by no means confined to Scala -- it's happening all over the industry, both in established languages and new ones.  Heck, I was reading a fine article yesterday, explaining how C#'s LINQ system is, basically, trying to be an implementation of monads...)

On Sep 9, 2011 5:29 PM, "Justin du coeur" <jducoeur@gmail.com> wrote:
>
> 2011/9/9 Cédric Beust ♔ <cedric@beust.com>
>>
>> Agreed, except for the "If you do not want to learn about these things then maybe you should
>> consider a different profession" part, which I find very condescending.
>
>
> On the one hand, it is.  And on the other hand, I think it's true, at least in the long run.
>
> The thing is, these abstraction shifts have an inexorable pull to them.  They take a lot of time -- typically a decade or two -- but wind up taking over the industry.  They become more and more necessary to understand, and if you've resisted doing so, you gradually find yourself unemployable.
>
> This isn't airy theory -- I've watched it happen to friends.  The people who didn't get into object-oriented programming have found their opportunities shrink steadily over the years, and the ones who took too long to pick up the paradigm shift often found it to be too late by the time they woke to the need: even once they accepted that they needed to do OO, they couldn't wrap their heads around it.  These were, by and large, good programmers in the older paradigm, but they had allowed their ability to learn to atrophy, and they went from being good procedural programmers to pretty bad OO ones.
>
> My feeling is that the same is true of functional programming today.  You can make do just fine without learning the newer paradigms; if all you know if traditional OO, you'll still be employable and able to do good work for another ten years or more.  But eventually, the new abstractions *are* going to take over, slow bit by bit.  And those who refuse to learn them today are likely to find themselves penned in by that decision over the years.
>

The principle is sound, but the history isn't. FP predates OO by a fair margin. When you consider that e.g. Lisp is based on Church's lambda calculus, it arguably predates both programming and computers as we now understand the terms.

As paradigms go, it would be harder to find something that's *less* new :)

> (Note that I am *not* a serious functional guru myself yet.  But I can tell which way the wind is blowing.  This conversation is by no means confined to Scala -- it's happening all over the industry, both in established languages and new ones.  Heck, I was reading a fine article yesterday, explaining how C#'s LINQ system is, basically, trying to be an implementation of monads...)

That's because it is!

On Sep 9, 2011 5:23 PM, "Cédric Beust ♔" <cedric@beust.com> wrote:
>
> On Fri, Sep 9, 2011 at 7:06 AM, Josh Berry <taeric@gmail.com> wrote:
>>
>> On Fri, Sep 9, 2011 at 9:56 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
>> > Music is a much better analogy than you might have first thought.  Imagine
>> > only learning music in C-major on a non-polyphonic electric keyboard, with
>> > all the black keys removed for the sake of simplicity, and because they're
>> > not all that necessary in C-major.
>>
>>
>> You are still hitting the theory, though.  Go more basic.  Imagine
>> learning to play on a Ukulele without any training in music theory at
>> all.  It can probably be done.  I bet there are some folks that make
>> really good music that way.
>
>
> Absolutely. I think a more accurate analogy would be learning the guitar with tabs only and no music sheet, ever. You can go very far this way. You have access to the entire spectrum of possibilities and you will most likely reinvent existing concepts along the way. I wouldn't consider such a guitar player any less of a musician than someone who knows music theory inside and out. At the end of the day, you are both producing music and you could probably learn from each other.
>
> -- 
> Cédric
>

Exactly, though it cuts both ways. Programming is as much about composition as it is about performance.

The tab-trained player would struggle to write for any other instrument. Their notation is limited and not suited to e.g. pedal indications for a piano. They may even be unaware of the concept through lack of exposure, and would be unable to take the vast majority of music ever written to adapt it for the ukelele.

Whilst our hypothetical player may well be a virtuoso on their chosen instrument, it's even possible that their entire mental model of music would be shaped, and restricted, by that notation.

However you cut it... the very same person, if schooled in "standard" notation, would find themselves a better musician. With more options available, and a greater body of collective knowledge to draw upon.

2011/9/9 Kevin Wright <kev.lee.wright@gmail.com>

However you cut it... the very same person, if schooled in "standard" notation, would find themselves a better musician.

Agree with you up until this point.
I don't want to stretch this metaphor too far because it's bound to leak, but so far, it's holding well with our Scala/Java discussion so I'll keep with it.
I am a beginner guitar player with six years of classical piano (and heavy theory) behind it. I can't imagine a world in which this would make me a better musician than a guitar player who's been practicing a few hours every day for a few months and who knows nothing about music notation. This person will run rings around me playing any kind of music (as long as it's using tabs, of course. Which he will probably not even need since his fingers probably know most of the pieces by heart).
I'm just trying to warn against using this classification to say who is a better musician (or developer) than another. It just doesn't work that way. See my earlier note about awesome developers who have very little knowledge of FP and category theory.
-- Cédric

On Fri, Sep 9, 2011 at 1:23 PM, Cédric Beust ♔ wrote:
> I am a beginner guitar player with six years of classical piano (and heavy
> theory) behind it. I can't imagine a world in which this would make me a
> better musician than a guitar player who's been practicing a few hours every
> day for a few months and who knows nothing about music notation. This person
> will run rings around me playing any kind of music (as long as it's using
> tabs, of course. Which he will probably not even need since his fingers
> probably know most of the pieces by heart).

This is why I stated what I did about these players likely learning
some theory without naming it. They would likely even call the chord
progression they chose in a little improvisation as something they did
because it was patterned after something else they had seen that
worked. Now, the theory could tell them why and which other patterns
might also work. Any why.

So, the question comes in, which gives more bang for buck? A new
tool, or a deeper understanding of the craft? Switching to Scala is
using a more capable tool than using Java. Just as switching to an
IDE gives you a more capable tool than using notepad. Does switching
editing tools help more than switching language targets? Do either
hit as hard as learning the craft?

The cut I made the other day was simply that learning whatever domain
you are working with may be the best bet most folks need to do. That
is, "learning to general program in Scala" likely won't help most
people writing webapps as much as simply learning the plumbing used by
the overall framework they are targeting.

On Sep 9, 2011 6:24 PM, "Cédric Beust ♔" <cedric@beust.com> wrote:
>
> 2011/9/9 Kevin Wright <kev.lee.wright@gmail.com>
>>
>> However you cut it... the very same person, if schooled in "standard" notation, would find themselves a better musician.
>
>
> Agree with you up until this point.
>
> I don't want to stretch this metaphor too far because it's bound to leak, but so far, it's holding well with our Scala/Java discussion so I'll keep with it.
>
> I am a beginner guitar player with six years of classical piano (and heavy theory) behind it. I can't imagine a world in which this would make me a better musician than a guitar player who's been practicing a few hours every day for a few months and who knows nothing about music notation. This person will run rings around me playing any kind of music (as long as it's using tabs, of course. Which he will probably not even need since his fingers probably know most of the pieces by heart).
>
> I'm just trying to warn against using this classification to say who is a better musician (or developer) than another. It just doesn't work that way. See my earlier note about awesome developers who have very little knowledge of FP and category theory.
>
> -- 
> Cédric
>

Oh, totally.  But, *all other things being equal*, the guy with the better theory, and experience with the more general-purpose notation, will be at an advantage. The analogy could be extended here to cover a developer who knows a wider range of abstractions and paradigms with which to construct software.

Of course... If you shirk practice, however well-reasoned your justification, then you'll suck. No matter how well you know the theory.  This goes for music and programming alike.

The point of an opportunity-cost in spending time on pure theory is a valid one :)

On Fri, Sep 9, 2011 at 1:01 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The principle is sound, but the history isn't. FP predates OO by a fair margin. When you consider that e.g. Lisp is based on Church's lambda calculus, it arguably predates both programming and computers as we now understand the terms.

As paradigms go, it would be harder to find something that's *less* new :)

True, and I'm well aware of that.  (Lisp was actually one of my first languages, back in the 70s.)  But I'm talking about "steam engine time".  FP has been regarded as a niche curiosity by most of the industry for decades; it is only now (past five years) that I'm detecting across-the-board movement for it to move into the mainstream.
This is similar to (although with a longer timescale) the way that OO existed for a goodly number of years before C++ and Java made it mainstream.  People called OO "new" without irony then, for much the same reason -- new to the mainstream, even though language devotees had known about it for a long time due to, eg, Smalltalk, Ada, etc.
So forgive the loose language, but I think you get what I mean here...

On 09/09/2011 15:16, Stefan Langer wrote:
> And it is those programmers that produce lots of problems in big teams
> but now I'm just ranting along

Sure, but there are disciplined programmers making good, big projects in
large teams in PHP...
And there are good programmers making wonders (eg. games) in C or
JavaScript, sometime alone.

Just opposing to abusive generalization, "lot of" isn't "all of". :-)

On Fri, Sep 9, 2011 at 10:01 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

The principle is sound, but the history isn't. FP predates OO by a fair margin. When you consider that e.g. Lisp is based on Church's lambda calculus, it arguably predates both programming and computers as we now understand the terms.

As paradigms go, it would be harder to find something that's *less* new :)

You got me thinking ... And realize that procedural programming - the notion of algorithm - was invented in B.C. times. There was even a corresponding computer - abacus.
The first recorded notion of entities with inheritable attributes in hierarchies, if memory serves me, dates back to Renaissance era. The corresponding "computer" was arguably a ledger/spreadsheet that saw a huge uptake around that time.
The lambda calculus and formalisms isomorphic to it came later as we know.

I think you misunderstood what I tried to say with
> "If you do not want to learn about these things then maybe you should consider a different profession"
You actually grasped what I tried to say with your following sentence:
> ... They are smart and they would have no problem learning these abstract concepts if
> they wanted to, they just either don't feel the need to, have never been
> exposed to them or just choose to focus their learning on different aspects
> of the profession.
They are probably already applying these Abstractions without knowing
what they are because Programming is all about finding a good
abstraction to make code more general and easier to handle. So they
are already on a search for these Abstraction and sooner or later they
will stumble upon them or at least they will strife to grasp them.

These concepts are not something that is specific to Scala or Haskell
these things represent universal laws. And if you are a programmer
that is on a search to find the better abstraction you will sooner or
later stumble on these abstractions and use them.

I see programming very much as a craftmansship like doing music but if
you want to become a true master you must always expand your horizon
and my sentence form the beginning was suppose to mean if you do not
strife to become better by learning new concepts then you may not be
fit for being a developer. Because you will have to adapt to a very
fast changing market and languages are just a minor part in that but
the concepts/abstractions represented by these languages prevail so if
you learn them you will have a toolset for the future.
I believe this holds true for many professions and if you are not
willing to strife for being better then you might think about doing
something else because I will assure you you will feel miserable
sooner or later.
-
Stefan

2011/9/7 Kevin Wright <kev.lee.wright@gmail.com>

It's an old, old debate, don't worry about it, just use the most powerful language you can[2] that fits your requirements, and be happy.

I would say the opposite. Use the least powerful language you can that fits your requirements, and be happy.

Why struggle with a turing machine when a finite-state machine will do?

BR,
John

On 9 September 2011 22:41, John Nilsson <john@milsson.nu> wrote:

2011/9/7 Kevin Wright <kev.lee.wright@gmail.com>

It's an old, old debate, don't worry about it, just use the most powerful language you can[2] that fits your requirements, and be happy.

I would say the opposite. Use the least powerful language you can that fits your requirements, and be happy.

Why struggle with a turing machine when a finite-state machine will do?

BR,
John

Why struggle with raw machine code, when Scala can do the job?

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.comquora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda
kev.lee.wright@gmail.comtwitter: @thecoda
vibe / skype: kev.lee.wright steam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Stefan, there are a lot of 9-5 dudes and dudettes out there who couldn't care less about the new thing... Which we know would make them work even less, but seems harder to pickup.

The evolution is a story told on terms of cost (initial and ongoing) and rewards. Species whose individuals got those wrong became extinct. That is no longer quite true with humans. Not everyone has to evolve now. As a programmer, employment is pretty much guaranteed these days, at some level, somewhere...

The ways I am trying to settle this in my mind is like an amplifier, whose quality was given by the ratio of amplification (useful) and noise (bad). I think the same is true with languages: they have a useful load of paradigms and syntactic noise. I Ned the help of a good "language lawyer" for quantization but I think that's the way to settle this and quantify each language in a directly comparable way?

Thanks
Razvan

On 2011-09-09, at 5:09 PM, Stefan Langer wrote:

> I think you misunderstood what I tried to say with
>> "If you do not want to learn about these things then maybe you should consider a different profession"
> You actually grasped what I tried to say with your following sentence:
>> ... They are smart and they would have no problem learning these abstract concepts if
>> they wanted to, they just either don't feel the need to, have never been
>> exposed to them or just choose to focus their learning on different aspects
>> of the profession.
> They are probably already applying these Abstractions without knowing
> what they are because Programming is all about finding a good
> abstraction to make code more general and easier to handle. So they
> are already on a search for these Abstraction and sooner or later they
> will stumble upon them or at least they will strife to grasp them.
>
> These concepts are not something that is specific to Scala or Haskell
> these things represent universal laws. And if you are a programmer
> that is on a search to find the better abstraction you will sooner or
> later stumble on these abstractions and use them.
>
> I see programming very much as a craftmansship like doing music but if
> you want to become a true master you must always expand your horizon
> and my sentence form the beginning was suppose to mean if you do not
> strife to become better by learning new concepts then you may not be
> fit for being a developer. Because you will have to adapt to a very
> fast changing market and languages are just a minor part in that but
> the concepts/abstractions represented by these languages prevail so if
> you learn them you will have a toolset for the future.
> I believe this holds true for many professions and if you are not
> willing to strife for being better then you might think about doing
> something else because I will assure you you will feel miserable
> sooner or later.
> -
> Stefan

On Fri, Sep 9, 2011 at 5:09 PM, Stefan Langer
wrote:
> These concepts are not something that is specific to Scala or Haskell
> these things represent universal laws. And if you are a programmer
> that is on a search to find the better abstraction you will sooner or
> later stumble on these abstractions and use them.

That said, I do have to say that I find some are hard to really grasp
at an, "I will do it this way" level. For instance, it is not
uncommon to write code that is:

Foo value;
for (Bar b : bars) {
value = someFunctionOn(value, b);
}

Trying to convince someone that this is a fold is less than easy.
That is, convincing someone to use a fold instead of this. Showing
them they are the same is easy enough. But, my brain still tries to
jump straight to the for loop more than I'd care for. To the point
that I have to confess that the cost to get someone to change their
style dramatically to start using folds and maps might not be
something that is easily paid. Especially not when they are layering
on top of their programming skills a lack of true domain
understanding.

Most of this is the struggle to leave the imperative world, I think.
Moving from "how will I do something" to "what do I want to do" is a
larger shift than it sounds.

On 10/09/11 10:32, Josh Berry wrote:
> On Fri, Sep 9, 2011 at 5:09 PM, Stefan Langer
> wrote:
>> These concepts are not something that is specific to Scala or Haskell
>> these things represent universal laws. And if you are a programmer
>> that is on a search to find the better abstraction you will sooner or
>> later stumble on these abstractions and use them.
> That said, I do have to say that I find some are hard to really grasp
> at an, "I will do it this way" level. For instance, it is not
> uncommon to write code that is:
>
> Foo value;
> for (Bar b : bars) {
> value = someFunctionOn(value, b);
> }
>
> Trying to convince someone that this is a fold is less than easy.
> That is, convincing someone to use a fold instead of this. Showing
> them they are the same is easy enough. But, my brain still tries to
> jump straight to the for loop more than I'd care for. To the point
> that I have to confess that the cost to get someone to change their
> style dramatically to start using folds and maps might not be
> something that is easily paid. Especially not when they are layering
> on top of their programming skills a lack of true domain
> understanding.
>
> Most of this is the struggle to leave the imperative world, I think.
> Moving from "how will I do something" to "what do I want to do" is a
> larger shift than it sounds.
Actually, I have a recipe that forces almost anyone to recognise it as a
left fold :)

Do this. Have them solve an apparent new problem that results in a
similar loop. Repeat this 3 or 4 times. Now point to the duplication.
Tell them it gives you extreme anxiety. There is a logical disconnection
here and your task is to unify it. The disconnection is this:
* Many people are sympathetic to the idea of removing duplicate code
* Those same people find the idea of "left-fold" obtuse or foreign

As you and I know, "left-fold" is simply the name given to the result of
having removed duplication. So, you can attract sympathy by stating your
allegiance to removing code duplication. They will share your "anxiety
disorder" so to speak on this front. When they are done, just say
"congratulations" and the next time "left-fold" comes up, you treat them
as if they know exactly what you are talking about (since they do,
whether this is known or not). If they act as if they do not know, point
it out to them what you did previously. Now that they have "accidentally
discovered" that they are "on the same level" as you with respect to
"left-fold", this will overcome the inferiority dilemma that often
arises (I can it The Princess Effect).

This works almost always.

On Fri, Sep 9, 2011 at 11:59 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 9 September 2011 22:41, John Nilsson <john@milsson.nu> wrote:

Why struggle with a turing machine when a finite-state machine will do?

Why struggle with raw machine code, when Scala can do the job?

 
What I meant is that it is not uncommon for me to discover heaps of very hard to analyse programs that could very succinctly, and more importantly, easier to reason about be expressed as regular expressions or simple SQL-queries.

Of course Scala makes it easy to construct DSLs that resembles such powerless laguages but you are still left with a turing complete illusion.

Take pureness as an example. It is often stated that an effect system is required to fully track pure code. But that is kind of the wrong way to look at it no? Given a subset of the language that didn't have impure features there would be no need to "track" it.

BR,
John

On Fri, Sep 9, 2011 at 5:43 PM, Tony Morris <tonymorris@gmail.com> wrote:

Do this. Have them solve an apparent new problem that results in a
similar loop. Repeat this 3 or 4 times. Now point to the duplication.

I don't think that's the right angle for teaching, because fold does hardly anything more than a for loop to avoid duplication. It's reasonable to argue that the following expressions:
for (Foo b : foos) {
 value = someFooFunctionOn(value, b);
}
for (Bar b : bars) {
 value = someOtherFunctionOn(value, b);
}
and
value.foldLeft(value)(someFooFunction) value.foldLeft(value)(someOtherFunction)
are both as DRY as they can be.
In other words, when you turn a for expression into a fold, you have done close to nothing to avoid duplication of code.
fold's strengths compared to a for loop are conciseness and composability, which is what I emphasize, especially the latter, since conciseness is not always a desirable quality.  

this will overcome the inferiority dilemma that often
arises (I can it The Princess Effect).

Actually, I believe Runar coined the term.
-- Cédric

On Sep 10, 2011 3:58 AM, "Cédric Beust ♔" <cedric@beust.com> wrote:
>
> On Fri, Sep 9, 2011 at 5:43 PM, Tony Morris <tonymorris@gmail.com> wrote:
>>
>>
>>
>> Do this. Have them solve an apparent new problem that results in a
>> similar loop. Repeat this 3 or 4 times. Now point to the duplication.
>
>
> I don't think that's the right angle for teaching, because fold does hardly anything more than a for loop to avoid duplication. It's reasonable to argue that the following expressions:
>
> for (Foo b : foos) {
>  value = someFooFunctionOn(value, b);
> }
>
> for (Bar b : bars) {
>  value = someOtherFunctionOn(value, b);
> }
>
> and
>
> value.foldLeft(value)(someFooFunction)
> value.foldLeft(value)(someOtherFunction)

(you folded value instead og bars/foos)

I guess you mean:

(value /: foos)(someFooFunction)
(value /: bars)(someBarFunction)

>
> are both as DRY as they can be.
>
> In other words, when you turn a for expression into a fold, you have done close to nothing to avoid duplication of code.
>
> fold's strengths compared to a for loop are conciseness and composability, which is what I emphasize, especially the latter, since conciseness is not always a desirable quality.
>  
>>
>> this will overcome the inferiority dilemma that often
>> arises (I can it The Princess Effect).
>
>
> Actually, I believe Runar coined the term.
>
> -- 
> Cédric
>

On Fri, Sep 9, 2011 at 8:43 PM, Tony Morris wrote:
> On 10/09/11 10:32, Josh Berry wrote:
> Actually, I have a recipe that forces almost anyone to recognise it as a
> left fold :)

My problem isn't so much recognizing it as a fold. The problem is
that the first thought, especially in Java, is always to do it with a
for loop. The imperative process is more the thinking that is akin
to, "I have a Value a, and I have a list of OtherValues b, now I want
to loop over those OtherValues and process them with my Value a to
make a new Value a."

Turning that line of thinking into "I want to fold over a list of
OtherValues b with a seed Value a" seems difficult. Especially if it
is something done after the fact. (That is, if you already have the
for loop written out, why change it? A question I am sympathetic to,
as often times there is not a compelling reason to change it.) (And
again, in Java you wind up with either an anonymous inner class and
all the ceremony it entails or a named class with even more ceremony.)

On Friday 09 September 2011, Josh Berry wrote:
> First, apologies for sending this direct... I thought I hit undo
> fast enough, evidently not. :(
>
> On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
>
> wrote:
> > And it is those programmers that produce lots of problems in big
> > teams but now I'm just ranting along
>
> I was going to chime in on this topic. I'll pick up here. I think
> it is somewhat misleading to think that everyone must learn the
> theory behind programming to learn their tools better. My analogy of
> choice is to music. There are some very talented guitarist out there
> that don't know music theory at all. They got really good with their
> instrument. Likely they discovered some of the underlying things
> that you would understand from theory, but they did not have to go
> the theory route.

This is so wrong. A guitarist who makes bad music won't make buildings
fall down or cause people's medical records to be exposed to the
public. A surgeon who does not understand human anatomy will kill
people. A painter who does not understand perspective ... well, he
might become the next Picasso.

Technology cannot be equated to the arts. We build societies upon
technological foundations and if they are unsound, those societies are
at risk. If someone's guitar tunes are unmelodic...

So what? Technology and science do actually have right and wrong.
Literature, music, art, dance, etc., they do not. The arts are
subjective. Technology is not!!

This is what really bothers me. Programmers want to see themselves as
artists. THEY ARE NOT! Not if they're writing programs for general
consumption.

> ....

I don't care what amateurs do or do not understand about programming.
But I expect professionals understand the foundations of computing.

If you don't want to understand the foundations of computing, no
problem. You're just not qualified to be a professional programmer or
software engineer.

Randall Schulz

On Sat, Sep 10, 2011 at 8:15 PM, Randall R Schulz wrote:
> This is so wrong. A guitarist who makes bad music won't make buildings
> fall down or cause people's medical records to be exposed to the
> public. A surgeon who does not understand human anatomy will kill
> people. A painter who does not understand perspective ... well, he
> might become the next Picasso.

Yet a surgeon who doesn't understand everything about the tool being
used to perform operations on someone is likely to be doing just fine.
An understanding of the body being surgically altered is far more
important than knowledge of a new knife that can accomplish something
with greater ease. (Not that we shouldn't look for better
knives/tools. We should, but the existence of a better tool does not
mean existing ones should be immediately discarded. Only bad ones.)

That is to say, a programmer programming the latest rocket going into
space better understand rockets and the related subjects better than
the programmer making your every day web app. Similarly, I fully
expect those working on high frequency trading have a stronger grasp
on trading concepts than most of the people working on the latest
programming ideas here. So, I think programmers doing basic webapps
for internal projects are probably best served learning about the web
as a platform and then the specifics of the application they are
making. More expressive languages are nice, and I push for them
myself, but they do not help people that are struggling with non
programming related issues.

Not to mention I think you are taking my analogy in directions I did
not mean for it to be taken. I'm specifically likening practitioners
of one craft with their tools to other practitioners and their tools.
As much as it pains some folks to admit it around here, there are some
highly skilled imperative programmers out there. I have to admit that
I firmly believe the question of "should some programmers shift to new
ways of programming?" is likely a no. With zero value judgement
against these individuals. They are successfully accomplishing what
they need to accomplish with the tools they have.

> This is what really bothers me. Programmers want to see themselves as
> artists. THEY ARE NOT! Not if they're writing programs for general
> consumption.

I am not likening programmers to artists. I am likening programming
languages and IDEs to tools. I personally like learning to use my
tools as well as I can. However, I am of the mindset now that if I
wanted to learn to program games, I would be better served studying
games, and not general programming. For webapps, similar ideas apply.

> If you don't want to understand the foundations of computing, no
> problem. You're just not qualified to be a professional programmer or
> software engineer.

As was said earlier, the vast majority of the software you interact
with at all is programmed by people that do not understand fully the
topics that are put forth here on a regular basis. To the point that
it is frighteningly laughable that it can be put forth some of these
things as required fundamentals. They are useful abstractions for
some to get a job done. I am personally a fan of them, but if they
were required foundations of anything, then they would by definition
be used in more places.

On 2011-09-10 5:15 PM, Randall R Schulz wrote:
> On Friday 09 September 2011, Josh Berry wrote:
>> First, apologies for sending this direct... I thought I hit undo
>> fast enough, evidently not. :(
>>
>> On Fri, Sep 9, 2011 at 9:16 AM, Stefan Langer
>>
>> wrote:
>>> And it is those programmers that produce lots of problems in big
>>> teams but now I'm just ranting along
>> I was going to chime in on this topic. I'll pick up here. I think
>> it is somewhat misleading to think that everyone must learn the
>> theory behind programming to learn their tools better. My analogy of
>> choice is to music. There are some very talented guitarist out there
>> that don't know music theory at all. They got really good with their
>> instrument. Likely they discovered some of the underlying things
>> that you would understand from theory, but they did not have to go
>> the theory route.
> This is so wrong. A guitarist who makes bad music won't make buildings
> fall down or cause people's medical records to be exposed to the
> public. A surgeon who does not understand human anatomy will kill
> people. A painter who does not understand perspective ... well, he
> might become the next Picasso.
>
> Technology cannot be equated to the arts. We build societies upon
> technological foundations and if they are unsound, those societies are
> at risk. If someone's guitar tunes are unmelodic...
>
> So what? Technology and science do actually have right and wrong.
> Literature, music, art, dance, etc., they do not. The arts are
> subjective. Technology is not!!
>
> This is what really bothers me. Programmers want to see themselves as
> artists. THEY ARE NOT! Not if they're writing programs for general
> consumption.
>
I disagree - the music metaphor is still sound. I like it - it is brilliant!

A programmer who codes a game is not likely to kill any people, while a
programmer who programs a nuclear reactor might. The quality of the
solution depends on the criticality of the problem - not the profession
of the person solving the problem.

You are confusing different dimensions of understanding and purpose. To
say the arts are subjective and technology is not, well, is really
shallow - there are aspects of the arts that are objective as well as
subjective, as there are aspects of technology that are subjective as
well as objective.

The problem is there are too few programmers who are able to be artists
- that is why there is so much boring code everywhere. A real software
artist knows how to write textbook code that is as clear as possible to
as many people as possible - and leaves you with an emotional feeling of
"that is so cool!" Software 'hackers' on the other hand care for nothing
more than solving the problem; the solution may be technically correct,
but hard for another person to figure out, or even for themselves to
figure out months later. A lack of art results in many more "wtf?" moments.

From my perspective there is just about as much art in Scala as there
is science, and we should not focus merely on the science. The reason I
like Scala is because of large number of "that is so cool" moments I
experience. Art and science are not separate - they are intertwined.

>> ....
> I don't care what amateurs do or do not understand about programming.
> But I expect professionals understand the foundations of computing.
>
> If you don't want to understand the foundations of computing, no
> problem. You're just not qualified to be a professional programmer or
> software engineer.
Which foundations are you talking about? Some of them or all of them?
Are we all supposed to be polymaths?

Every person understands as much as they can, whether they are amateur
or professional. To try to pigeon-hole people so starkly seem to me to
be bordering on bigotry.

- Eric
>
>
> Randall Schulz

2011/9/9 Cédric Beust ♔ <cedric@beust.com>

On Fri, Sep 9, 2011 at 5:43 PM, Tony Morris <tonymorris@gmail.com> wrote:

Do this. Have them solve an apparent new problem that results in a
similar loop. Repeat this 3 or 4 times. Now point to the duplication.

I don't think that's the right angle for teaching, because fold does hardly anything more than a for loop to avoid duplication. It's reasonable to argue that the following expressions:
for (Foo b : foos) {
 value = someFooFunctionOn(value, b);
}
for (Bar b : bars) {
 value = someOtherFunctionOn(value, b);
}
and
value.foldLeft(value)(someFooFunction) value.foldLeft(value)(someOtherFunction)
are both as DRY as they can be.

No, not really:
var value = // some initial valuefor (Foo b : foos) {  value = someFooFunctionOn(value, b);}
for (Bar b : bars) { value = someOtherFunctionOn(value, b);}
Is roughly about the same as:
val result = (((/* some initial value */ /: foos)(someFooFunction)) /: bars)(someBarFunction)   

In other words, when you turn a for expression into a fold, you have done close to nothing to avoid duplication of code.

Sure, you could write:
var value = /*some initial value*/; for (Foo b : foos) { value = someFooFunctionOn(value, b); }; for (Bar b : bars) { value = someOtherFunctionOn(value, b); }
Seems to me that the fold approach precisely and concisely captures the idea of a catamorphism, whereas the for loops do nothing but express iteration.  Further, to my eye I certainly see a fair bit of duplication even in this trivial case.

fold's strengths compared to a for loop are conciseness and composability, which is what I emphasize, especially the latter, since conciseness is not always a desirable quality.

Conciseness is a desirable property, obfuscation is not desirable.  The sequential application of for statements does not express the catamorphism either concisely or clearly.
--
Jim Powers

Possibly not the best example, since I know that a pretty large
proportion of people working in the quant and hf trading spaces have a
pretty decent (ie significantly better than average) knowledge of
functional programming concepts, in addition to specialist trading
knowledge (I know of hedge funds who use nothing but OCaml or Haskell,
for example). I think that generally trading tends to lend itself to
people who are keen on both the problem domain and the tools
themselves (certainly in my experience, at least), and there are more
than a few people around who are using scala (and scalaz) in
production on high frequency trading platforms.

I think the music analogy holds rather well when we only talk about
classical music. Someone with a decent grasp of the theory can move
quite easily from a cello (c++) to a violin (java) but might well
struggle with moving straight to a piano(haskell) without practice.
Someone who has only ever played guitar by strumming along to music on
the radio might well be able to play the songs he knows perfectly, but
is going to struggle if he has to play a new song, or a known song on
a mandolin... I guess the true genius is the guy who can play
something truly beautiful on any instrument, whether it be the cello,
violin, piano, or possibly even the tuba (assembly?) or theramin
(prolog!).

(instruments selected largely at random. I'm not trying to imply
anything in particular here...)

On Sun, Sep 11, 2011 at 2:10 AM, Josh Berry wrote:
> Similarly, I fully
> expect those working on high frequency trading have a stronger grasp
> on trading concepts than most of the people working on the latest
> programming ideas here...

On Fri, Sep 9, 2011 at 07:05, Kevin Wright wrote:
> Interesting, I wonder how many of those who succeeded in the non-functional
> course later discovered that programming really wasn't "for them", and would
> have discovered this sooner given the functional approach.
> It's not so good for the university to have dropouts, but perhaps we're not
> doing the students any favours by lulling them into a false sense of
> confidence because it boosts pass rates.
> The possible explanations are too varied as well:
> - FP was too familiar with people who already had prior experience of
> programming via basic and scripting
> - The instructors were less familiar with teaching in that style
> - miranda was perceived as having no commercial relevance
> - etc.
> Still, it *is* an interesting data point!  We need more...
> Personally, I was lucky to get early exposure to FP. I started with Logo :)

Here's another datapoint on the same subject:
http://existentialtype.wordpress.com/2011/05/04/the-semesters-over/