Same thought. Wonder if those titles are generated simply for a more descriptive url. In that case, I think writers are missing their target audience - humans.
Also this particular title strikingly resembles typical MS's writing signature such as "Buy a home, get a US visa, Senators propose"
An alternative is an option type. In scala, you have the abstract type Option[T], which has implementations Some[T](value: T) and None[T].
Alternately, you have Either[A, B], with implementations Left[A](value: A), and Right[B](value: B).
So you can define a function that takes an Either[Int, ErrorMessage], rather than an Int or null. Getting a None[Int] is better than null, because it won't throw NullPointerExceptions if you access it sensibly.
Examples:
def x2or0(i: Option[Int]): Int = i.getOrElse(0) * 2
def x2(i: Option[Int]): Option[Int] = i.map(_ * 2)
def x2danger(iOrPossiblyNull: Int) = i * 2
// throws NullPointerException on null input
Ok, nothing with EMP in TF2 except for some anti-sticky bomb weapon the Engineer use. Looking for TF EMP grenade in Youtube gave me videos of jumpers. You know the demo man can do all that and probably more?
Actors had a memory leak when a lot of the formative Twitter Scala stuff happened. This lead to more usage of java concurrency primitives, which snowballed within the culture.
There's some people at Twitter who truly love and grok Scala and Scala idioms inside out, and there's some people who look at Scala as a more functional, less verbose Java.
Interesting form of technical debt. I hear Akka is replacing Scala's actors lib in 3.1 or thereabouts. Any talk about adopting it?
>There's some people at Twitter who truly love and grok Scala and Scala idioms inside out, and there's some people who look at Scala as a more functional, less verbose Java.
I'm a full card-carrying member of exactly both groups, but if all Scala does is succeed b/c of the latter, it will have served a wonderful purpose in displacing Java.
That first claim, that it's as expressive as Ruby, just doesn't hold up to scrutiny. (I've never used Ruby much, but I know my Python, and I'm going to assume they're approximately equally expressive). In no sane Python codebase would you see copy-paste that looks like:
Well, all these tuples can be represented as a List[Any] object in Scala with no problems and it would be just like any other dynamically typed language. However, if you want static type checking of your code, then yes - it is useful to tell the compiler the constraint on the range of values that are valid for your object. This is generally not possible in dynamic languages and should not be surprising.
This whole thing is a bit disingenuous, because the type signature argued over is an alternate signature which no one uses, because it provides custom concatenation of Traversables. All of the provided collections have reasonable implementations of concatenation, so this implies you're inventing your own collection.
Everyone uses the alternate form: flatMap [B] (f: (A) ⇒ Traversable[B]): CC[B]. Nevertheless, I'll attempt to explain the provided signature.
If you understand Java generics, you should hopefully be able to understand this response.
A, B, and That are type parameters/generics. So they can be filled in by any type. This flatMap method exists on a trait (think Java Interface) called Traversable[A]. Traversable is similar to Iterable in java.
(f: (A) ⇒ Traversable[B]) means that this function takes one argument called f. That argument is a closure or anonymous function. The closure itself takes one argument of type A (an element in the parent Traversable[A]), and returns a Traversable[B], where B is an arbitrary type.
Skipping ahead, flatMap returns an instance of That. But what's a That? It appears to be unspecified. This is where the "(implicit bf: CanBuildFrom[List[A], B, That])" makes it's appearance.
Implicit parameters are like default arguments. "def foo(i: Int = 12)" will use the i if provided, else it will default to 12. "def foo(implicit i: Int)" will take the i given, else it will grab the first available Int in the containing scope. If you, "val c = 11; def foo(implicit i: Int) = i * 2", calling foo(1) yields 2, but calling foo() yields 22.
The object bf is an object that provides an overridable custom definition of concatenation. So when you write your custom collection, you include an instance of CanBuildFrom[List[A], B, That] in the correct scope, and it gets used for the concatenation. CanBuildFrom's type parameters say that it exists in a List[A], takes a B, and returns a That.
So yeah, in your implementation of bf, you could make it a new MyCanBuildFrom[List[A], B, FunkyCollection[B]], and do funky concatenation.
I spent about a year as a maintainer of FlockDB, Twitter's social graph store. If you don't know, it's basically a sharded MySQL setup. One of the key pain points was optimizing the row lock over the follower count. Whenever a Charlie Sheen joins, or someone tries to follow spam us, one particular row would get blasted with concurrent updates.
Doing this in-memory in java via someAtomicLong.incrementAndGet() sounds appealing.
