1 note

Hey Bostonians, I’m giving Scala talks on Functional API Design and Android Development a week from today, sign up and join us!

“But, if you don’t like my definition, if you’d like to claim that an ‘actor’ is actually just a function A => Future[B] and that therefore ‘actors’ are composable, then I don’t really have a problem with that (although, why call this model ‘actors’?”

Follow up to ‘Actors are not a good concurrency model’

Curried and Confused

The best post on the internet got some sweet linkage again this week. You know, the one where Scala is too complex because you can express the sum of a list of numbers like so:

def sum(nums: List[Int]) = (0 /: nums) { _ + _ }

In the intervening years since that expression prompted a ‘verdict’ that Scala was too difficult for us regular folks, a lot of us have written a heck of a lot of Scala. We had to make implicit.ly just to keep up with the flow of Scala software that people are publishing these days. The pump is primed and the machinery has finally come to life. It’s an exciting time! For some.

But since it’s come up, let’s review that old /: scarecrow. What makes him so perplexing to newcomers? Some have blamed the use of non-letters in the name. Okay then, how much clearer would Joe BeanFactory find this definition?

def sum(nums: List[Int]) = (nums foldLeft 0) { _ + _ }

Not much really! Well, maybe the problem is the infix notation?

def sum(nums: List[Int]) = nums.foldLeft(0) { _ + _ }

Yeah, I don’t know. By this point our rhetorical corporate programmer has gone out for coffee. Perhaps he will be back later to decide which programming languages we’re all supposed to use for his convenience. Maybe he would rather express things like 1 + 1 as 1.plus(1) —or, maybe he just doesn’t give a Dilbert about orthogonality.

But seriously guys, I don’t think it’s the infix notation or the permitting of symbolic characters in syntactic symbols that make applications of /: difficult to grok at first. It’s the blessed currying. Setting off the first function application with parentheses prevents one’s uninitiated mind from cheaply translating it to a familiar series of parameters. Instead you have to recognize that the first function application returns a second function, which is applied to another set of parameters. It’s trippy.

Truth be told, this perplexed me at the time. But instead of rejecting the language for supporting functional constructs beyond my experience, I decided to keep learning—and I’m happy with how that has worked out. So it’s interesting that two years later, this particular functional freak-out has been ‘cited’ to brand Scala as overly complex (Perl-y) while a second thread of spite bemoans Scala’s insufficient promotion of currying.

It’s simple, you see. The currying in Scala makes innocent enterprise developers cry in their frappuccinos, while similar encounters in OCaml inspire a rapturous session of functional mind-blowing.

Well. At least you can learn Scala at your desk.

“Crap, there’s an underscore. Is it a ‘point’? Good question. And the answer is no.”

Robert Fischer Finally Admits that Scala is Functional

“Because aside from the static typing, all the language features that Odersky trots out already exist in Perl.”

Scala: Only Different from Perl in Fundamental Ways

“Dependency Injection is one of the techniques that I use regularly when I am programming in Java. … I have been programming more in Scala and Clojure and being exposed to many of the functional paradigms that they encourage and espouse … it may be we will see that this is yet another instance of a pattern melding into the chores of a powerful language’s idiomatic use.”

Dependency injection potentially sidelined by function currying

“So what’s wrong with actors? The problem which dooms the actor model is that actors are fundamentally not composable.”

Bad actors

Page 1 of 2

}