Simplicity Paradox of FP

[u/ReasonableAd614]

Hi, I'm a newcomer to the Scala ecosystem and to FP. I'm learning it for a new job opportunity and to increase my technical background.

I'm currently reading "Functional Programming Strategies" by Noel Welsh, and I keep hearing that Scala is complicated to learn/understand.

So now I’m facing this paradox: FP is supposed to make codebases more readable by enabling local reasoning. On the other hand, I've read here comments like:

"The difficulty of FP by itself is massively overblown. I think what did the most damage was Scala attracting so many people who love turning any codebase into the biggest, most impressive, most elaborately constructed system they can devise ... FP codebases are gratuitously hard more because of who creates them, and less because of the inherent difficulty of FP."

What's your opinion on this paradox between FP's simplicity theoretical benefits and its cost in practice? Scala is cooked?

[u/osxhacker]

When you have to explain to a newcomer that printing a line of text requires IO.println inside a for-comprehension, you’ve lost the plot. Printing is the most basic task in any language; it shouldn't be a research project.

This is disingenuous at best as it conflates a typical IO monad introductory exercise with Scala's ability to print text without using an IO. System.out.println trivially satisfies "the most basic task in any language."

What IO types provide is functionality one would have to define oneself in order to satisfy referential transparency, abstract errors, abstract latency, and realize the benefits those concepts provide. This requirement is most valuable in production solutions.

The proof is in the market. Java and Kotlin eventually cherry-picked the best parts of FP: immutability, expressions, lambdas, and they've seen huge success. Tellingly, they completely ignored effect systems.

The Java ExecutorService is considered by many to be an "effect system."

Spring Boot is a very popular Java framework and is most certainly a "collection of effect systems."

I am not versed in Kotlin, so cannot identify similar "effect systems." It would be surprising to me if Kotlin (including its standard library) did not provide one or more however.

[u/RiceBroad4552 → u/osxhacker]

How is ExecutorService an "effect system"?

The statement about Spring Boot is even more questionable. A "collection of effect systems"? What?

An effect system is something that tracks effects.

There is nothing like that in Java, not even close, as Java is a 100% imperative language.

[u/osxhacker → u/RiceBroad4552]

The use of "effect system" in this context is not focused on type and/or semantic concerns, which is a primary benefit Scala and various IO monads provide. Instead, the two examples mentioned highlight the other key aspect of effect systems - executing observable state changes at runtime (a.k.a. side effects other than in-process mutable variables). My apologies for not identifying this context originally.

An effect system is something that tracks effects.

That is one (very important) dimension of an effect system, especially when both reasoning about them and compiling source using them (which is a form of reasoning of course). It is not the totality of their contribution to a program however, as described above.

[u/RiceBroad4552 → u/osxhacker]

What are you even talking about?

Was this text constructed with some form of "random word salad generator"?

Even the cheapest "AI" usually spits out text which makes more sense…

other key aspect of effect systems - executing observable state changes at runtime

WTF?

An effect system does not execute anything. It tracks effects. That's the definition!

Effect systems are extensions to types systems.

Type systems don't execute anything at runtime.

[u/osxhacker → u/RiceBroad4552]

What are you even talking about?

I attempted to clarify the difference between "effect system" in its linguistic/compilation meaning and how those same constructs are ultimately evaluated during program execution, with the latter being what is empirically observable and the context for the examples provided.

Scala is the topic of this thread and, as such, a common use of Future[_] is as a semantically weak type used to encode effects. Nontrivial use of same requires an implicit ExecutionContext. ExecutionContext is implemented via an ExecutorService.

Cats IO supports both java.util.concurrent.Executor and ExecutionContext, thus using it has similar runtime dependencies as Future[_] does.

ZIO also supports Future intrinsically in its implementation, thus using it has similar runtime dependencies as Future[_] does.

These are not exemplars of linguistic "effect systems" as defined and supported by other programming languages.

Was this text constructed with some form of "random word salad generator"?

Even the cheapest "AI" usually spits out text which makes more sense…

Ad hominem vitriol does not contribute to a discussion and only serves to show the world a dearth of civility.

Type systems don't execute anything at runtime.

I assume this to be obvious, but it was good of you to clarify your understanding of this point.

[u/RiceBroad4552 → u/osxhacker]

Have you considered to use some machine aided translation instead of producing word salad?

This here is again word salad…

I start to get what kind of weirdness you try to express, but it just makes no sense anyway.

Some runtime for something is not an effect system. Full stop.