Doc continues to be a challenge, but there's a lot of good stuff at http://docs.scala-lang.org/ including an in-depth guide to collections that the author might find helpful.
In general I think a site for language docs where people can add comments/examples/content would be extremely useful. Like the php docs but for all languages in the same place. I never use php but comment-able docs are a win.
APIdock (http://apidock.com/) already has the “commentable multi-project documentation” infrastructure in place, though it only has the Ruby language and two Ruby libraries on it right now.
Api docs do tend to merely provide method signatures, which is great when you know what you are doing, but when you come upon a bunch of generics, implicit parameters, and thats in the docs for the first time, you end up combing through a lot of stuff. In many cases, a simple example use case embedded in the document with console output of the use case would admittedly be very helpful.
I'm in the same shoes with OP. Here's how my Scala skill progresses:
In the beginning, I wrote Scala "the Java way", sans semi-colons. Then I omit dots and parenthesis whenever possible (foo.do(bar) -> foo do bar). Then I learn to use immutable declaration (var -> val) and learn that expressions like this:
var i = 0
if (something) {
// Additional logic
i = 1
}
Can be made immutable like this:
val i = {
if (something) {
// Additional logic
1
} else 0
}
Then I try to make use its functional goodies like map and fold, and so on. I use IntelliJ with Scala and JRebel (free for Scala!) plugin. JRebel allows you to "hot reload" Scala classes to avoid server restarts.
I admit I'm a frequent lurker in SO when using Scala, as its API doc sucks, and I also dislike its integration with Java, although it's not Scala's fault. For API doc, I think it'd be better if it has examples, which reminds me of ActionScript API docs.
Re. SSA, I used to use it by default in Java when I still worked with that language, you don't have to switch to java to have it. Although it is significantly more verbose than in Scala (let alone in e.g. Erlang). Even for the shape you show here it can be done, Java has basic initialization guarantees so you can write:
final int i;
if (condition) {
// logic
i = 1;
} else {
i = 0;
}
and javac will produce an error if you forget the second branch of the conditional as this would allow an uninitialized `i`.
Although for clarity's sake I'd probably invert the condition so the "default" case is easier to see.
That also works for instance members, javac will allow setting them in a constructor or an initialization block, and will verify that they are set (and not set twice so you can't set the member in a constructor and an initialization block)
Very interesting comment about the notation for package-level scoping. When I worked with Java, most of the devs I worked alongside also used package-level access for more complicated private methods in order to unit test, but I've never seen that pattern used in Scala.
How do you generally test private methods in Scala? Would an inner class work? Path-dependent types in Scala seem to make this approach more elegant than in Java.
Scala is quite complex, not just the base language, but the standard libraries, the ability to comprehend code by just looking at the lines (implicits!), and the eventual full implications of features as carried out to the logical conclusion by std libs, etc.
I wrote a lengthy email describing a year's worth of experience to scala, and here is an excerpt:
If we think that one of the goals of our developers (jr, mid and even
sr) is to fully understand as much of their execution environment and
stack as possible, the sheer bulk of the language and its standard
libraries becomes worrysome. I could probably re-write
java.util.concurrent and java collections from whole cloth if
necessary, but I could NOT re-write the Scala collection libraries.
Perhaps consider raising your hiring bar. Even young girls still in School in India didn't have trouble using Scala: http://www.scala-lang.org/node/10714
16 comments
[ 2.6 ms ] story [ 53.6 ms ] threadFor beginners http://dcsobral.blogspot.com/2011/12/using-scala-api-documen... may be helpful in learning how to navigate the docs buuut what really helps are examples especially with scala's sometimes long and hard to parse type signatures.
In general I think a site for language docs where people can add comments/examples/content would be extremely useful. Like the php docs but for all languages in the same place. I never use php but comment-able docs are a win.
In the beginning, I wrote Scala "the Java way", sans semi-colons. Then I omit dots and parenthesis whenever possible (foo.do(bar) -> foo do bar). Then I learn to use immutable declaration (var -> val) and learn that expressions like this:
Can be made immutable like this: Then I try to make use its functional goodies like map and fold, and so on. I use IntelliJ with Scala and JRebel (free for Scala!) plugin. JRebel allows you to "hot reload" Scala classes to avoid server restarts.I admit I'm a frequent lurker in SO when using Scala, as its API doc sucks, and I also dislike its integration with Java, although it's not Scala's fault. For API doc, I think it'd be better if it has examples, which reminds me of ActionScript API docs.
Although for clarity's sake I'd probably invert the condition so the "default" case is easier to see.
That also works for instance members, javac will allow setting them in a constructor or an initialization block, and will verify that they are set (and not set twice so you can't set the member in a constructor and an initialization block)
How do you generally test private methods in Scala? Would an inner class work? Path-dependent types in Scala seem to make this approach more elegant than in Java.
And yes, the F# compiler is around 1/8th the speed of the C# compiler, at best - possibly much worse.
I wrote a lengthy email describing a year's worth of experience to scala, and here is an excerpt:
If we think that one of the goals of our developers (jr, mid and even sr) is to fully understand as much of their execution environment and stack as possible, the sheer bulk of the language and its standard libraries becomes worrysome. I could probably re-write java.util.concurrent and java collections from whole cloth if necessary, but I could NOT re-write the Scala collection libraries.