The for Loop “Reads”. Not Sure About Some of the Vector Methods Though…

The claim that Scala doesn’t “force you to jump through hoops [with the syntax]” (Atomic Scala pp.109-110) holds true for the for loop, especially when you “read” it as follows:

// “for i gets each value of the Vector"
for (i <- Vector(1, 2, 3, 4)) {
    println(“the value of I is: “ i)
}

I especially like that it parses in this instance, in the same way a lot of Ruby syntax does.  (Update, 5th September, 2013: As Summary 2, pp. 126-7 of Atomic Scala points out, the Scala “for” focusses on the loop, rather than the counting.  Precisely. And if you want to count? Loop through a range.  Beautifully explicit. You even get the Range’s “to” and “until” methods. Luverly)

But what about “Vector.sorted”?  I follow the argument (Atomic Scala pp.110) that Scala likes to “leave things in place” and instead create new copies of things. But for me, a good method name always is, or starts with a verb: getXxxx, sortXxxx, calculateXxxx.  That’s because methods act on the object they belong to, using the parameters they are passed.

But is this just another thing I’m trying to carry across from the well-worn Java/OO world?  My dictionary tells me (we focussed more on creativity at my school…) “sorted” is an adjective, and my dictionary also tells me that an adjective is

“a word naming an attribute of a noun", such as sweet”

(Oxford Dictionary of English)

Now if we see it in context:

val sortedVal = v4.sorted

And read it, knowing that Scala prefers to leave the original objects alone, and return a copy (and in this case a sorted copy) then perhaps I can warm to this.  I don’t think I’ll have too much of a problem, as long as things are consistent in this rule.  But doesn’t “Vector.sum” already break this rule? (Shouldn’t it be “summed”?)

Small Things That Make Me Happy #1

When you display a Vector:

val vector = Vector(1, 2, 3)

println(vector) // prints “Vector(1, 2, 3)”

It prints in the same form as the initialization expression.

That makes me happy.

(from Atomic Scala, pp.109)

That’s Annoying

Annoyingly, the Scala REPL doesn’t show all the possible completions when you press the [TAB] key.  Apparently the Scala documentation may contain other features.

I wonder why this is?  Something else to add to the “To Find Out” list…

Additionally, when running in the REPL, scripts will “sometimes have behaviour that is not proper for regular Scala programs.” (Atomic Scala, pp 79)

…

Atomic Scala has TDD Baked In

I’m still slowly working through Bruce Eckel’s and Dianne Marsh’s Atomic Scala.  I just got to the Testing "Atom” (Chapter) (pp. 94-100).  It’s the first atom (that I can recall anyway) which has merited a sub-atom, entitled “Testing as Part Programming”, and it introduces TDD.

I’m a massive fan of TDD, and my this I mean Kent-Beck-Red-Green-Refactor-Test-Driven-Design-TDD, and these guys get it.  They keep it simple (it’s a beginners book after all) but it’s the first time I’ve seen TDD being brought in so early to teach a new language (hell, I’ve never even seen it for frameworks outside of Beck’s “Test-Driven Development by Example”, and it works excellently. 

Given the known, but little-discussed mental-offloading benefits of TDD, I’m surprised they’re such pathfinders.  A real shame really, but others loss is their gain…

REPL :paste Power Move (via Atomic Scala)

This is a blatant cut-and-paste, but as it’s about cutting-and-pasting, I think it’s almost allowed. (from Atomic Scala by Bruce Eckel and Dianne Marsh, Summary I, pp. 65)

To put the Scala REPL into multi-line, delayed-interpretation, paste-mode, use the :paste command. To evaluate when you’re done, hit CTRL-D.

Good times.

Statements and Expressions (via Atomic Scala)

NOTE: I’ve posted on the vague area of this topic before. 

As previously discussed, not having a strict CompSci background seems to be a particular hindrance when trying to learn Scala. At least when you are following the standard texts. One example of this is around the terminology regarding “Statements” and “Expressions”. I know it’s important I know the difference, but what is  the difference?  “Atomic Scala, Atom: Expressions” (pp. 54) to the rescue:

A statement changes state […] An expression expresses [a] result.

Now, not only is this clear, its terse, and memorable too. I’d expect nothing less from a book co-written by the author of Thinking in Java.  Good ole’ breezy simplicity.  A section of my mind now feels free to really grok the goodness of immutability and case classes.

“Atomic Scala” is Available (as a PDF too)

FULL DISCLOSURE: I was a proof-reader/tester on an early draft of Atomic Scala, and I know both Bruce and Dianne.

I’ve posted before about Atomic Scala, for which I hold out great hope.  It was always my aim to use it as the wedge which which I would force my way into Scala-greatness.  The problem was, I do all my reading on the train, and there was no way I was going to lug a technical tome back and forth to work on top of my laptop.

Until now (well, now-ish, I’m a little slow in getting to this post) there has been no electronic version.  Ideally I’m looking for a Kindle (.mobi) version, but anything electronic would do.  This meant that I’d been fighting my way through Nilanjan Raychaudhuri’s Scala in Action. Until now.

I’m pleased to say that I’ve heard from Bruce and Dianne that you can now get an Atomic Scala PDF (with Kindle .mobi to come later when it’s available at no extra cost) for $20.00 from Gumroad.  (It’s in Beta, but that’s for technical, not content reasons – the dead-tree version has been about for more than six months.)

I’ve got it, and am loving it.  I highly recommend you get a copy too.  If you want to dip your toe in free, the first 100 pages are available for free.