Is Scala the Next C++

On Fri, Sep 9, 2011 at 8:32 PM, Josh Berry <taeric@gmail.com> wrote:

On Fri, Sep 9, 2011 at 5:09 PM, Stefan Langer
<mailtolanger@googlemail.com> 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.

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

On Tue, Sep 13, 2011 at 8:45 AM, Rex Kerr <ichoran@gmail.com> wrote:

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.

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-procedural-version/5465024#5465024 
-0xe1a

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

On Tue, Sep 13, 2011 at 2:09 PM, Josh Berry <taeric@gmail.com> wrote:

I think this just underscores the point I tried to make.  The difficulty is in getting people to think of the fold first.

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

On 2011-09-13 8:45 AM, Rex Kerr wrote:

26Q83FX2h_oCc+XAjXUWnL85WuoL+mE7Kw [at] mail [dot] gmail [dot] com" type="cite">

On Fri, Sep 9, 2011 at 8:32 PM, Josh Berry <taeric [at] gmail [dot] com" rel="nofollow">taeric@gmail.com> wrote:

On Fri, Sep 9, 2011 at 5:09 PM, Stefan Langer
<mailtolanger [at] googlemail [dot] com" rel="nofollow">mailtolanger@googlemail.com> 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.

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

I'm sold :-)

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

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

On 2011-09-13 11:21 AM, Justin du coeur wrote:

CAO26FW18PSpYU7P9aLR1kyDtQL1cWcX3eO1KUmOoHS5D-vxP+g [at] mail [dot] gmail [dot] com" type="cite"> On Tue, Sep 13, 2011 at 2:09 PM, Josh Berry <taeric [at] gmail [dot] com" rel="nofollow">taeric@gmail.com> wrote:

I think this just underscores the point I tried to make.  The difficulty is in getting people to think of the fold first.

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

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