- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Is Scala the Next C++
I have recently seen a number of discussions around issues like "is
Scala too complex, "is Scala too hard to learn," "Thinking in a
language vs. thinking into a language." etc.
I find these discussions fascinating as I often find myself on both
sides of the fence. At times I find coding in Scala increasingly
seductive and satisfying, at other times I try to read some of the
advanced code and concepts I see people discussing and I feel like a
moron who has no hope to ever grok what they mean, let alone simply
understand it. Often I just have to be satisfied that I get the gist
of it.
This sort of reminds me of my experience with C++. I started trying
the language as soon as there were competent compilers available and
enjoyed the new learning experience, trying to sample as many new
language features as I could and was generally able to master most of
them. However, after a while I was not writing code as often and ever
time I tried to start some new little project I found the start-up
cost of having to relearn C++ too high and switched back to C as much
as possible. My experience was that unless I used C++ continuously,
the overhead of coding was too high.
Eventually I took a class from Scott Meyers. My takeaway point from
that class was that there were programmers and there were type
designers. Type designers had to be very very good at type design. On
the other hand, with well designed type libraries and APIs, being a C+
+ programmers was not so bad after all.
After a while I did not do much C++ because I moved on to Objective-C
because I drank of the NeXT Cool-Aid. I really took to Objective-C
because it was was so much more simple to think in that language than C
++, and the NeXT types and APIs were awesome.
Eventually I moved on to Java and almost immediately became addicted
to the simplicity (over C++) and power (close to C++), but mostly to
the garbage collection. There was a reason I used to love writing code
in LISP.
Eventually I had a job where I had to look at some C++ code again, but
by then it was Microsoft C++ with ATL/COM. My first reaction was WTF?
How did this language get so messed up? Fortunately I was senior
enough I could just say "no way I am touching that!"
Eventually Java became my de facto language and I became increasingly
proficient with it. Then I started looking at Groovy and really liked
how much more expressive Groovy was, with minimal added complexity. I
found it hard to do much with Groovy because I could not convince my
colleagues of its value. Then I found Scala and tried to learn it but
had to bail because it was too confusing. But Scala is seductive!
Eventually I found my way back and became relatively proficient with
it. Yes, I can even write in a functional style and comprehend the
value of it. But I still cannot convince my colleagues of its value
either.
Martin Odersky's Levels http://www.scala-lang.org/node/8610 reminds me
very much of what I learned from Scott Meyers - that you do not need
to grok all of Scala to be proficient and productive in using it. I
personally hope to be able to transition some day from Java to Scala
as my main working language, but at the same time I am mindful of what
became of C++ because the geniuses who came up with ATL and COM.
What I am hoping we might debate is: what is to prevent Scala from
going the route of C++ (and maybe other trials and tribulations of
learning and using Scala). What are the barriers to adopting Scala,
and what compelling advantages does Scala offer to seduce us past
those barriers. Every week I see more barriers coming down because the
keepers of Scala work hard to remove them, but almost as often I see
people pointing out new barriers. Has Scala reached critical mass, or
are we still waiting for it?
Cheers, Eric
Re: Is Scala the Next C++
On Tue, Sep 6, 2011 at 1:45 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
I have the same feeling.
First of all, let it be clear that in terms of design, Scala is much more powerful and pleasant to work with than C++ ever was.
Having said that, a lot of things about Scala do remind me about C++ in the sense that "Scala is to Java what C++ is to C": a language more powerful but that also comes with costs.
I don't expect anyone who hasn't written thousands of lines of C++ in the 90's to understand the connection, though.
-- Cédric
Re: Is Scala the Next C++
Cédric Beust ♔ wrote:
> On Tue, Sep 6, 2011 at 1:45 PM, Eric Kolotyluk wrote:
>> This sort of reminds me of my experience with C++.
> I have the same feeling.
>
> First of all, let it be clear that in terms of design, Scala is much more
> powerful and pleasant to work with than C++ ever was.
>
> Having said that, a lot of things about Scala do remind me about C++ in the
> sense that "Scala is to Java what C++ is to C": a language more powerful but
> that also comes with costs.
There is an important difference, though: C++ is more complex than C,
but Scala is simpler than Java.
jwm
Re: Re: Is Scala the Next C++
2011/9/8 Jörg W Mittag <2BUsenet [at] googlemail [dot] com" rel="nofollow">JoergWMittag+Usenet [at] googlemail [dot] com>
A lot of people will probably disagree with you on this.
More expressive than Java, certainly. Simpler... definitely not.
-- Cédric
Re: Re: Is Scala the Next C++
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>
Re: Re: Is Scala the Next C++
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:
Re: Re: Is Scala the Next C++
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
>
>
>
Re: Re: Is Scala the Next C++
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
>>
>>
Re: Is Scala the Next C++
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).
Re: Re: Is Scala the Next C++
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
Re: Is Scala the Next C++
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". :-)
Re: Re: Is Scala the Next C++
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> wrote:
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
Re: Re: Is Scala the Next C++
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> wrote:
Re: Re: Is Scala the Next C++
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:
Re: Re: Is Scala the Next C++
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 [dot] lee [dot] wright [at] gmail [dot] com> wrote:
--
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
Re: Is Scala the Next C++
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 [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher
Re: Is Scala the Next C++
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 [dot] [dot] [dot] [at] paulbutcher [dot] com
> AIM: paulrabutcher
> Skype: paulrabutcher
Re: Is Scala the Next C++
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).
Re: Is Scala the Next C++
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
Re: Is Scala the Next C++
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 [at] paulbutcher [dot] com> wrote:
--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev [dot] lee [dot] wright [at] gmail [dot] com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
Re: Is Scala the Next C++
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/
Re: Re: Is Scala the Next C++
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!
Re: Re: Is Scala the Next C++
On Fri, Sep 9, 2011 at 1:48 AM, Francois <fanf42 [at] gmail [dot] com> wrote:
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
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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.
Re: Re: Is Scala the Next C++
On Fri, Sep 9, 2011 at 8:32 PM, Josh Berry <taeric [at] gmail [dot] com> wrote:
Here's a way. Show them that code. Looks about right, doesn't it?
Now point out that Foo value wasn't initialized, and the code therefore may not work.
Oops.
Won't have that problem with a fold.
Are we sold yet?
--Rex
Re: Re: Is Scala the Next C++
I recently started writing some Scala code after not writing any for a year, and being buried in Java code hard core since March. How quickly I forgot all our friends like .foldLeft, .reduce, .map, .filter,... Fortunately I am picking them back up again and relearning a functional attitude towards code. One thing that is really helpful is that I can write things in a procedural style in Scala until it works, then I can refactor things into a functional style until things work prettier.
To perhaps borrow from a (maybe) tired metaphor - Scala is like music, if you don't practice and stretch your goals you revert back to non-music.
What I am coming to see now is that Scala is not just a programming language, it is a narrative. It is a narrative about writing excellent code, and finding new ways to write even more excellent code. My personal problem is that I am not very effective at learning Scala from books the way I learned Java, for Scala I need to be part of the conversation and follow the narrative. Also, like most of my calculus, I have forgotten most of my high-level computing science theory from university, and today's computing science theory (especially in language design) is substantially more evolved than it was in 1980.
I'm pretty convinced by now that Scala is not the next C++. IHMO C++ degraded into something rather vulgar that I would rather not be involved with anymore, whereas Scala continues to evolve into something increasingly beautiful that I am having trouble keeping up with, and I increasingly have to depend on for others for understanding.
Cheers, Eric
Re: Re: Is Scala the Next C++
Here's my answer from a similar question from a few months ago:
http://stackoverflow.com/questions/5460213/why-use-foldleft-instead-of-procedural-version/5465024#5465024
-0xe1a
Re: Re: Is Scala the Next C++
On Tue, Sep 13, 2011 at 1:53 PM, Alex Cruise wrote:
>> Here's a way. Show them that code. Looks about right, doesn't it?
>>
>> Now point out that Foo value wasn't initialized, and the code therefore
>> may not work.
>
> Here's my answer from a similar question from a few months ago:
> http://stackoverflow.com/questions/5460213/why-use-foldleft-instead-of-p...
> -0xe1a
I think this just underscores the point I tried to make. The
difficulty is in getting people to think of the fold first.
Specifically, the declarative thinking behind it. Proving they are
the same is usually trivial enough. Getting people to think and type
the fold first is tough, compared to the for/loop if only because
people have to do a cognitive shift to think of the fold first. (That
is, it is still easier for me to think of the for/loop and then to
convince myself to use a fold instead. Compare this with Option
map/getOrElse, which I am actually comfortable thinking in terms of
maps followed by a getOrElse. To the point that I code those first in
Java sometimes, despite how hideous they look. I look forward to the
day I have the same comfort with folds.)
Does this make any sense? (Am I just plain playing a different ball
game, as it were?)
Re: Re: Is Scala the Next C++
On 2011-09-13 11:09 AM, Josh Berry wrote:
> On Tue, Sep 13, 2011 at 1:53 PM, Alex Cruise wrote:
>>> Here's a way. Show them that code. Looks about right, doesn't it?
>>>
>>> Now point out that Foo value wasn't initialized, and the code therefore
>>> may not work.
>> Here's my answer from a similar question from a few months ago:
>> http://stackoverflow.com/questions/5460213/why-use-foldleft-instead-of-p...
>> -0xe1a
> I think this just underscores the point I tried to make. The
> difficulty is in getting people to think of the fold first.
> Specifically, the declarative thinking behind it. Proving they are
> the same is usually trivial enough. Getting people to think and type
> the fold first is tough, compared to the for/loop if only because
> people have to do a cognitive shift to think of the fold first. (That
> is, it is still easier for me to think of the for/loop and then to
> convince myself to use a fold instead. Compare this with Option
> map/getOrElse, which I am actually comfortable thinking in terms of
> maps followed by a getOrElse. To the point that I code those first in
> Java sometimes, despite how hideous they look. I look forward to the
> day I have the same comfort with folds.)
>
> Does this make any sense? (Am I just plain playing a different ball
> game, as it were?)
Yes, it makes sense to me. Things like fold are tools that we forget to
use because we are used to doing things without such tools. As I try to
get back into Scala programming I am finding I have to spend more time
familiarizing myself with the tools, APIs and concepts, than just
duplicating the patterns I already know procedurally. You would not
believe the number of times I have seen people implement bubble-sort in
code just because they did not think to look in the library for
quick-sort - myself included.
Cheers, Eric
Re: Re: Is Scala the Next C++
Just so. Having made this shift myself over the past year, I've found that it has to do with learning to step back and ask, "What am I really trying to accomplish here?", and then internalizing that a foldLeft is (in many cases) a better representation of the goal than a for loop. Much of it has to do with recognizing, eg, an accumulator pattern as such.
I knew I'd made this particular mental leap about six months ago, when I realized that I *had* to implement foldLeft as a utility in ActionScript (which I'm currently working in), or my head was going to hurt. And then teach the other engineers on the project what foldLeft was, and why I'm using it here...
Re: Re: Is Scala the Next C++
You would not believe how many years I used a butter knife instead of a screwdriver, until I finally just when out an bought a toolbox. For years later I kept using the butter knife because it was closer than going downstairs for my toolbox.
Cheers, Eric
Re: Re: Is Scala the Next C++
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.
Re: Re: Is Scala the Next C++
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.)
Re: Re: Is Scala the Next C++
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.
Actually, I believe Runar coined the term.
-- Cédric
Re: Re: Is Scala the Next C++
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)
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.
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
Re: Re: Is Scala the Next C++
On Sep 10, 2011 3:58 AM, "Cédric Beust ♔" <cedric [at] beust [dot] com> wrote:
>
> On Fri, Sep 9, 2011 at 5:43 PM, Tony Morris <tonymorris [at] gmail [dot] 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
>
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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...)
Re: Re: Is Scala the Next C++
On Sep 9, 2011 5:29 PM, "Justin du coeur" <jducoeur [at] gmail [dot] com> wrote:
>
> 2011/9/9 Cédric Beust ♔ <cedric [at] beust [dot] 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!
Re: Re: Is Scala the Next C++
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.
Re: Re: Is Scala the Next C++
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...
Re: Re: Is Scala the Next C++
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 [at] gmail [dot] com>
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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!
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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.)
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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
Re: Re: Is Scala the Next C++
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.