4 ms·

As someone who is currently having to deal with a monolithic Java app built on spring, hibernate, aspect weaving, code drenched in null checks, and other questi

by sreque 10y ago

As someone who is currently having to deal with a monolithic Java app built on spring, hibernate, aspect weaving, code drenched in null checks, and other questionable architecture choices, this article makes me want to switch to Scala, and the reasons are mainly community, not programming language. I think you could do a lot of the above In Java although the code would be a little boiler-platey. But why do people care about boiler plate so much? Hasn't GoLang shown us that boilerplate is not our greatest enemy?

paulddraper 10y ago
The nice thing is that you can choose the language and "community" independently. Scala with Spring or Java with Play. You can usually mix and match Java and Scala source code easily. Kind of like C and C++.
- dsacco 10y ago
  This has not been my experience in practice, but it has been my experience that people say this can be done theoretically. I worked at a company where most of the backend was in Java and Scala. There was this platonic ideal of Scala for the usually stated reasons, but what actually happened was weird, half-implemented Scala with Java that was necessary to take it the rest of the way on pretty much every microservice. It never really felt like Scala stood on its own weight without requiring 20% of the solution in Java. That bifurcation ended up making the maintenance sort of a pain. I don't currently work with Scala (sometimes Java), but I would be interested in hearing some tips from you on how to make Scala more of a first class citizen and stand on its own weight.
  - paulddraper 10y ago
    Well, my practical experience is that writing in Scala is so much more enjoyable, it eventually becomes 100% Scala.
dustingetz 10y ago
It's not the boilerplate. When you take some of the best java developers on the planet, after a couple years you end up with a AbstractSingletonProxyFactoryBean, so what is a mere mortal supposed to end up with? Evolve any Java codebase for N years and the result is the same. http://docs.spring.io/spring-framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring-framework/docs/2.5.x/api/org/sp... You could also make a similar argument for Scala. Not boilerplate, but other problems. There are some epic scala flamewars out there. A mortal could be forgiven for looking at an "idiomatic" scala codebase and scratching their head, looking at all this higher order "stuff" and wondering, "but where is the actual code, that does the actual thing?" And I'm not sure there exists a human on the planet who knows what idiomatic scala is. The whole point of the language was to make some impossible compromises, and as such you can kind of feel forces inside the language in tension with itself, not in alignment. Perhaps FP and OOP are not meant to be unified.
- pdpi 10y ago
  > Perhaps FP and OOP are not meant to be unified. The only thing that keeps FP and OOP from integrating properly is the "Everything is an Object" mentality. Pure-data structs aren't objects, and you start making loads of weird compromises when you force them into an object-shaped hole. Java (and, I guess, C++) kind of pushes classes as better structs, and lots of bizarre problems come from there. I find that, when I'm programming in the small, on the lower-level implementation details, FP design principles serve me best. Inversely, when thinking about the structure of my applications, OOP principles suit the problem better. This sort of design is what leads some people to say that Erlang is the most OOP language out there — Erlang processes map very naturally to objects in this sense, and it is, obviously, a functional language through-and-through.
  - mafribe 10y ago
    The only thing that keeps FP and OOP from integrating properly is the "Everything is an Object" mentality. Actually ... in Scala everything is an object. Functions are special cases of objects. That's Scala's great insight and it reverses what people used to think: everything is a function, and OOP is a special case of FP (this is e.g. OCaml's idea). If you look at Scala's foundations (DOT -- the dependent object calculus) this becomes pretty clear. Could you be referring to the difference between pure programming and stateful programming? Note that OO can be done in a pure way.

by sreque 10y ago

paulddraper 10y ago

The nice thing is that you can choose the language and "community" independently. Scala with Spring or Java with Play. You can usually mix and match Java and Scala source code easily. Kind of like C and C++.

dsacco 10y ago
This has not been my experience in practice, but it has been my experience that people say this can be done theoretically. I worked at a company where most of the backend was in Java and Scala. There was this platonic ideal of Scala for the usually stated reasons, but what actually happened was weird, half-implemented Scala with Java that was necessary to take it the rest of the way on pretty much every microservice. It never really felt like Scala stood on its own weight without requiring 20% of the solution in Java. That bifurcation ended up making the maintenance sort of a pain. I don't currently work with Scala (sometimes Java), but I would be interested in hearing some tips from you on how to make Scala more of a first class citizen and stand on its own weight.
- paulddraper 10y ago
  Well, my practical experience is that writing in Scala is so much more enjoyable, it eventually becomes 100% Scala.

dustingetz 10y ago

It's not the boilerplate. When you take some of the best java developers on the planet, after a couple years you end up with a AbstractSingletonProxyFactoryBean, so what is a mere mortal supposed to end up with? Evolve any Java codebase for N years and the result is the same. http://docs.spring.io/spring-framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring-framework/docs/2.5.x/api/org/sp... You could also make a similar argument for Scala. Not boilerplate, but other problems. There are some epic scala flamewars out there. A mortal could be forgiven for looking at an "idiomatic" scala codebase and scratching their head, looking at all this higher order "stuff" and wondering, "but where is the actual code, that does the actual thing?" And I'm not sure there exists a human on the planet who knows what idiomatic scala is. The whole point of the language was to make some impossible compromises, and as such you can kind of feel forces inside the language in tension with itself, not in alignment. Perhaps FP and OOP are not meant to be unified.

pdpi 10y ago
> Perhaps FP and OOP are not meant to be unified. The only thing that keeps FP and OOP from integrating properly is the "Everything is an Object" mentality. Pure-data structs aren't objects, and you start making loads of weird compromises when you force them into an object-shaped hole. Java (and, I guess, C++) kind of pushes classes as better structs, and lots of bizarre problems come from there. I find that, when I'm programming in the small, on the lower-level implementation details, FP design principles serve me best. Inversely, when thinking about the structure of my applications, OOP principles suit the problem better. This sort of design is what leads some people to say that Erlang is the most OOP language out there — Erlang processes map very naturally to objects in this sense, and it is, obviously, a functional language through-and-through.
- mafribe 10y ago
  The only thing that keeps FP and OOP from integrating properly is the "Everything is an Object" mentality. Actually ... in Scala everything is an object. Functions are special cases of objects. That's Scala's great insight and it reverses what people used to think: everything is a function, and OOP is a special case of FP (this is e.g. OCaml's idea). If you look at Scala's foundations (DOT -- the dependent object calculus) this becomes pretty clear. Could you be referring to the difference between pure programming and stateful programming? Note that OO can be done in a pure way.