4 ms·

I agree 100%. Despite Scala's hype and functional influences, it's most exciting to me simply as another option for the JVM, and another "tool in the toolbox."

by wooby 17y ago

I agree 100%. Despite Scala's hype and functional influences, it's most exciting to me simply as another option for the JVM, and another "tool in the toolbox." Assuming you consider something JVM-based an eligible tool for a job, you have a wide variety of programming languages on a common platform to pick from. While it's probably not a good idea to apply them all in a project, it's nice to know that in the future the probability of you being able to reuse code in disparate languages increases.

JulianMorrison 17y ago
Scala isn't really all that FP. Marginally more so than, say, Perl. It's more like: most of the advantages of Ruby, Java and Erlang in one place, with very extensible syntax.
- warfangle 17y ago
  Let's see: - immutable types - lambdas and closures - tail recursion optimization - first order functions ... Sounds a lot like an FPL to me!
  - jongraehl 17y ago
    Yes, but Scala is a less polished FPL than Haskell. If you're using Scala instead, it's because you love OO, want convenient global mutable state, aren't interested in the purity (read: B&D) of Haskell's effect system, or want to use Java libraries.
    - warfangle 17y ago
      Haskell has also been around 13 years longer than Scala. It's no wonder it's more polished.
- mbrubeck 17y ago
  You're not going to get "most of the advantages" of Erlang in a language that includes imperative OOP and runs on the JVM. The reliability of Erlang is built around features like: * Upgrading code while it's running. In Erlang, this works because all program state is explicitly passed as parameters to a tail-recursive main loop, so there's a clear place where one version of the code can cleanly take over the state from a previous version. This won't work in a language with singletons, and mutable objects that mix code and data. * Modularizing a program into tens or even thousands of lightweight shared-nothing processes. Erlang can do this efficiently because of key properties of the language and VM. For example, the entire language and all of its libraries use persistent or copy-on-write data structures, so that processes can share memory without sharing mutable state. This won't work in a language that's interoperating with Java libraries, and whose own data structures aren't 100% immutable.
  - jksmith 17y ago
    That's my issue with Clojure as well. A language that provides and encourages use of a foundational feature X doesn't seem ideally coherent if it depends on usability provided from (Java) libraries which are unable to make use of that feature X.

by wooby 17y ago

JulianMorrison 17y ago

Scala isn't really all that FP. Marginally more so than, say, Perl. It's more like: most of the advantages of Ruby, Java and Erlang in one place, with very extensible syntax.

warfangle 17y ago
Let's see: - immutable types - lambdas and closures - tail recursion optimization - first order functions ... Sounds a lot like an FPL to me!
- jongraehl 17y ago
  Yes, but Scala is a less polished FPL than Haskell. If you're using Scala instead, it's because you love OO, want convenient global mutable state, aren't interested in the purity (read: B&D) of Haskell's effect system, or want to use Java libraries.
  - warfangle 17y ago
    Haskell has also been around 13 years longer than Scala. It's no wonder it's more polished.
mbrubeck 17y ago
You're not going to get "most of the advantages" of Erlang in a language that includes imperative OOP and runs on the JVM. The reliability of Erlang is built around features like: * Upgrading code while it's running. In Erlang, this works because all program state is explicitly passed as parameters to a tail-recursive main loop, so there's a clear place where one version of the code can cleanly take over the state from a previous version. This won't work in a language with singletons, and mutable objects that mix code and data. * Modularizing a program into tens or even thousands of lightweight shared-nothing processes. Erlang can do this efficiently because of key properties of the language and VM. For example, the entire language and all of its libraries use persistent or copy-on-write data structures, so that processes can share memory without sharing mutable state. This won't work in a language that's interoperating with Java libraries, and whose own data structures aren't 100% immutable.
- jksmith 17y ago
  That's my issue with Clojure as well. A language that provides and encourages use of a foundational feature X doesn't seem ideally coherent if it depends on usability provided from (Java) libraries which are unable to make use of that feature X.