5 ms·

I like Scala, but it's still got mutable state, for loops, and lots of other imperative trappings. It's got some functional features, but I don't consider it to

I like Scala, but it's still got mutable state, for loops, and lots of other imperative trappings. It's got some functional features, but I don't consider it to be a functional language (IMHO). If Scala is functional, then so are Ruby, JavaScript, and a host of other languages with higher order functions and the ability to be immutable, so long as you make the effort to not mutate anything (though anything is immutable by that logic). That doesn't make Scala bad. I actually enjoy writing it most days, but I think it's not quite accurate to call it a functional programming language. For that matter, even Clojure has enough imperative parts that I don't consider it to be functional. Maybe I'm just overly strict in my definitions. Anyway, Elixir qualifies, but isn't heavily used. I hope that changes some day, because it's a beautiful language. It manages to be principled about being functional, while also having an easy learning curve, and rock solid dependability. I want to see Elixir grow, because a language this good deserves to be popular. According to the Red Monk rankings, Haskell is close to Scala in usage. The learning curve is much higher, but I love writing it. I love the clean, simple code that Haskell pushes me towards, and it usually does the right thing the first time I run it. It seems to be gaining traction lately, and Stack has me excited about the possibility of things ramping up even further.

Aqueous 11y ago
While I agree that the ability to fall back on stateful imperative code makes it not a pure functional language, once you get into an immutable pattern it becomes less and less convenient or desirable to fall back on mutable data structures. I can't remember the last time I was even tempted to make something mutable. Also, in my experience it's required very little effort to convince new hires that are new to Scala to adopt this pattern.
runT1ME 11y ago
I'm not sure how familiar you are with scala if you are equating them in equal 'functional power' to Ruby and Javascript. Have you read Functional Programming in Scala? The fact that the language supports immutable records out of the box, type classes, monadic comprehension all make it much more pleasant to deal with the realities of immutable data. You can write immutable java, but the language doesn't make it easy to at all. Look at the hilariously bad builder pattern (which is as good as it gets in Java) compared to the right way of doing things in Scala.
- willtim 11y ago
  Sadly I'm sceptical that the JVM can support practical and efficient use of functional structures such as monads. I hope this will change.
- jbooth 11y ago
  What's Scala's superior alternative to builder patterns? You can have lots of final members in a constructor in Java, too..
  - runT1ME 11y ago
    State monad and/or lenses when appropriate, which is made quite pleasant to use with for comprehension's syntactic sugar.
    - jbooth 11y ago
      You mind pasting an example? I typically find higher kinded types, monads etc to be more of a pain than the problems they're solving (builders & constructors not really that painful IMO), but am really trying to keep an open mind.
      - yummyfajitas 11y ago
        Sure, here's an example with lenses, taken from actual code I've written: (for { _ <- EventLenses.duid := UserDuid("12345") _ <- EventLenses.contexts := Seq(EventContext.NilContext) _ <- EventLenses.url := "http://news.ycombinator.com" } yield ()).run(originalEvent) This code will take an event, set it's duid, contexts and url. If you squint hard enough it almost looks like: originalEvent.duid = ... originalEvent.contexts = ... originalEvent.url = ... The thing that's cool about lenses is that they compose nicely. E.g., the contexts lens is defined as: val contexts: Lens[Event, Seq[EventContext]] = query >=> getterMLens("cx") >=> Lens.lensu(...) This means that first we take the query lens, compose it with a lens that gets the "cx" parameter, then do the actual work of decoding the "cx" param.
nevergo 11y ago
> I like Scala, but it's still got mutable state, for loops, and lots of other imperative trappings. It's got some functional features, but I don't consider it to be a functional language (IMHO). If Scala is functional, then so are Ruby, JavaScript, and a host of other languages with higher order functions and the ability to be immutable, so long as you make the effort to not mutate anything (though anything is immutable by that logic). That doesn't make Scala bad. I actually enjoy writing it most days, but I think it's not quite accurate to call it a functional programming language. Immutability != FP And "It's got some functional features..." isn't fair to say because other FP languages contain lesser features compared to Scala - which is an other thing. > According to the Red Monk rankings, Haskell is close to Scala in usage. The learning curve is much higher, but I love writing it. I love the clean, simple code that Haskell pushes me towards, and it usually does the right thing the first time I run it. It seems to be gaining traction lately, and Stack has me excited about the possibility of things ramping up even further. Haskell would be good if it could handle state and some basic features for code reusage - so we could create uis and everyday stuff seemlessly. But the real-real-world haskell code is beyond ugliness. It's nice when you start with it - creating fibonacci, Monad, little game loops etc. But when you want to create something...

Aqueous 11y ago

While I agree that the ability to fall back on stateful imperative code makes it not a pure functional language, once you get into an immutable pattern it becomes less and less convenient or desirable to fall back on mutable data structures. I can't remember the last time I was even tempted to make something mutable. Also, in my experience it's required very little effort to convince new hires that are new to Scala to adopt this pattern.

runT1ME 11y ago

I'm not sure how familiar you are with scala if you are equating them in equal 'functional power' to Ruby and Javascript. Have you read Functional Programming in Scala? The fact that the language supports immutable records out of the box, type classes, monadic comprehension all make it much more pleasant to deal with the realities of immutable data. You can write immutable java, but the language doesn't make it easy to at all. Look at the hilariously bad builder pattern (which is as good as it gets in Java) compared to the right way of doing things in Scala.

willtim 11y ago
Sadly I'm sceptical that the JVM can support practical and efficient use of functional structures such as monads. I hope this will change.
jbooth 11y ago
What's Scala's superior alternative to builder patterns? You can have lots of final members in a constructor in Java, too..
- runT1ME 11y ago
  State monad and/or lenses when appropriate, which is made quite pleasant to use with for comprehension's syntactic sugar.
  - jbooth 11y ago
    You mind pasting an example? I typically find higher kinded types, monads etc to be more of a pain than the problems they're solving (builders & constructors not really that painful IMO), but am really trying to keep an open mind.
    - yummyfajitas 11y ago
      Sure, here's an example with lenses, taken from actual code I've written: (for { _ <- EventLenses.duid := UserDuid("12345") _ <- EventLenses.contexts := Seq(EventContext.NilContext) _ <- EventLenses.url := "http://news.ycombinator.com" } yield ()).run(originalEvent) This code will take an event, set it's duid, contexts and url. If you squint hard enough it almost looks like: originalEvent.duid = ... originalEvent.contexts = ... originalEvent.url = ... The thing that's cool about lenses is that they compose nicely. E.g., the contexts lens is defined as: val contexts: Lens[Event, Seq[EventContext]] = query >=> getterMLens("cx") >=> Lens.lensu(...) This means that first we take the query lens, compose it with a lens that gets the "cx" parameter, then do the actual work of decoding the "cx" param.

nevergo 11y ago

> I like Scala, but it's still got mutable state, for loops, and lots of other imperative trappings. It's got some functional features, but I don't consider it to be a functional language (IMHO). If Scala is functional, then so are Ruby, JavaScript, and a host of other languages with higher order functions and the ability to be immutable, so long as you make the effort to not mutate anything (though anything is immutable by that logic). That doesn't make Scala bad. I actually enjoy writing it most days, but I think it's not quite accurate to call it a functional programming language. Immutability != FP And "It's got some functional features..." isn't fair to say because other FP languages contain lesser features compared to Scala - which is an other thing. > According to the Red Monk rankings, Haskell is close to Scala in usage. The learning curve is much higher, but I love writing it. I love the clean, simple code that Haskell pushes me towards, and it usually does the right thing the first time I run it. It seems to be gaining traction lately, and Stack has me excited about the possibility of things ramping up even further. Haskell would be good if it could handle state and some basic features for code reusage - so we could create uis and everyday stuff seemlessly. But the real-real-world haskell code is beyond ugliness. It's nice when you start with it - creating fibonacci, Monad, little game loops etc. But when you want to create something...