Why moving to Scala - Part I - Writing less code | Hacker News Reader

Why moving to Scala - Part I - Writing less code

blog.furiousbob.com

75 pointsZeroC00l34 comments

I can't wait to see some case studies about experiences with Scala over the term of a long-lived, large project.

I like the language, but sometimes it feels like it promotes a lot of "creative" coding. My concern is that the idioms for dealing with things like collections seem to change with some frequency as more and more features get added to the language.

It's possible that my concerns are misplaced, I've written < 10,000 lines of Scala so I'm certainly a neophyte. It's just been troubling to find so many suggestions for doing things like folding/reducing.

FWIW we've got about 150k lines of scala code in the foursquare codebase and are thusfar very happy with it. There are certainly ways of writing bad code in scala (as with any language) but you learn pretty quickly how to avoid them.

Do you feel that you would have had as much success with less strong developers? (Edit: probably better phrased as "Do you think success would have been possible with less strong developers")

I don't mean "bad" developers as much as I mean ordinary "enterprise" developers.

The real concern I have is with hiring - what is the likelihood that you can take a competent Java developer (or any competent developer, I suppose) and expect them to make good decisions with Scala in a relatively short window of time (say 1-2 months)?

It's hard for me to say definitively because the eng team at foursquare is AWESOME (I know I"m biased here, but I really do think it's exceptional).

I do think it would have been possible though. In a lot of ways scala is a combination of the benefits of a compiled/type checked language (which should make things easier for developers of any skill level) + the concision of an interpreted language like python or ruby.

Thanks a lot for taking the time to answer, Harry. I really enjoyed the recording of your talk about Lift from the New York Scala meetup, by the way.

Happy to help out. FYI you can check out our eng blog at http://engineering.foursquare.com to see other posts about the technical details of foursquare.

For those of us who'd like to add this to our Squrl queues to watch later, the video is here:

http://www.vimeo.com/8057986

and the slide deck is here:

https://docs.google.com/present/view?id=dcbpz3ck_24f3v83ggz&...

We use Scala at our company too (The Weather Channel) and as long as you get a competent developer and a good mentor, they can write decent Scala code quick.

I think it is fair to say that one of the biggest reasons that people like Scala more than Java is that while it certainly improves A LOT of things that Java needed to fix, it also allows a clean break from some legacy Java baggage in terms of platforms.

For example, if you are doing a Java web project, most teams go with the Java EE platform simply because that is what is standard and so most of the things around Java in terms of the web are usually somehow in the vein of Java EE in terms of being big, kludgy, slow moving web frameworks.

So, even though nicer MVC frameworks like Play exist in Javaland, simply switching to Scala opens your eyes to the opportunities that exist in other frameworks like Lift and Play and scalatra.

In the end Scala is a nice mix of improving the language and revealing potentially better platforms at the same time.

If you really want to break with traditional Java web dev then Lift is probably a good fit. It's really different from every other framework I've worked with... In kind of a good but strange way. They have MVC and restful use patterns now but the original functional approach of the framework is very powerful, though it takes some getting used to.

As a current .NET developer that used to do Java, it seems like Scala includes a lot of things that C# developers have taken for granted for several years. I can see where it goes a bit further though, and I'm excited to see the community around it grow.

I'm a .NET guy looking to move away from C#, and feel much the same way you do. I'd love to have some additional niceties like LINQ, but right now Scala is probably the most natural language to transition to from C#.

Have you seen squeryl? Its not quite as nice as LINQ, but its definitely a useful DSL

The biggest problem with Scala for me are very cryptic compilation errors with several line long type informations that do not match each other.

The second problem is DDL hell. Too many changes to APIs, binary compatibility, dropped classes from 2.7.x -> 2.8.x -> 2.9.x.

That said I'm very happy with Scala as a language, but they should fix those problems.

1) There is a literal syntax for Java:

entries = new ArrayList<Integer>() {{ add(3); add(4); }}

But yes, certainly not as elegant as Scala. Having said that, you don't encounter literal collections very often (except maybe in tests).

6) Named parameters are pretty easy to emulate:

new Window().width(100).height(50)

although the builder pattern is safer:

Window w = new Window.Builder().width(100).height(50).build();

7) No more checked exceptions: celebrating this is like saying that your code is shorter because you no longer bother checking for errors.

8) You can only omit parenthese in Scala when there is exactly one parameter:

x.foo a <-- legal

x.foo a b <-- illegal

x.foo(a, b) <-- legal

One of the many syntactic quirks that Scala suffers from

9) Comprehensions are neat but they suffer from a crippled performance limitation that forces you to revert to imperative loops, even in optimized mode. This technical problem is serious and there is no solution in sight at the moment.

There are genuine reasons to be excited about Scala but this article makes me think that the author just discovered Scala and they haven't really dug very deep yet. When you do, you start realizing that Scala's nice features are offset by quite a few annoying limitations that will probably doom this language to a niche.

    1) There is a literal syntax for Java:
    
    entries = new ArrayList<Integer>() {{ add(3); add(4); }}

Unfortunately if you have warnings turned on in your IDE, it will complain about the lack of a serialVersionUID on your new class. This can be worked around via the `@SupressWarnings("serial")` annotation, but that hurts overall readability & code line count. That makes this technique less of a win than it would seem.

re 1. "create a new anonymous class with one instance and run this when initialising and by the way it's all in one line" is hardly "literal syntax".

re 7. They're ok as long as they're helpful, but at the same time they prevent writing something like useful `map()`, unless it throws everything. How many times do you need to catch something and handle, even though the situation can never happen? (as in - code doesn't throw the exception, but interface says otherwise) How many broken functions, like throwing `sleep()` are there? How many times do you have to write catch / finally / catch / finally / ... when closing more than one resource reliably? And it still doesn't protect you from silly null mistakes. I believe that properly using Option and matching will prevent more errors than checked exceptions ever did... (I may be wrong of course)

1) That is probably quite slow since you're creating a new class not just a new object.

6) Sure, now let's see all the boilerplate builder code you need to need to make that work.

7) Of course you can check for exceptions, you just don't need to add a bunch of throws clauses all over your code base to get the error bubbling up to the place where you want to handle it.

8) Doesn't look like a quirk to me. Looks pretty straightforward.

> 7) Of course you can check for exceptions, you just don't need to add a bunch of throws clauses all over your code base to get the error bubbling up to the place where you want to handle it.

These clauses allow static verification. In other words, the compiler will remind you to handle the error cases.

If you fail to do this and the compiler doesn't nag you, you can bet that most developers will never bother doing it.

> entries = new ArrayList<Integer>() {{ add(3); add(4); }}

Nah, entries = Arrays.asList(3, 4);

Scala is pretty sweet with a lot of syntactic sugars, but it still it doesn't fundamentally make writing correct code any faster, especially for Java developers who are competent with their IDEs. Until Scala's compile time and IDE support improves 10x, I see no point of using Scala for production code.

Slightly more verbose Java syntax is more than made up by the instant/incremental compilation/autocompletion/refactor that works. Even as a Java noob (I'm more experienced in C++), I can bang out correct code the first time without going through any edit/compile cycles, most of the time. IDE is the new REPL and language snobs always forget that.

I feel that the boilerplate code IDEs spit out on demand is far more of a liability than not. Once it's created it's your responsibility to maintain.

By focusing on the creation of the simplistic code we ignore the burden of maintaining ten lines of critical fluff for every intentional line of code.

I suspect that Scala is good, but I find the article a little disingenuous. In one example, the author counts curly braces on a line as part of the line count (when it happens in Java code), but doesn't do the same when it happens for Scala code. The constraint example leaves out the public method declaration, or at least doesn't illustrate how it directly maps to the Java code. Maybe it directly replaces everything there, but both snippets don't provide enough context to decide - at least not without already understanding a fair bit of Scala and Java code. That said, I did enjoy seeing some examples of more-or-less equivalent Java and Scala code.

I liked this; "One could argue on the max example being possible using ternary operator (which I use a lot, and now I understand why, I had a deep need for Functional Programming)." I don't know anything about functional programming, but I have used the ternary operator an awful lot over the years in C and C++. So maybe the fact that I can never understand why people complain that the ternary operator is hard to read means that I am a natural born functional programmer without even knowing it.

If writing less code is the objective, use Clojure.

For me, Scala has a couple killer projects going for it that should greatly help adoption: ensime and simple-build-tool. An IDE and a build environment that doesn't suck. When you're just starting out with a language, being able to get going on a project quickly is key to not losing interest. And these two projects fit that need perfectly.

when you are moving from Java, everything looks better :) which is probably how you could tlds this post

tltd

I've decided after 12 years of writing PHP to move to Scala. My (very limited) experience with it so far is that it is rock solid awesome.

it almost looks like PHP there :)

Care to explain, because I can't see it.

I believe that the impression is there because of the fact that Scala really reminds of a dynamically typed language, with type inference and lots of syntax sugar. And if PHP is the only dynamic language one has been exposed to, then well, PHP it looks like. :)

It certainly seems very fair to say that most dynamic languages have most of the features he's bragging about. That seems to be the a repeating pattern of the last several Scala articles I've seen here: The author is all excited about how terse it is (compared to Java, I guess), but it actually looks kind of bloated to me. :)

Their first example

val entries = List(Map("name"->"joe","age"->35),Map("name"->"joe","age"->32))

looks much more like PHP than like the Java example they give:

$entries = array("foo" => "bar", 12 => true);

And downvotes? wtf, php-haters?

I meant anything

Reply on news.ycombinator.com