5 ms·

Starting out, it makes sense to just "write Java in Scala", and gradually introduce the advanced concepts of Scala as you learn them. That way, you can be imme

Starting out, it makes sense to just "write Java in Scala", and gradually introduce the advanced concepts of Scala as you learn them. That way, you can be immediately productive.

catnaroek 13y ago
That way you can delude yourself into thinking you are productive, because you are writing code immediately. However, productivity is not to be measured by the number of lines of code; rather, by 1. the amount of actual functionality implemented, 2. the elegance of the design (which saves time refactoring later on).
- lmm 13y ago
  It's easy to forget the value of delivering functionality immediately. It's all too easy to spend a long time on an elegant design that doesn't actually serve business needs. I like to follow an agile approach where if something can't deliver value in 2 weeks then it's not worth doing (or, more likely, needs to be split into smaller pieces). That's plenty of time to learn enough Scala to be more productive than you were in Java, even though it will take months or years to learn the full language.
  - catnaroek 13y ago
    Learning a new programming language is an intellectual, exploratory endeavor, even if it might result in adopting that language for future programming projects. Writing software professionally is a pragmatic engineering job constrained by non-intellectual considerations such as customer expectations (and lack of knowledge thereof) and limited availability of resources (time, money, skills, etc.). Suggesting that both activities should be approached the same way is a huge mistake.
    - lmm 13y ago
      I learnt scala very effectively simply by delivering a program in it at my day job. I'm not sure about "should", but in my personal experience I've found that the best way to learn.
- trailfox 13y ago
  ...and the only way you learn how to write more elegant code is to start writing code...
  - catnaroek 13y ago
    In my experience, jumping straight to writing code results, if anything, in a huge mess. For anything more complex than proof of concept programs for specific language or library features, this quickly becomes unmanageable. I have obtained much better results by first developing a nice logical model (not necessarily 100% formal, but at least rigorous enough to be amenable to formalization), and only then picking a programming language into which the model can be translated with a minimum amount of effort. In this regard, a good language is one that allows translating as many logical constraints as possible into statically verifiable constructs (such as types). The nice thing about static verification is that errors in the translation can be detected as soon as you make them. Heck, in some cases, even errors in the original conceptual design can be detected. Scala is a better language than Java because its type system is so much more powerful. Using Scala as if it were Java nullifies this advantage, and leaves you only with the inconvenience of having to learn a new syntax. So, what is the point?
    - lmm 13y ago
      The new syntax is similar but nicer. If you just use Scala as "java with type inference, no semicolons, and a shorter form of final" it's already an improvement over java.
      - catnaroek 13y ago
        > "java with type inference" Scala only has very limited inference. In fact, so limited that, based on this criterion alone, I would take Java's powerful refactoring tools over Scala's inference anytime. (One of my main uses of inference is enabling fearless aggressive refactoring.) But let's say Scala had a type system amenable to global inference with a nice principal types property. This does not prevent you from having to annotate types when, at a module boundary, you want a term to have a more specialized type than its principal type. (Within module boundaries, it is admittedly no big deal to have terms whose types are more generic than their use would warrant.) > "no semicolons, and a shorter form of final" You cannot tell me with a straight face that cosmetic syntactic changes are a particularly compelling reason to switch languages. (Well, you can, but then you cannot convince me you are a pragmatic engineer.) > "it's already an improvement over java." Yes, but, without taking advantage of Scala's powerful type system, is the improvement over Java substantial enough to justify the investment in learning a new language?
rybosome 13y ago
The danger of that approach is that, in my experience, it's more likely to turn someone away from Scala. At my last job, some of the engineers did write Java in Scala. In what I'm sure is not a coincidence, they were also the ones who disliked Scala the most, and felt that it was detrimental to our codebase. By not learning its differentiating features, all they saw was the burden of having two languages, library support, spotty IDE, painful Scala upgrades, etc. In fact, since I've left, I've heard that they are migrating a lot of the Scala back to Java; the effort is being led by those who never wrote idiomatic Scala. Again, I'm sure this is not a coincidence.
ericssmith 13y ago
Pattern matching, immutability, option types, combinators, traits are not advanced features in Scala. They are fundamental concepts. To be productive in Scala, write in Scala. Otherwise, you will needlessly waste a huge chunk of your life, including having to go back and clean up your messes.
dustingetz 13y ago
I'm leading a scala transition at a javashop. I think you need a crital mass of people who understand scala as well as a lot of respect for your colleagues for this to go smoothly, 10x so if you have legacy code. There will be some very tense discussions about how things ought to be implemented, and if not well managed, it can feel like "this approach is wrong, your code is bad and you are a bad engineer" which is toxic to any team. Sorry on mobile or I would write more. There is a lot of blog activity on this subject both from successful teams and unsuccessful that your leads absolutely must understand
- catnaroek 13y ago
  It should be evident to anyone with a modicum of understanding of what types are for, that Scala is a superior language to Java. (And Haskell even much more so, but Scala is friendlier to your existing investment in a Java codebase.) > There will be some very tense discussions about how things things ought to be implemented (...) Encoding as much as possible of the problem domain's logical constraints in types. Any property enforced by a type checker (and not subverted via a type system escape hatch) is a property that you do not have to test. > (...) and if not well managed, it can feel like "this approach is wrong. your code is bad and you are a bad engineer" My experience with most programmers using Java/C#/Python/whatever is precisely that: "Their approach is wrong. Their code is bad. And they are bad engineers." I have to waste my precious time subverting their brittle type systems (downcasts, reflection, assuming stuff is not null, etc.) and enforcing correctness the hard way (extensive testing or even good old non-computer-assisted brain usage), when I could simply read type signatures, get free theorems, run a couple of tests for checking stuff that cannot be inferred from types, and move on to the next thing.
  - wpietri 13y ago
    You omitted the part where the previous poster described that quote as toxic. If you see your time as much more precious than your colleagues, and default to treating them with contempt, you're going to have a hard time finding colleagues. Which you may not care about. But what should matter to you is that it's basically a self-fulfilling prophecy. If you treat your colleagues like that, they're never going to get better, and they're going to be the ones who eventually vote to throw out all your beautiful code and go back to Java, where they at least understand what's going on and nobody condescends to them all day.

Starting out, it makes sense to just "write Java in Scala", and gradually introduce the advanced concepts of Scala as you learn them. That way, you can be immediately productive.

catnaroek 13y ago

That way you can delude yourself into thinking you are productive, because you are writing code immediately. However, productivity is not to be measured by the number of lines of code; rather, by 1. the amount of actual functionality implemented, 2. the elegance of the design (which saves time refactoring later on).

lmm 13y ago
It's easy to forget the value of delivering functionality immediately. It's all too easy to spend a long time on an elegant design that doesn't actually serve business needs. I like to follow an agile approach where if something can't deliver value in 2 weeks then it's not worth doing (or, more likely, needs to be split into smaller pieces). That's plenty of time to learn enough Scala to be more productive than you were in Java, even though it will take months or years to learn the full language.
- catnaroek 13y ago
  Learning a new programming language is an intellectual, exploratory endeavor, even if it might result in adopting that language for future programming projects. Writing software professionally is a pragmatic engineering job constrained by non-intellectual considerations such as customer expectations (and lack of knowledge thereof) and limited availability of resources (time, money, skills, etc.). Suggesting that both activities should be approached the same way is a huge mistake.
  - lmm 13y ago
    I learnt scala very effectively simply by delivering a program in it at my day job. I'm not sure about "should", but in my personal experience I've found that the best way to learn.
trailfox 13y ago
...and the only way you learn how to write more elegant code is to start writing code...
- catnaroek 13y ago
  In my experience, jumping straight to writing code results, if anything, in a huge mess. For anything more complex than proof of concept programs for specific language or library features, this quickly becomes unmanageable. I have obtained much better results by first developing a nice logical model (not necessarily 100% formal, but at least rigorous enough to be amenable to formalization), and only then picking a programming language into which the model can be translated with a minimum amount of effort. In this regard, a good language is one that allows translating as many logical constraints as possible into statically verifiable constructs (such as types). The nice thing about static verification is that errors in the translation can be detected as soon as you make them. Heck, in some cases, even errors in the original conceptual design can be detected. Scala is a better language than Java because its type system is so much more powerful. Using Scala as if it were Java nullifies this advantage, and leaves you only with the inconvenience of having to learn a new syntax. So, what is the point?
  - lmm 13y ago
    The new syntax is similar but nicer. If you just use Scala as "java with type inference, no semicolons, and a shorter form of final" it's already an improvement over java.
    - catnaroek 13y ago
      > "java with type inference" Scala only has very limited inference. In fact, so limited that, based on this criterion alone, I would take Java's powerful refactoring tools over Scala's inference anytime. (One of my main uses of inference is enabling fearless aggressive refactoring.) But let's say Scala had a type system amenable to global inference with a nice principal types property. This does not prevent you from having to annotate types when, at a module boundary, you want a term to have a more specialized type than its principal type. (Within module boundaries, it is admittedly no big deal to have terms whose types are more generic than their use would warrant.) > "no semicolons, and a shorter form of final" You cannot tell me with a straight face that cosmetic syntactic changes are a particularly compelling reason to switch languages. (Well, you can, but then you cannot convince me you are a pragmatic engineer.) > "it's already an improvement over java." Yes, but, without taking advantage of Scala's powerful type system, is the improvement over Java substantial enough to justify the investment in learning a new language?

rybosome 13y ago

The danger of that approach is that, in my experience, it's more likely to turn someone away from Scala. At my last job, some of the engineers did write Java in Scala. In what I'm sure is not a coincidence, they were also the ones who disliked Scala the most, and felt that it was detrimental to our codebase. By not learning its differentiating features, all they saw was the burden of having two languages, library support, spotty IDE, painful Scala upgrades, etc. In fact, since I've left, I've heard that they are migrating a lot of the Scala back to Java; the effort is being led by those who never wrote idiomatic Scala. Again, I'm sure this is not a coincidence.

ericssmith 13y ago

Pattern matching, immutability, option types, combinators, traits are not advanced features in Scala. They are fundamental concepts. To be productive in Scala, write in Scala. Otherwise, you will needlessly waste a huge chunk of your life, including having to go back and clean up your messes.

dustingetz 13y ago

I'm leading a scala transition at a javashop. I think you need a crital mass of people who understand scala as well as a lot of respect for your colleagues for this to go smoothly, 10x so if you have legacy code. There will be some very tense discussions about how things ought to be implemented, and if not well managed, it can feel like "this approach is wrong, your code is bad and you are a bad engineer" which is toxic to any team. Sorry on mobile or I would write more. There is a lot of blog activity on this subject both from successful teams and unsuccessful that your leads absolutely must understand

catnaroek 13y ago
It should be evident to anyone with a modicum of understanding of what types are for, that Scala is a superior language to Java. (And Haskell even much more so, but Scala is friendlier to your existing investment in a Java codebase.) > There will be some very tense discussions about how things things ought to be implemented (...) Encoding as much as possible of the problem domain's logical constraints in types. Any property enforced by a type checker (and not subverted via a type system escape hatch) is a property that you do not have to test. > (...) and if not well managed, it can feel like "this approach is wrong. your code is bad and you are a bad engineer" My experience with most programmers using Java/C#/Python/whatever is precisely that: "Their approach is wrong. Their code is bad. And they are bad engineers." I have to waste my precious time subverting their brittle type systems (downcasts, reflection, assuming stuff is not null, etc.) and enforcing correctness the hard way (extensive testing or even good old non-computer-assisted brain usage), when I could simply read type signatures, get free theorems, run a couple of tests for checking stuff that cannot be inferred from types, and move on to the next thing.
- wpietri 13y ago
  You omitted the part where the previous poster described that quote as toxic. If you see your time as much more precious than your colleagues, and default to treating them with contempt, you're going to have a hard time finding colleagues. Which you may not care about. But what should matter to you is that it's basically a self-fulfilling prophecy. If you treat your colleagues like that, they're never going to get better, and they're going to be the ones who eventually vote to throw out all your beautiful code and go back to Java, where they at least understand what's going on and nobody condescends to them all day.