4 ms·

All I can say is that I think you're completely mistaken. I can count on one hand the number of times I've had to do casting in Scala over the course of writin

All I can say is that I think you're completely mistaken. I can count on one hand the number of times I've had to do casting in Scala over the course of writing four different web applications of various sizes in it. Fine-grained control over side effects is only a benefit if you consider it a benefit, and is IMO far from the greatest benefit you can get from a strong, flexible type system. Easy mutability has little to do with type safety—indeed, type safety makes mutability marginally safer by at least holding you to a basic promise when you make mutations. I can't deny Scala is heavier than JavaScript, I suppose, for some definition of heavier that I assume means “has more features”, or means something that ends up equating to same. To argue that writing software in both Clojure and Java (or pick 2+ other languages that all run on the JVM, of course) will leave you with an objectively lower complexity:benefit ratio than using a single language is a dubious claim indeed. I don't guarantee that just using Scala will always result in a lower such ratio, but you'd have to make a much better quantitative argument to convince me that you can have a lower ratio consistently by using different languages instead. To deal in increasingly-divergent analogies one more time: if your work is in Las Vegas, you may not care that there are cheap supersonic flights to other cities. They will never compare to being able to do all of your work in Las Vegas, even if it means switching hotels depending on your needs on a given day.

pron 13y ago
Using two languages will give you a much better cost/benefit ratio, and here's why. In a team of 20 people, 18 will program in simple language A, while 2 will program in simple language B. The ones programming A know it well; those programming B know it well, and usually they would also know A well, as they would probably be your star programmers. The JVM makes integrating the two quite easy. You wouldn't need to discipline those 18 programmers to limit themselves to some subset of Scala, and they wouldn't be dumbfounded by its linked-list. I've worked on projects that used C++, Ada and FORTRAN; on projects that used Java, C, and some homegrown DSL; on projects that used C++ and Scheme. In all circumstances, the integration of languages proved simpler than "disciplining" the C++ programmers, and on the JVM that integration is a lot simpler than what we had to put up with back then. Also, bear in mind that team members change, as do team leaders. That proved to be a big problem for C++ projects as the discipline changed over the lifetime of the project.
- pkolaczk 13y ago
  First, Scala is not C++. Second, you need good discipline in those simple languages, as well. I've seen too much terrible Java code to believe Java simplicity saves you from being disciplined.
platz 13y ago
yeah, the polyglot approach is total in it's coverage, but I haven't experienced how polyglotism works on a team or set of teams. If you look at Odersky's presentation "The Trouble with Types" [1] at Strage Loop 2013, he describes Scala as a "type it to the max language" like haskell, ocaml or F#. He seems to be aware of the complexity problem and proposes a few ways to reduce some of the type complexity. [1] http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues
- pron 13y ago
  Yes, I have watched that talk, and Martin Odersky is clearly aware of Scala's problems. If he were to come up with a new language, I would certainly give it a try, but I think it's too late for Scala. BTW, to reiterate some of what's been said in other comments, I am certainly not opposed to using Scala in "Ruby style" projects (though Clojure would be a better option for those, too, IMO); I do, however, think that it's a very bad alternative for large Java projects.
  - trailfox 13y ago
    In our experience Scala has been a superb alternative for large Java projects. Practical experience vs. your opinion/speculation?
    - pron 13y ago
      Call it educated speculation based on years of experience with similar decisions. How big is the team? How many years of maintenance have you had on those projects? I remember C++ looked pretty awesome for a while. It was certainly great for one-man projects or small team. Then the problems started piling up. Thing is, C++ didn't have any good alternatives (maybe now we'll have Rust); Scala does.
      - pkolaczk 13y ago
        Scala is not C++. Scala has much better features to keep complex pieces of code separated from the simple pieces. Also C++ design philosophy was totally different from that of Scala's - C++ values performance over everything else, while Scala's top priorities are correctness and type-safety.

pron 13y ago

Using two languages will give you a much better cost/benefit ratio, and here's why. In a team of 20 people, 18 will program in simple language A, while 2 will program in simple language B. The ones programming A know it well; those programming B know it well, and usually they would also know A well, as they would probably be your star programmers. The JVM makes integrating the two quite easy. You wouldn't need to discipline those 18 programmers to limit themselves to some subset of Scala, and they wouldn't be dumbfounded by its linked-list. I've worked on projects that used C++, Ada and FORTRAN; on projects that used Java, C, and some homegrown DSL; on projects that used C++ and Scheme. In all circumstances, the integration of languages proved simpler than "disciplining" the C++ programmers, and on the JVM that integration is a lot simpler than what we had to put up with back then. Also, bear in mind that team members change, as do team leaders. That proved to be a big problem for C++ projects as the discipline changed over the lifetime of the project.

pkolaczk 13y ago
First, Scala is not C++. Second, you need good discipline in those simple languages, as well. I've seen too much terrible Java code to believe Java simplicity saves you from being disciplined.

platz 13y ago

yeah, the polyglot approach is total in it's coverage, but I haven't experienced how polyglotism works on a team or set of teams. If you look at Odersky's presentation "The Trouble with Types" [1] at Strage Loop 2013, he describes Scala as a "type it to the max language" like haskell, ocaml or F#. He seems to be aware of the complexity problem and proposes a few ways to reduce some of the type complexity. [1] http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues

pron 13y ago
Yes, I have watched that talk, and Martin Odersky is clearly aware of Scala's problems. If he were to come up with a new language, I would certainly give it a try, but I think it's too late for Scala. BTW, to reiterate some of what's been said in other comments, I am certainly not opposed to using Scala in "Ruby style" projects (though Clojure would be a better option for those, too, IMO); I do, however, think that it's a very bad alternative for large Java projects.
- trailfox 13y ago
  In our experience Scala has been a superb alternative for large Java projects. Practical experience vs. your opinion/speculation?
  - pron 13y ago
    Call it educated speculation based on years of experience with similar decisions. How big is the team? How many years of maintenance have you had on those projects? I remember C++ looked pretty awesome for a while. It was certainly great for one-man projects or small team. Then the problems started piling up. Thing is, C++ didn't have any good alternatives (maybe now we'll have Rust); Scala does.
    - pkolaczk 13y ago
      Scala is not C++. Scala has much better features to keep complex pieces of code separated from the simple pieces. Also C++ design philosophy was totally different from that of Scala's - C++ values performance over everything else, while Scala's top priorities are correctness and type-safety.