

How Scala Changed My Programming Style - coglethorpe
http://www.artima.com/scalazine/articles/programming_style.html

======
henning
A lot of the "OMG Scala <3" stuff being written recently comes from people who
have written Scala books and therefore kind of have an agenda.

The essential idea behind the post is this: using a language like Scala can
make you use a mainstream language like C# or Java differently. By using a
language that makes immutability the default it teaches you when mutable state
is actually necessary and when it isn't. This will lead you to write code in
whatever normal language that also has less mutable state, and fewer side
effects. It will therefore be easier to test and have fewer bugs.

And, no, I have not written any Scala books and have no Scala-related
products/services to sell you.

~~~
codeodor
"A lot of the "OMG Scala <3" stuff being written recently comes from people
who have written Scala books and therefore kind of have an agenda."

My guess would have been that they were excited about Scala before they wrote
the book.

------
lallysingh
I can't describe how happy I'll be when we have lambdas in C++. Them + the STL
will be a very lightweight gateway drug into functional programming for a lot
of programmers.

~~~
eru
With a special meaning for 'lightweight'. (C++ itself is quite heavy, but
people are accustomed to it already.)

~~~
lallysingh
In terms of cognitive load.

------
jimbokun
That is a nice, concrete example of how functional style can improve code
clarity.

------
richcollins
1\. "I enjoy the benefits of static typing such as types as documentation"

Documentation as a side effect of types is somehow better than a system
designed for good documentation?

"code completion in IDE"

See 1

"execution speed"

See LuaJIT, Self, Javascript ... etc

The reasons people often give to justify losing (types) so much flexibility
(late binding) never add up to me.

------
Hexstream
I have no idea why anyone would use ++i (though technically correct) instead
of i++ in a for loop's incrementation clause since the incrementation is done
_after_ the loop body, not before... That just seems like willfully confusing
intuition.

~~~
amalcon
Using i++ was the recommended practice before C++ came along and let people
change what i++ means. That convention was even the reason it's C++ and not
++C.

In C++, it's suggested to do ++i because it will sometimes result in fewer
calculations if i is an object with overloaded increment operators.

~~~
dkarl
Is this true? It was never explained to me this way, and it doesn't make much
sense. The increment will always be performed unless it can be optimized away.
In places where the two are equivalent, using i++ might impose a space penalty
if you have to store both values, which can be a significant consideration for
large objects. I don't know what you mean by "change what i++ means" since you
can't redefine ++ for any types for which it has a meaning in C. (Or maybe you
can, but I wouldn't know because it would never done in sanely written code;
the possibility definitely isn't taken into account in any C++ coding
recommendations I've read.)

Mainly I was taught that situations that _require_ i++ are less common, more
subtle, and easier to get wrong, so programmers should make them stand out by
using ++i everywhere else.

