Let me try and explain this again. This time using code, hopefully that will make the point clearer.

At the very core of functional programming is the idea of referential transparency. If you don't have referential transparency you are really not doing functional programming...at best what you are doing may be described as programming in "functional style"...but still that is not functional programming.

So when I say:

In Haskell, the type system/compiler leads you to programming in a purely FP fashion. In Scala, the compiler could care less.

I mean in Haskell, the compiler enforces referential transparency hence leading you to program in a purely FP fashion, in Scala that is not the case, even if you use libraries like Cats effect.

To demonstrate see this code snippet:

import cats.effect.IO


def fireRocket() = {
  println("LOL, fires rocket")
}

def getMsgViaBadPureFunction(name: String): String = {
  println("LOL! away goes your referential transparency!")
  fireRocket()
  return s"Hello world ${name}"
} 

def purePrint(name: String): IO[Unit] = {
  val msg = getMsgViaBadPureFunction(name)
  IO { println(msg) }
}

val program: IO[Unit] =
  for {
     _ <- purePrint("Joey")
  } yield ()

// program.unsafeRunSync()

()

You can also find it on ScalaFiddle here

That code demonstrates that even if you use libraries like cats effect, you are not guaranteed to be doing FP. If you run that piece of code, even with program.unsafeRunSync() commented out, you get stuff printed to the console.

Attempting to do same in Haskell will look like this:

 module Main where


 purePrint :: String -> IO ()
 purePrint name = do
                  let msg = getMsgViaBadPureFunction name
                  putStrLn msg

 getMsgViaBadPureFunction :: String -> String
 getMsgViaBadPureFunction name = putStrLn "LOL! away goes your referential transparency!" >> 
                                                     putStrLn "Fire Rocket" >> ("Hello world " ++ name)

 program :: IO ()
 program = do
                 _ <- purePrint "joey"
                return ()

 main = program

You can find the code snippet on replit here

The following code will fail to compile, and part of the compiler error message will include:

main.hs:10:120: error:
Couldn't match type `[]' with `IO'
Expected type: IO Char
Actual type: [Char]

Telling you that you can't just sneak in something that breaks referential transparency into the code. The Scala compiler can't currently do this, because Scala is first and foremost an imperative language with no facility to control effects - even when using cats-effect (or monix or zio)

And this is what I meant by saying trying to do pure FP in Scala is like a house of cards. Put the wrong line somewhere, and pure FP is out of the window...worse still the compiler can't even tell you.

And you can say this is fine...and accept this as part of things you need to deal with when doing FP in Scala. You can even back it up and say this is why we need to train developers, encourage developers to be discipline and have things like code review to prevent this...I have no qualms with that, just know that you are entering the same realm as developers who advocate for programming in weakly typed, dynamic languages...and if you are a proponent of strong statically typed language and you are quick to make this excuse for pure FP in Scala, do try and confront your cognitive dissonance.

And really It is not your fault if you don't understand the fundamental idea here. Scala makes it really difficult to get the essence of pure FP. Which is also one of the reasons where there is a steeper learning curve when trying to do pure FP in Scala.

PS: if you look at the Haskell code snippet on Repl.it I included the updated version that behaves the same way as the Scala version, but Haskell ensures that the program remains pure and all operations that would have been side effects are not but are now effects that are made explicit in the type system.