Hacker News Reader

Comment by grumpyprole | Hacker News Reader

> it's just an implementation detail than doesn't make the language more or less functional.

It affects the language very much, awkward currying and tupling, needing to wrap methods in objects. Subtyping also has many complex consequences. There is limited type inference and tail call optimisation versus functional-first languages.

> Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml.

It offers higher-kinded types, but F# has units of measure, OCaml has polymorphic variants. Each has advanced features not offered by the other.

> The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.

It was not designed as a functional programming language first and foremost, that is my point.

View on HN

> It affects the language very much, awkward currying and tupling, needing to wrap methods in objects.

That is a lot less true since Scala 3.

> Subtyping also has many complex consequences.

Sure. But it also means I can use any library from the Java ecosystem, and that's a huge reason behind the big number of Scala jobs compared to other FP languages.

> There is limited type inference and tail call optimisation versus functional-first languages.

Limited type inference is typically what I (and my team) want, for the sake of self-documentation. Scala's type inference is plenty enough, and the few corner cases that were annoying in Scala 2 should be fixed in Scala 3.

Tail-call optimization is done the compiler. The lack of tail-call elimination is bothering the few maintainers of functional libraries that need to implement CPS and trampolines, but not really something the average developer will have to worry about. And it should come to the JVM with Loom, eventually.

> F# has units of measure

Scala offers more generic ways to do the same thing. Would F# need such a feature at the language-level if it had typeclasses?

> OCaml has polymorphic variants

I believe most people don't want structural typing in their GADTs.

> It was not designed as a functional programming language first and foremost, that is my point.

I don't think Martin Odersky would agree. It's not an either/or situation. Scala was designed to be a full-fledged functional language, and OO hybrid, compatible with (and leveraging) the Java OO model, and offering a strong type system that goes beyond what you find in most FP languages.

> awkward currying

Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.

> Subtyping also has many complex consequences

But also substantial benefits!

> There is limited type inference

I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.

> tail call optimisation

This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).

> F# has units of measure

I dearly miss those. Type Providers even more so.

> OCaml has polymorphic variants

Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.

> It was not designed as a functional programming language first and foremost

This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.

More languages are becoming more and more like Scala, btw.

https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...

And the concept of a programming language paradigm is fake from the start anyway ;)

https://www.cambridgeblog.org/2017/05/what-if-anything-is-a-...

> This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary,

Possibly misleading yes, it is certainly a subjective point. I guess it reflects the struggle I had doing FP in Scala versus alternatives. I don't think I'm alone either, the Haskell community contains a lot of Scala refugees. Note that I have not looked at Scala 3.

> doing FP in Scala versus alternatives

I think Scala is the language most actual functional programming on this planet takes place these days. Be it just FP or pure FP.

I especially like pure FP in Scala. One can do that with Cats Effect (from the TypeLevel family of languages) or ZIO. They're both awesome, so check them out and pick what you'll like best.

https://typelevel.org/cats-effect/

https://zio.dev/

You don't even need to reach out to Scala 3 (still not as mature in its tooling support), you can have a great time with the latest Scala 2 (2.13).

> versus alternatives

I think of Scala as a opinionated take on ML and a module system that is tailored to JVM (and is seamlessly interoperable with Java) that just happens to have syntax heavy on braces/parentheses. Otherwise, what's not to like? :)

I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.

I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route.

I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!

> I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.

Then how do you explain that a very significant number of "top" tech companies have teams who manage to deliver products written in Scala or other FP languages?

Teams have managed to deliver products in also sorts of languages, Cobol for example. Did the choice of language benefit the delivery, maintenance and TCO is my question. If I choose Haskell/Scala over Java (FYI as a programmer I'm not a fan of Java) what benefit will it actually bring the business, and does it out weight the negatives, over what time frame and how much risk?

There are technical tradeoffs everywhere. But you cannot make a caricature of FP developers, supposedly not willing to spend energy on delivering products.

Lots of tech companies have proved that you don't need to follow Google and constrain your workforce to a small list of vetted languages. Most teams who chose Haskell, OCaml, Scala, Rust... are productive and able to deliver products.

But my point is does moving to FP, which is the direction of change, actually bring any benefits to the actual outcome?

My question is simple as that, yet as engineers we get lost in the detail of the doing and some hand wavy suggestion that it makes things better, yet where is the actual evidence for this?

Be pro FP or not, or any other programming paradigm, lets say logic based (prolog etc), where is there any measures on how it benefits outcome.

I appreciate this isn't something that can be easily measured, but that is arguably a key problem with the state of the industry, that its emotion, intuition and bandwagon driven.

> There are technical tradeoffs everywhere. But you cannot make a caricature of FP developers, supposedly not willing to spend energy on delivering products.

That is my personal experience, a tiny data point, again where are the studies that give some actual useful guidance?

I wrote a great project using Racket, everyone should use Racket, its cool, lets blog it ... gains momentum, its new its exciting it promises change ... people start to have different experiance, bad decisions are made ... new bandwagon, lets all rush to that yay. Having been around for long enough to see this cycle, I think it's right to ask for some well thought evidence, or gathering of trade offs to help decision making.

> scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery

This feels to me like a low effort and vague criticism.

Essentially, this is a complaint about an arbitrary group of developers that they're playing around with tech (whatever that tech might be) instead of delivering...

Obviously, in this case you can't say that specific thing about Python/JS/PHP/whatever developers, because "monads and type theory" just don't apply in these languages. (I know Python has MyPy, but let's put that aside for the simplicity of the argument.)

But for some non-scala/functional engineers, somebody could complain that they're wasting time playing with GUI frameworks, testing frameworks, async libraries, whatever...

The truth is, people can clown around with any technology, just as people can deliver with Scala/FP or something else.

Reply on news.ycombinator.com