On Scala's future
antoniocangiano.com
antoniocangiano.com
And the 'technical excellent' stuff like internal DSL are there if you want them, but you can safely ignore them. Maybe only library designers will use some of the more advanced features, but it is awesome having them available.
Let me repeat: I like Scala. I just wish that the Scala creators had avoided creating a syntax that is almost, but not entirely, quite unlike Java.
Look at Lift -- fast, scalable, and may as well be written in Greek. What is '_ ::'? What about '(something _)' and '(__ thing __)'? Why does Lift require that the programmer require goat-sacrifices to Maven to get things working?
It's very newcomer-unfriendly, and Scala people tend to be incredibly defensive of the language's odd syntax... and really hostile towards dynamic languages. Both static and dynamic-typed languages have their place in the programming world, so accept that and move on.
It's a Ruby-like language in flexibility, something like Camping or Sinatra is a much better representation of Scala style than a do-everything Rails rewrite with a hard-on for Comet.
I certainly hope it doesn't reflect too much on scala. There seems to be a bit of a hang over from java framework-itis where people get more exited over generic meta frameworks rather then solving actual problems.
Testing with specs and mockit has been much easier for us than in the bad ole Java days.
val m = mock[java.util.List[String]] // a concrete class would be mocked with: mock(new java.util.LinkedList[String])
// stub a method call with a return value
m.get(0) returns "one"
// call the method
m.get(0)
// verify that the call happened, this is an expectation which will throw a FailureException if that is not the case
m.get(0) was called
// we can also check that another call did not occur
m.get(1) wasnt called // or m.get(1) was notCalled
Being able to write a test like this seems like a pretty big win.
re: newcomer-unfriendly, the people I've spoken with all seem really excited about the language and want to share the love. shrug
And in my experience, you're simply wrong; aside from toy programs written for golfing or obfuscation contests, there really doesn't seem to be a significant difference, and many of the "concise" features of, say, Perl tend to be frowned on for real-world use because of the impact they have on the ability of others to read, understand and maintain the code.
As for Lisp, well, "concise" Lisp programs tend to remind me of stuff that comes out of the demoscene, where the headline is "look at this awesome demo in 4k!" but it actually relies on hundreds of megabytes' worth of graphics APIs. Lisp seems to be the same way: for every short piece of amazing Lisp code, there seems to be a corresponding huge chunk of functions and macros backing it.
Scala's operators are OK, but Haskell's are better yet because of the concept of a typeclass. You can't abuse + because it comes bundled with -, instances which support < are guaranteed to support ==, and so on. Operators actually have meanings that aren't arbitrary.