7 ms·

Scala is not a better Java

61 points by mnemonik 16y ago

Daishiman 16y ago
Why yes, giving you difficult to check XML files as a bad replacement for introspection, decent conventions, and complex class hierarchies (with tons of casts in the middle) to account for absence of features is just so much better.
barrkel 16y ago
"it was designed to restrict the kind of trouble programmers can get themselves into" Every programming language is designed to restrict trouble programmers can get into. The key is that they all have different ideas of trouble.
wheaties 16y ago
Inventing good languages within other languages is a good thing. Just look a Rails. Inventing bad languages, well, bad code is always going to be bad. I disagree that Scala is not better than Java. Any language which adds additional mechanisms to make my life easier as a developer is a good thing.
- Chris_Newton 16y ago
  > Any language which adds additional mechanisms to make my life easier as a developer is a good thing. What if they make life easier for you but harder for everyone else on your team? I'm not saying I disagree with your philosophy, just that there is merit in the other side of the argument as well. I want tools to build powerful abstractions, but I want those powerful abstractions to be easy for everyone to read and, when necessary, explore in detail.
  - btilly 16y ago
    How big does your team need to be? There is a productivity valley between small teams (up to 5-8 people) and large teams (20+). In that valley you get less done than on either side, so it makes no sense to be there. What this means is that organizations need to make a choice between maximizing what can be done with at most 5-8 people, or else making teams of 20+ people work together smoothly. And the sets of features that are good for either of those goals are frequently bad for the other goal.
    - Chris_Newton 16y ago
      > There is a productivity valley between small teams (up to 5-8 people) and large teams (20+). Sorry, but I don't agree with that at all. As soon as you have more than one person working on the same part of your code, you incur some degree of overhead. I don't see why the numbers 8 or 20 are special. Are you really claiming that a competent development team of 18 people cannot do more than a competent development team of 8 people? To co-ordinate teams of many developers, we divide projects into manageable chunks, each with a relatively small number of developers working on them. This requires good abstraction tools, so that developers can see how their contribution fits into the larger picture, can work with the code written by others without having to know it in intimate detail, and can combine all the components into a complete product. Again, I don't see how this picture differs whether you have 8 people or 20 people, unless you're following some sort of surgical team model where you really are trying to get all of the smaller team working on the same code but most of them aren't actually writing that code at all.
      - btilly 16y ago
        It doesn't matter whether you agree, it is true. See page 229 in Software Estimation for references to research that a medium size project will be produced in the same number of calendar months by a team of 5-8 people or a team of 20-25 people. And it will take LONGER if your team is between those two sizes. Beyond that larger threshold, development also speeded up. In this case a medium sized project was 10-100 thousand lines of code, and for all the team sizes looked at across all of the projects examined averaged 50-60 thousand lines. I would expect that the small team likely had less code duplication within their project, which would indicate that when measured by functionality, the small team had an even bigger advantage. Note that this is calendar months to finish the project. If you measure in terms of dollars spent to finish, the most productive team size is 1. And yes, this is with the larger teams using standard practices such as being divided into smaller, more focused groups. The reason is that the process of doing that requires completely changing how you work, and that results in a significant productivity impact. Once you take that hit you can scale, but you have to take that hit first.
        16y ago
- zootm 16y ago
  I'm not sure the article asserted that Scala was "not better" than Java. It was asserting that Scala is not "a better Java"; that is that the design philosophies between the two languages are such that it's not right to treat Scala as an evolutionary "next step" from Java, as some have. I think there's some truth to that point of view.
strlen 16y ago
Scala's DSLs are internal DSLs, made through the use of higher order functions, closures and implicit conversions. That's very different from external DSLs, written in a separate language (macros in C and C++). There are also DSLs that straddle the line e.g., C++ templates ("generic meta programming") and Lisp macros (application of Lisp but at a different stage, resulting in new s-exps). That's a big distinction.
gte910h 16y ago
Scala is finally giving Java programmers a grown up language. Java is the "oh this is explicit, I just wrote a program the size of the federal register!" language. It is overly simplistic in several areas thereby causing complex workarounds to be implemented to solve real world issues.
acg 16y ago
Seems a superficial argument, C++'s features have not been added into Java to create Scala. Even the Java community is pushing Java7 in a direction with richer features, except the language is beginning to get in the way. Generics are not implemented too well, closures are likely to complicate matters further.
stephenjudkins 16y ago
Java is deliberately not programmer-orientated. That's the point of using it — it was designed to restrict the kind of trouble programmers can get themselves into. If you're stuck with the JVM, I guess the question is: how much rope do you want to give your programmers? Scala is essentially the opposite answer to Java. This was an interesting read but I disagree with this assertion. Java's lack of power as a language hasn't meant that people haven't written huge, complex, unmaintainable messes with it. Indeed, I think all the crazy dependency injection frameworks, configuration-by-XML, and other general insanity is due in part to the language's lack of power. Things that are simple in other languages (say, dependency injection, which can be replaced with runtime stubbing in Ruby or mixing in traits in Scala) often require painful and complicated ad-hoc solutions in Java. That said, it is possible to write code in Scala that requires a PhD in category theory to understand (see Scalaz), but there are also many examples of simple, functional, easy to understand code (see stuff that has come out of Twitter, like Kestrel or Nagatti). I think in practice, working with the modern Java ecosystem gives one at least as much rope to hang oneself as using Scala does.
- billmcneale 16y ago
  Scala's traits come nowhere near the functionalities offered by dependency injection frameworks such as Guice. When Scala encounters the need for DI, it's very likely that it will roll out a framework that will look a lot like Guice. Your point regarding the rope is well taken, the difference being that with Java, the rope lies in the frameworks, while in Scala, it lies both in the frameworks (take a look at Lift) and in the language.
  - stephenjudkins 16y ago
    Well, for a big enough project something like Guice will become necessary sooner or later. However, for smaller programs traits are simpler to use and get one 80% of Guice's functionality--and it's all built into the language. Traits are relatively easy to understand that any reasonably competent developer should be able to easily reason about. I don't see why a Scala-native DI framework wouldn't be able to leverage this existing, simple solution to build the last 20%. Guice is the result of smart Google engineers who had probably tried all sorts of DI frameworks before and finally developed something nice. It's the result of more than a decade of painful experiences with existing solutions to a real problem. In conclusion, I think you can hang yourself when using any language. In Scala, when I needed to mock out a dependency for a project, I settled on a fairly simple trait-based approach that was simple and elegant. In Java, I could have rolled by own Factory scheme that would be ugly and unmaintainable, or picked a DI framework that hopefully wouldn't have sucked. In this case I was presented with many fewer opportunities to make a mess than if I had been using Java. (BTW, you can use Guice in Scala programs right now! And, when you do, it looks way nicer and easier to use than in Java. See http://makeapp.blogspot.com/2009/09/how-to-use-guice-with-scala-and-java.html http://makeapp.blogspot.com/2009/09/how-to-use-guice-with-sc...)
narrator 16y ago
Scala is actually a better Ruby. All the messy fun stuff that we all love with Ruby like duck typing and monkey patching can be done easily with Scala, except it's all statically typed so it keeps the whole mess under control. For instance, you can have a duck type as a function argument that's contract is it implements a particular method signature. In Ruby there is no type type enforcement so you can get runtime errors when you pass in an object that doesn't have the right method, while in Scala the compiler catches it. You can monkey patch by doing implicit conversions in Scala to a rich type, allowing one to add methods to the Integer class, for example, but if you have to libraries that do the same monkey patch Scala will alert you to ambiguous situations. In Ruby this depends on load order and can cause all kinds of screwy bugs.
- cageface 16y ago
  Scala is brilliant in a way in that it hides all the incredible complexity you incur when you try to statically type a programming style evolved in dynamic languages. That is, it hides it to a point. It's easy enough to get started writing simple scripts and sprucing up old Java code but before long you get a compiler error that sends you scurrying away to the reference books and then it hits you that you really are going to have to come to grips with the type system and it's a doozy. I'm still not persuaded that all the gymnastics Scala has to do to allow Ruby-like flexibility really result in a more productive language overall. I need to spend more time with it to be sure but at first blush it really feels like the faustian bargain Scala has had to strike to merge expressive, Ruby-like syntax with strong, static type-checking and java compatibility has resulted in a language too complex for most working programmers. Clojure seems a lot more elegant and comprehensible.
  - narrator 16y ago
    When I get a compiler error in Scala it's almost always something that would cause a runtime error in a non statically typed language. The downside is that the error messages can be difficult to parse and resolve for beginners. Once I got over the learning curve, I realized that in almost all cases the compiler was trying to tell me something very useful. I do get a little annoyed at all the Haskell/OCaml type nerds trying to do things with the type system that are not particularly practical, for instance: http://apocalisp.wordpress.com/2010/06/16/type-level-programming-in-scala-part-4a-peano-number-basics/ http://apocalisp.wordpress.com/2010/06/16/type-level-program...
Parabola 16y ago
Features should be looked at individually to determine whether their expressive power is worth their potential for abuse, and also what the alternative would be for the use cases for that feature if the feature was not provided. Java refuses to do this and has barely evolved in a decade to the monstrous ecosystem of hacks it is now. Scala throws in the kitchen sink and manages to work things out pretty well. I think this means that the fine line isn't quite where we thought it was. But it's still there and Scala should be careful.
mhd 16y ago
It's not just a better Java, if you ask me. Scala, like Clojure, aren't really pure Java replacements, fixing some of the bugs and awkward syntax details. Both try to steer the programmer towards different ways of programming. They're better, and more. As I'm currently taking a look at Android development, I wish there was a simply "better Java". Something that doesn't stray too much from imperative C/Algol/Pascal-like programming, but doesn't require me to use a huge, bloated IDE just to cope with the language features. Better variable declaration, better modules, uniform access principle etc. Fantom looks interesting but -- again -- tries to be more than that (own library, multi-VM etc.).
dman 16y ago
Can any of the scala folks point me to a good introduction of the language ?
- samdk 16y ago
  Before you jump into Scala I'd recommend being familiar with Java and (at the least) being comfortable with the basics of an ML-like language or Haskell. Having had experience with a scripting language like Ruby or Python helps too. Knowing Java, Haskell, Ruby, and Python already, I found it really easy to jump into Scala with the references listed on the Scala site. If you do have experience with Java/statically-typed FP (or if you're just feeling brave) that's where I'd recommend looking.
- bitsai 16y ago
  Daniel Spiewak has written a fair number of Scala articles, and I've found them to be quite helpful: http://www.codecommit.com/blog/category/scala/page/10 http://www.codecommit.com/blog/category/scala/page/10
guelo 16y ago
Java beats Scala, and many other languages, in readability and maintainability. Java has a lot of best-practice conventions developed over many years of pain on how to make the code as readable as possible. The functional languages need these guidelines even more than Java does, but they seem to lack them. It's really easy to write insanely convoluted unreadable code in Scala.
- kunjaan 16y ago
  "Java beats Scala, and many other languages, in readability and maintainability." I have to respectfully disagree with this statement.
  - guelo 16y ago
    You have to respectfully state your argument or your comment is useless.
- TeHCrAzY 16y ago
  "It's really easy to write insanely convoluted unreadable code in Scala." It's really easy to write insanely convoluted and unreadable code in any language. The language isn't really the factor there, more the programmer.
  - guelo 16y ago
    That's why I said conventions. Java has many years in this area. There is nothing like Joshua Bloch's "Effective Java" for Scala.
    - TeHCrAzY 16y ago
      You are missing my point: that the language isn't the key part here, its the programmer. If a programmer doesn't adhere to some sane formating and code structure, it won't matter what language they write in, the result will be spaghetti.
      - 16y ago
andybak 16y ago
I mainly know OO through Python. I had a Java programmer try and explain why Dependency Injection frameworks were great and I went off and googled around and there are a few for Python. I still can't grok why I'd need one though. Is DI for Python the product of damaged minds or do they provide some real benefit?
- JulianMorrison 16y ago
  Even in Python, you benefit from structuring an object to accept its dependencies as inputs, rather than calling to them by their global names. It lets you test each class independently with mock objects that support the same interface.
  - andybak 16y ago
    By writing XML config files? (or is that just a Struts wart rather than an intrinsic part of DI?) Anyway - if mocking for tests is the major benefit of DI then there some other simpler ways to that. Everything I've read on DI makes it sound like a fairly complex beast.

61 points by mnemonik 16y ago

Why yes, giving you difficult to check XML files as a bad replacement for introspection, decent conventions, and complex class hierarchies (with tons of casts in the middle) to account for absence of features is just so much better.

barrkel 16y ago

"it was designed to restrict the kind of trouble programmers can get themselves into" Every programming language is designed to restrict trouble programmers can get into. The key is that they all have different ideas of trouble.

wheaties 16y ago

Inventing good languages within other languages is a good thing. Just look a Rails. Inventing bad languages, well, bad code is always going to be bad. I disagree that Scala is not better than Java. Any language which adds additional mechanisms to make my life easier as a developer is a good thing.

Chris_Newton 16y ago
> Any language which adds additional mechanisms to make my life easier as a developer is a good thing. What if they make life easier for you but harder for everyone else on your team? I'm not saying I disagree with your philosophy, just that there is merit in the other side of the argument as well. I want tools to build powerful abstractions, but I want those powerful abstractions to be easy for everyone to read and, when necessary, explore in detail.
- btilly 16y ago
  How big does your team need to be? There is a productivity valley between small teams (up to 5-8 people) and large teams (20+). In that valley you get less done than on either side, so it makes no sense to be there. What this means is that organizations need to make a choice between maximizing what can be done with at most 5-8 people, or else making teams of 20+ people work together smoothly. And the sets of features that are good for either of those goals are frequently bad for the other goal.
  - Chris_Newton 16y ago
    > There is a productivity valley between small teams (up to 5-8 people) and large teams (20+). Sorry, but I don't agree with that at all. As soon as you have more than one person working on the same part of your code, you incur some degree of overhead. I don't see why the numbers 8 or 20 are special. Are you really claiming that a competent development team of 18 people cannot do more than a competent development team of 8 people? To co-ordinate teams of many developers, we divide projects into manageable chunks, each with a relatively small number of developers working on them. This requires good abstraction tools, so that developers can see how their contribution fits into the larger picture, can work with the code written by others without having to know it in intimate detail, and can combine all the components into a complete product. Again, I don't see how this picture differs whether you have 8 people or 20 people, unless you're following some sort of surgical team model where you really are trying to get all of the smaller team working on the same code but most of them aren't actually writing that code at all.
    - btilly 16y ago
      It doesn't matter whether you agree, it is true. See page 229 in Software Estimation for references to research that a medium size project will be produced in the same number of calendar months by a team of 5-8 people or a team of 20-25 people. And it will take LONGER if your team is between those two sizes. Beyond that larger threshold, development also speeded up. In this case a medium sized project was 10-100 thousand lines of code, and for all the team sizes looked at across all of the projects examined averaged 50-60 thousand lines. I would expect that the small team likely had less code duplication within their project, which would indicate that when measured by functionality, the small team had an even bigger advantage. Note that this is calendar months to finish the project. If you measure in terms of dollars spent to finish, the most productive team size is 1. And yes, this is with the larger teams using standard practices such as being divided into smaller, more focused groups. The reason is that the process of doing that requires completely changing how you work, and that results in a significant productivity impact. Once you take that hit you can scale, but you have to take that hit first.
      - 16y ago
zootm 16y ago
I'm not sure the article asserted that Scala was "not better" than Java. It was asserting that Scala is not "a better Java"; that is that the design philosophies between the two languages are such that it's not right to treat Scala as an evolutionary "next step" from Java, as some have. I think there's some truth to that point of view.

strlen 16y ago

Scala's DSLs are internal DSLs, made through the use of higher order functions, closures and implicit conversions. That's very different from external DSLs, written in a separate language (macros in C and C++). There are also DSLs that straddle the line e.g., C++ templates ("generic meta programming") and Lisp macros (application of Lisp but at a different stage, resulting in new s-exps). That's a big distinction.

gte910h 16y ago

Scala is finally giving Java programmers a grown up language. Java is the "oh this is explicit, I just wrote a program the size of the federal register!" language. It is overly simplistic in several areas thereby causing complex workarounds to be implemented to solve real world issues.

acg 16y ago

Seems a superficial argument, C++'s features have not been added into Java to create Scala. Even the Java community is pushing Java7 in a direction with richer features, except the language is beginning to get in the way. Generics are not implemented too well, closures are likely to complicate matters further.

stephenjudkins 16y ago

Java is deliberately not programmer-orientated. That's the point of using it — it was designed to restrict the kind of trouble programmers can get themselves into. If you're stuck with the JVM, I guess the question is: how much rope do you want to give your programmers? Scala is essentially the opposite answer to Java. This was an interesting read but I disagree with this assertion. Java's lack of power as a language hasn't meant that people haven't written huge, complex, unmaintainable messes with it. Indeed, I think all the crazy dependency injection frameworks, configuration-by-XML, and other general insanity is due in part to the language's lack of power. Things that are simple in other languages (say, dependency injection, which can be replaced with runtime stubbing in Ruby or mixing in traits in Scala) often require painful and complicated ad-hoc solutions in Java. That said, it is possible to write code in Scala that requires a PhD in category theory to understand (see Scalaz), but there are also many examples of simple, functional, easy to understand code (see stuff that has come out of Twitter, like Kestrel or Nagatti). I think in practice, working with the modern Java ecosystem gives one at least as much rope to hang oneself as using Scala does.

billmcneale 16y ago
Scala's traits come nowhere near the functionalities offered by dependency injection frameworks such as Guice. When Scala encounters the need for DI, it's very likely that it will roll out a framework that will look a lot like Guice. Your point regarding the rope is well taken, the difference being that with Java, the rope lies in the frameworks, while in Scala, it lies both in the frameworks (take a look at Lift) and in the language.
- stephenjudkins 16y ago
  Well, for a big enough project something like Guice will become necessary sooner or later. However, for smaller programs traits are simpler to use and get one 80% of Guice's functionality--and it's all built into the language. Traits are relatively easy to understand that any reasonably competent developer should be able to easily reason about. I don't see why a Scala-native DI framework wouldn't be able to leverage this existing, simple solution to build the last 20%. Guice is the result of smart Google engineers who had probably tried all sorts of DI frameworks before and finally developed something nice. It's the result of more than a decade of painful experiences with existing solutions to a real problem. In conclusion, I think you can hang yourself when using any language. In Scala, when I needed to mock out a dependency for a project, I settled on a fairly simple trait-based approach that was simple and elegant. In Java, I could have rolled by own Factory scheme that would be ugly and unmaintainable, or picked a DI framework that hopefully wouldn't have sucked. In this case I was presented with many fewer opportunities to make a mess than if I had been using Java. (BTW, you can use Guice in Scala programs right now! And, when you do, it looks way nicer and easier to use than in Java. See http://makeapp.blogspot.com/2009/09/how-to-use-guice-with-scala-and-java.html http://makeapp.blogspot.com/2009/09/how-to-use-guice-with-sc...)

narrator 16y ago

Scala is actually a better Ruby. All the messy fun stuff that we all love with Ruby like duck typing and monkey patching can be done easily with Scala, except it's all statically typed so it keeps the whole mess under control. For instance, you can have a duck type as a function argument that's contract is it implements a particular method signature. In Ruby there is no type type enforcement so you can get runtime errors when you pass in an object that doesn't have the right method, while in Scala the compiler catches it. You can monkey patch by doing implicit conversions in Scala to a rich type, allowing one to add methods to the Integer class, for example, but if you have to libraries that do the same monkey patch Scala will alert you to ambiguous situations. In Ruby this depends on load order and can cause all kinds of screwy bugs.

cageface 16y ago
Scala is brilliant in a way in that it hides all the incredible complexity you incur when you try to statically type a programming style evolved in dynamic languages. That is, it hides it to a point. It's easy enough to get started writing simple scripts and sprucing up old Java code but before long you get a compiler error that sends you scurrying away to the reference books and then it hits you that you really are going to have to come to grips with the type system and it's a doozy. I'm still not persuaded that all the gymnastics Scala has to do to allow Ruby-like flexibility really result in a more productive language overall. I need to spend more time with it to be sure but at first blush it really feels like the faustian bargain Scala has had to strike to merge expressive, Ruby-like syntax with strong, static type-checking and java compatibility has resulted in a language too complex for most working programmers. Clojure seems a lot more elegant and comprehensible.
- narrator 16y ago
  When I get a compiler error in Scala it's almost always something that would cause a runtime error in a non statically typed language. The downside is that the error messages can be difficult to parse and resolve for beginners. Once I got over the learning curve, I realized that in almost all cases the compiler was trying to tell me something very useful. I do get a little annoyed at all the Haskell/OCaml type nerds trying to do things with the type system that are not particularly practical, for instance: http://apocalisp.wordpress.com/2010/06/16/type-level-programming-in-scala-part-4a-peano-number-basics/ http://apocalisp.wordpress.com/2010/06/16/type-level-program...

Parabola 16y ago

Features should be looked at individually to determine whether their expressive power is worth their potential for abuse, and also what the alternative would be for the use cases for that feature if the feature was not provided. Java refuses to do this and has barely evolved in a decade to the monstrous ecosystem of hacks it is now. Scala throws in the kitchen sink and manages to work things out pretty well. I think this means that the fine line isn't quite where we thought it was. But it's still there and Scala should be careful.

mhd 16y ago

It's not just a better Java, if you ask me. Scala, like Clojure, aren't really pure Java replacements, fixing some of the bugs and awkward syntax details. Both try to steer the programmer towards different ways of programming. They're better, and more. As I'm currently taking a look at Android development, I wish there was a simply "better Java". Something that doesn't stray too much from imperative C/Algol/Pascal-like programming, but doesn't require me to use a huge, bloated IDE just to cope with the language features. Better variable declaration, better modules, uniform access principle etc. Fantom looks interesting but -- again -- tries to be more than that (own library, multi-VM etc.).

dman 16y ago

Can any of the scala folks point me to a good introduction of the language ?

samdk 16y ago
Before you jump into Scala I'd recommend being familiar with Java and (at the least) being comfortable with the basics of an ML-like language or Haskell. Having had experience with a scripting language like Ruby or Python helps too. Knowing Java, Haskell, Ruby, and Python already, I found it really easy to jump into Scala with the references listed on the Scala site. If you do have experience with Java/statically-typed FP (or if you're just feeling brave) that's where I'd recommend looking.
bitsai 16y ago
Daniel Spiewak has written a fair number of Scala articles, and I've found them to be quite helpful: http://www.codecommit.com/blog/category/scala/page/10 http://www.codecommit.com/blog/category/scala/page/10

guelo 16y ago

Java beats Scala, and many other languages, in readability and maintainability. Java has a lot of best-practice conventions developed over many years of pain on how to make the code as readable as possible. The functional languages need these guidelines even more than Java does, but they seem to lack them. It's really easy to write insanely convoluted unreadable code in Scala.

kunjaan 16y ago
"Java beats Scala, and many other languages, in readability and maintainability." I have to respectfully disagree with this statement.
- guelo 16y ago
  You have to respectfully state your argument or your comment is useless.
TeHCrAzY 16y ago
"It's really easy to write insanely convoluted unreadable code in Scala." It's really easy to write insanely convoluted and unreadable code in any language. The language isn't really the factor there, more the programmer.
- guelo 16y ago
  That's why I said conventions. Java has many years in this area. There is nothing like Joshua Bloch's "Effective Java" for Scala.
  - TeHCrAzY 16y ago
    You are missing my point: that the language isn't the key part here, its the programmer. If a programmer doesn't adhere to some sane formating and code structure, it won't matter what language they write in, the result will be spaghetti.
    - 16y ago

andybak 16y ago

I mainly know OO through Python. I had a Java programmer try and explain why Dependency Injection frameworks were great and I went off and googled around and there are a few for Python. I still can't grok why I'd need one though. Is DI for Python the product of damaged minds or do they provide some real benefit?

JulianMorrison 16y ago
Even in Python, you benefit from structuring an object to accept its dependencies as inputs, rather than calling to them by their global names. It lets you test each class independently with mock objects that support the same interface.
- andybak 16y ago
  By writing XML config files? (or is that just a Struts wart rather than an intrinsic part of DI?) Anyway - if mocking for tests is the major benefit of DI then there some other simpler ways to that. Everything I've read on DI makes it sound like a fairly complex beast.