3 ms·

If you buy into object-functional, combining ADTs and inheritance as Scala does is quite reasonable. It will be interesting to see what Scala is like in a coup

If you buy into object-functional, combining ADTs and inheritance as Scala does is quite reasonable. It will be interesting to see what Scala is like in a couple of years. I think (hope) many of the issues will be resolved. Just going over the list you give: - Implicits are useful. Implicit conversions, the evil part of implicits, are mostly going away via deprecation and other mechanisms. - Structural types might go away if higher kinds are curried, or there is syntax for partially applying a higher kind. - Dynamics. Who uses this? Why was it even added? I'd nuke it in a second but I don't know of any plans to remove it. - Macros aren't even officially in the language yet, so it's a bit early to call for their removal :) Ultimately is comes down to implementations. The idea of statically typed FP inspired languages has been around forever, but the implementations just haven't been up to scratch. Where are the alternatives to Scala (that is, statically typed, run on the JVM)? Things like Kotlin etc. are still in development and don't really offer much over Java. It might be in 5 years that Rust has a sufficient ecosystem to make it a viable alternative to the JVM. I think a lot of big data systems (in the area of Cassandra / Kafka / Hadoop) projects would happily move over to Rust, just to avoid GC issues. Haskell is the other alternative with traction, but it's an even further leap for most developers so I'm not convinced.

pron 12y ago
I prefer a much more pragmatic approach. From where I stand, statically-typed FP languages like Haskell are very interesting but are still in the research stage. We don't even know that that's a direction worth adopting in mainstream languages. Some ideas (pattern matching) are easy to understand, but others? Personally, I think static types going beyond those offered by Java could be very beneficial, but I'm not convinced that the type systems used by Haskell or Scala are the way to go. We do know that FP does allow for more general abstractions, but those usually come at a cost. They are harder for people to understand, and frankly, haven't been proven to increase code quality and maintainability. Yes, they're elegant like mathematical equations, but equations don't need to be changed and maintained by large teams of people over many years. A language like Haskell gives you more tools to think of your program ahead of time at the expense of thinking about it when it runs (with a debugger, profiler etc.), and I'm not sure that's the tradeoff the industry should make. Math is a great tool, but I'd learn how to catch a ball a lot faster by trial and error, then by learning how to rigorously compute its trajectory. I think people in the industry should wait for more evidence of the utility of the more advanced FP concepts before rushing to adopt them. Of course, that doesn't mean people should be working on novel approaches and trying them. But my problem with Scala is that it is really a research language that tries different unproven approaches (and that answers pretty much all your questions about why certain features were ever included -- that and the non discriminating taste of its designers). But it's dangerous because it tricks people into thinking it's something else.
frowaway001 12y ago
Just ignore him, he's a troll. The worst thing about Scala seems to be that the community always have to deal with a single nutjob on Jihad, first Harrop, then Colebourne, then Beust, now that guy.

pron 12y ago

I prefer a much more pragmatic approach. From where I stand, statically-typed FP languages like Haskell are very interesting but are still in the research stage. We don't even know that that's a direction worth adopting in mainstream languages. Some ideas (pattern matching) are easy to understand, but others? Personally, I think static types going beyond those offered by Java could be very beneficial, but I'm not convinced that the type systems used by Haskell or Scala are the way to go. We do know that FP does allow for more general abstractions, but those usually come at a cost. They are harder for people to understand, and frankly, haven't been proven to increase code quality and maintainability. Yes, they're elegant like mathematical equations, but equations don't need to be changed and maintained by large teams of people over many years. A language like Haskell gives you more tools to think of your program ahead of time at the expense of thinking about it when it runs (with a debugger, profiler etc.), and I'm not sure that's the tradeoff the industry should make. Math is a great tool, but I'd learn how to catch a ball a lot faster by trial and error, then by learning how to rigorously compute its trajectory. I think people in the industry should wait for more evidence of the utility of the more advanced FP concepts before rushing to adopt them. Of course, that doesn't mean people should be working on novel approaches and trying them. But my problem with Scala is that it is really a research language that tries different unproven approaches (and that answers pretty much all your questions about why certain features were ever included -- that and the non discriminating taste of its designers). But it's dangerous because it tricks people into thinking it's something else.

frowaway001 12y ago

Just ignore him, he's a troll. The worst thing about Scala seems to be that the community always have to deal with a single nutjob on Jihad, first Harrop, then Colebourne, then Beust, now that guy.