4 ms·

It so happens I've been trying to write my first "real" Scala application these past few days. It's been a harrowing experience. Just a few highlights off the t

by Elrac 15y ago

It so happens I've been trying to write my first "real" Scala application these past few days. It's been a harrowing experience. Just a few highlights off the top of my head: * Eclipse support is spotty. Apparently legal programs suddenly develop lots of errors. Sometimes restarting Eclipse will allow the program to run anyway. * Types are constantly getting in my way. Sometimes types are correctly inferred, sometimes I need to add types to hint the compiler about what I'm doing. * Writing anonymous functions remains hit and miss. I just throw in underscores at random until something works. * I don't understand where the round or squiggly parentheses go in for comprehensions; i.e. what goes in the parens and what stays outside. * Hashmaps have a cool "+=" operator to add a key-value pair. So why does "put" work but "+=" doesn't? Another mystery. * Sometimes the parentheses after function invocations are optional if there are no parameters. Sometimes not. Why? It's not Scala's fault that the Eclipse plugin is less than perfect, it's already very powerful. As for my little struggles with the language, none of this is witchcraft; I'm sure there are well-defined rules and sensible answers to all these questions and many more. But I must say I'm annoyed with the huge number of rules behind Scala. The amount of stuff I need to learn to really use Scala effectively is daunting. Contrast this with my Ruby experience. This is a language that places great value on orthogonality: wherever possible, every operation works the same in every situation. So you have a smallish number of versatile functions, not too much stuff to absorb and things generally Just Work (TM). I taught myself Ruby and Rails and wrote my first useful Web app in a couple of weeks' worth of evenings, and it was a very pleasant experience. Clojure, similarly. All the parentheses took some getting used to, but the language's syntax is wonderfully simple and consistent, so getting stuff done is mostly just a matter of looking up the most appropriate function in the cheat sheet. I managed to be productive (for small programs) with Clojure in a couple of days. Scala is no doubt a fantastic language. But thanks to its kitchen sink attitude, it's not an easy language to come to grips with for someone with an aging memory and a less than full-time commitment.

currywurst 15y ago
Spending a little time with the unofficial Scala Style guide (http://davetron5000.github.com/scala-style/index.html http://davetron5000.github.com/scala-style/index.html) helped me figure out some of the "when? why?" questions.
dkarl 15y ago
Programming in Scala has a very straightforward explanation of for comprehensions. Mysteriously, almost every other explanation I read left me more confused than before. I don't know why there are so many poor and/or partial explanations out there. Read Programming in Scala instead and you'll be fine. As for type inference, another week of programming and you'll fall into a groove where you're anticipating when you need to declare types and when you don't. I had the same pain, and after a week, it had dropped down to a very occasional annoyance. It might just be my programming style, though -- I declare the return types on all functions that are meant to be called from another class or object, so there's a lot of information for the compiler to work with. I agree about the underscore thing. It's pretty useless, and Clojure's version looks superior to me. As best as I can tell, the underscore doesn't work inside an extra layer of parens or curly braces. But it's just syntactic sugar, after all. Using a named variable isn't the end of the world. It's just three extra non-whitespace characters, "n =>".
Lewisham 15y ago
But thanks to its kitchen sink attitude, it's not an easy language to come to grips with for someone with an aging memory and a less than full-time commitment. Perhaps this is one of the things that is tripping people up that I'm not doing. I tend to still be quite verbose in my code, even if only as a way of reminding myself what I thought the code was supposed to do (ever look back at Python and you're not really sure whether the variable is supposed to be a list or a tuple or a string? I have that problem all the time). I don't tend to use all the flourishes like underscores and such. It seems a bit like Perl's many ways to do it attitude. Except I feel like Perl was designed by ideology, whereas Scala has a lot of bits and pieces because it wasn't clear to Odersky et al. which bits people would like and which they wouldn't. Perhaps rather than trying to enforce an idomatic style, they wanted programmers to find their own way. But that means there's things in the language that exist and can't be taken out (XML literals), and there's no documentation cohesion (by which I mean different documents will tell you to do different things, and you're not sure which is best). If you Google "effective scala", you'll see a number of people clamoring for a book along the lines of Effective Java, and Scala sorely needs it, but Scala is still too much of a moving target to warrant putting anything in dead tree form yet. The Davetron Scala Style guide, however, is a really good stop gap, and helped me a lot.

by Elrac 15y ago

currywurst 15y ago

Spending a little time with the unofficial Scala Style guide (http://davetron5000.github.com/scala-style/index.html http://davetron5000.github.com/scala-style/index.html) helped me figure out some of the "when? why?" questions.

dkarl 15y ago

Programming in Scala has a very straightforward explanation of for comprehensions. Mysteriously, almost every other explanation I read left me more confused than before. I don't know why there are so many poor and/or partial explanations out there. Read Programming in Scala instead and you'll be fine. As for type inference, another week of programming and you'll fall into a groove where you're anticipating when you need to declare types and when you don't. I had the same pain, and after a week, it had dropped down to a very occasional annoyance. It might just be my programming style, though -- I declare the return types on all functions that are meant to be called from another class or object, so there's a lot of information for the compiler to work with. I agree about the underscore thing. It's pretty useless, and Clojure's version looks superior to me. As best as I can tell, the underscore doesn't work inside an extra layer of parens or curly braces. But it's just syntactic sugar, after all. Using a named variable isn't the end of the world. It's just three extra non-whitespace characters, "n =>".

Lewisham 15y ago

But thanks to its kitchen sink attitude, it's not an easy language to come to grips with for someone with an aging memory and a less than full-time commitment. Perhaps this is one of the things that is tripping people up that I'm not doing. I tend to still be quite verbose in my code, even if only as a way of reminding myself what I thought the code was supposed to do (ever look back at Python and you're not really sure whether the variable is supposed to be a list or a tuple or a string? I have that problem all the time). I don't tend to use all the flourishes like underscores and such. It seems a bit like Perl's many ways to do it attitude. Except I feel like Perl was designed by ideology, whereas Scala has a lot of bits and pieces because it wasn't clear to Odersky et al. which bits people would like and which they wouldn't. Perhaps rather than trying to enforce an idomatic style, they wanted programmers to find their own way. But that means there's things in the language that exist and can't be taken out (XML literals), and there's no documentation cohesion (by which I mean different documents will tell you to do different things, and you're not sure which is best). If you Google "effective scala", you'll see a number of people clamoring for a book along the lines of Effective Java, and Scala sorely needs it, but Scala is still too much of a moving target to warrant putting anything in dead tree form yet. The Davetron Scala Style guide, however, is a really good stop gap, and helped me a lot.