re: Is Haskell bad for FP? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I feel that when you refer to 'pure' FP you are referring to languages with a static type system which is checked on compilation. Probably language...

Purity is tied to compilation and static typing, almost by necessity. While I have no idea how a pure language that is dynamically typed would look like, it would still have e.g. explicit dependencies to make refactoring easy, whereas a language with side-effects does not.

Scheme which makes it very clear when you're performing a function which mutates a variable

Depending on how this is implemented, you might call it a linear type or monad in disguise. If side effects are explicit they're not really side effects.

Purity is tied to compilation and static typing, almost by necessity.

function addOne (x) {
  return 1 + x
}

How is this impure?

You might be able to make a pure functions, if you don't consider type errors to be side effects (which I do if they don't require explicit catching, which is unlikely in a dynamic language), but that doesn't make the entirety of the language pure.
How are you going to represent effects? As you pointed out you will need at some point. Untyped monads? A framework like TEA but error resistant?

So, you might be able to do it, but it's going to be a bit awkward at least, which is why I said "almost by necessity".

code of conduct - report abuse