[shermantanktop]

Learning a “pure” language is a lot like tripping on LSD.

The people who do it can’t stop talking about how great it was, but also can’t really explain why it was so great, and when they try it just sounds ridiculous, maybe even to them. And then they finish by saying that you should drop acid too and then you’ll understand.

[CyberDildonics]

The reality is people want what you produce when you're sober, not having fantasy hallucinations.

[mrkeen]

> also can’t really explain why it was so great

I like it when

  assertTrue (f x)  -- passes in test

means that

  assertTrue (f x)  -- passes in prod

[shermantanktop]

Is there a language where that isn’t the case?

[mrkeen]

Approximately all of them. The property is "referential transparency", and it's such a sensible thing to have that people assume they already have it (per your question).

The "test/prod" was an unnecessary detail - there's really nothing saying that f(x) will equal f(x) in most languages in most circumstances! It can return different things on repeated calls to it, it can behave differently if two threads call into it at once.

It's a major part of the reason people don't see the appeal of Haskell. They think they already have "type-safety" and "functional stuff" and "generics" and "null-safety" - but it's really not the same.

[eru]

Haskell isn't all that pure.

[ChadNauseam]

what do you mean by that? all functions in haskell are pure unless you explicitly use unsafePreformIO or similar (which is rare to ever have to do)

[eru]

They can still have side-effects like non-termination.

But I didn't mean purity in that formal sense. I meant that Haskell is plenty pragmatic in its design.

[kreetx]

To me, "pure" means referential transparency: same input, same output. So an `Int -> Int` function will return same result on same argument. So, similar to `Int -> IO Int`, the function (action) will return an Int after interacting with outside world, `IO` tracking the fact that this is the case.

[tromp]

Lambda calculus is as pure as can be, and also has terms that don't normalize. That is not considered a side effect.

A better example of impurity in Haskell for pragmatic's sake is the trace function, that can be used to print debugging information from pure functions.

[eru]

> Lambda calculus is as pure as can be, and also has terms that don't normalize. That is not considered a side effect.

Many typed lambda calculi do normalise. You can also have a look https://dhall-lang.org/ for some pragmatic that normalises.

> A better example of impurity in Haskell for pragmatic's sake is the trace function, that can be used to print debugging information from pure functions.

Well, but that's just unsafePerformIO (or unsafePerformIO-like) stuff under the hood; that was already mentioned.

[instig007]

> They can still have side-effects like non-termination.

you can still have total functions that don't finish in humanly/business reasonable amount of time.

[eru]

Yes?

Just like pure functions can use more memory than your system has. Or computing them can cause your CPU to heat up, which is surely a side-effect.

[agnishom]

It doesn't have great support for Dependent Types

[Tainnor]

what does that have to do with purity?

[agnishom]

Nothing, but arguably a language with dependent types is more Haskell than Haskell

[yazzku]

"You mean you're going to make a copy of that every time?"

[mrkeen]

Haha, can't tell if you're joking or not.

For anyone else reading - you don't need to make a copy if you know your data isn't going to change under your feet.

https://dev.to/kylec32/effective-java-make-defensive-copies-...

[yazzku]

I was half-joking. I wasn't aware Java was promoting "defensive copies" :D