3 ms·

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

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.
sreque 10y ago
The problem here is that "best java developers" really aren't that good. And why is that the case? Is it the community's fault? The language's? I think it can be seen as both to some extent. The mentality and philosophy of a PL community in my opinion can be heavily influenced by the programming language itself. I think you can design and build perfectly fine software in Java, but the problem to solve is education of software developers. Most software developers can't be bothered to learn basic PL theory or deeply learn multiple programming languages that are very different from each other. As such, when they think about how to solve problems in code, their thoughts are heavily influenced by their primary language. In this case, what we see from the "best" java developers is the kind of coding you can expect if the only language you ever learn is Java. A more extreme case of this is Perl. Some of the most crazy, convoluted, unnecessarily complex code I've ever seen comes from the Perl community. Now, you can write somewhat normal code in Perl, but the community often doesn't, and the language itself certainly doesn't encourage it. As to your concern that FP and OOP can't be unified, I don't see this as Scala's core problem. Scala's core problem is that a vocal part of the community wants to use Scala as a worse Haskell, and the other part wants to use it as a better Java. I think Scala will be most successful if instead someone figures out the best way to design software in a Scala-specific way, and I don't think anyone has successfully done that yet, although people are certainly trying. Martin Odersky, for instance, long ago introduced the cake pattern, something that was fairly scala-specific and represented a new design pattern. Unfortunately, the cake pattern ended up being a bit of a disaster! Since then, he has pushed the idea of "modular" programming, where Scala embraces more of it's ML roots (https://pellucidanalytics.github.io/blog/scalas-modular-roots/ https://pellucidanalytics.github.io/blog/scalas-modular-root...). I haven't been following the community well enough to know if this kind of thinking ever took off further or not, or if there are other avenues of exploration currently in development. At the end of the day, Scala is a research language, except the research is more focused on: how can I take existing non-mainstream PL ideas and integrate them into a practical, production-ready language? That research, for better or worse, is still ongoing in my opinion. The only way to validate the research is to try new ideas in production environments and see what works and what doesn't.
- dustingetz 10y ago
  > The problem here is that "best java developers" really aren't that good. What kind of nonsense is this? You can't casually dismiss an entire generation of programmers who built all the systems we take for granted today.

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.

sreque 10y ago

The problem here is that "best java developers" really aren't that good. And why is that the case? Is it the community's fault? The language's? I think it can be seen as both to some extent. The mentality and philosophy of a PL community in my opinion can be heavily influenced by the programming language itself. I think you can design and build perfectly fine software in Java, but the problem to solve is education of software developers. Most software developers can't be bothered to learn basic PL theory or deeply learn multiple programming languages that are very different from each other. As such, when they think about how to solve problems in code, their thoughts are heavily influenced by their primary language. In this case, what we see from the "best" java developers is the kind of coding you can expect if the only language you ever learn is Java. A more extreme case of this is Perl. Some of the most crazy, convoluted, unnecessarily complex code I've ever seen comes from the Perl community. Now, you can write somewhat normal code in Perl, but the community often doesn't, and the language itself certainly doesn't encourage it. As to your concern that FP and OOP can't be unified, I don't see this as Scala's core problem. Scala's core problem is that a vocal part of the community wants to use Scala as a worse Haskell, and the other part wants to use it as a better Java. I think Scala will be most successful if instead someone figures out the best way to design software in a Scala-specific way, and I don't think anyone has successfully done that yet, although people are certainly trying. Martin Odersky, for instance, long ago introduced the cake pattern, something that was fairly scala-specific and represented a new design pattern. Unfortunately, the cake pattern ended up being a bit of a disaster! Since then, he has pushed the idea of "modular" programming, where Scala embraces more of it's ML roots (https://pellucidanalytics.github.io/blog/scalas-modular-roots/ https://pellucidanalytics.github.io/blog/scalas-modular-root...). I haven't been following the community well enough to know if this kind of thinking ever took off further or not, or if there are other avenues of exploration currently in development. At the end of the day, Scala is a research language, except the research is more focused on: how can I take existing non-mainstream PL ideas and integrate them into a practical, production-ready language? That research, for better or worse, is still ongoing in my opinion. The only way to validate the research is to try new ideas in production environments and see what works and what doesn't.

dustingetz 10y ago
> The problem here is that "best java developers" really aren't that good. What kind of nonsense is this? You can't casually dismiss an entire generation of programmers who built all the systems we take for granted today.