Hacker News Reader

Comment by kryptiskt | Hacker News Reader

There is a reason for this, and it's not that Haskell is jumping through hoops unnecessarily. All those languages are strictly evaluated, which means that side effects are clearly localized in time and space, we know when and where they happen if we run the program. Haskell is lazy, and laziness doesn't go well together with ad-hoc side effects. Haskell evaluates expressions when the result is needed, and an expression that only side effects and doesn't return a value is never needed.

You could finagle your way around that, but the result would be something like unsafePerformIO in current Haskell, where it's hard work to ensure that it's used correctly.

View on HN

This sort of thing is where I detach from the idea that functional programming is the ultimate good as some advocates would push it: it's far too obvious that outside of narrow constraints, real hardware just isn't functional.

No where was this more apparent in my career then when I was on a team of Scala-using FP programmers who were building part of a real hardware provisioning system (and the org structure tipped in their favor) - the number of arguments about the sheer amount of things which can and definitely would go bad across hundreds of servers when you tried to do things - versus their desire to ignore these problems as infrequent so they wouldn't have to try and code the handling in a functional way (FP is terrible at logging, so even getting that done adequately was an argument).

Basically the paradigm does tend towards collapsing once the problem grows too complicated for someone to keep in their head because it actively fights the sort of procedural reasoning humans do pretty much natively in favor of dealing with abstract math which very few people are any good at.

Heh, I'm currently experiencing the exact opposite in our Scala codebases. Unhandled exceptions everywhere, null pointers left-and-right, `if(myOptionalValue.isDefined) myOptionalValue.get` all over the place, etc.

I gave an internal talk about FP approaches like .map, .flatMap, etc. (as well as `Try[T]`). Although I didn't call it "FP", I called it "type-safe error handling" (i.e. `null` and `throw e` lie about their types, and are hence not type-safe)

> FP is terrible at logging

Um, what? You can't just drop this without elaborating. I've never seen anybody have problems logging in a functional language.

They probably mean Haskell. Note: I don't know Haskell, so below is speculation.

To log you need IO. To get IO you need to provide it to the function that will do logging. And now your function has to be marked as doing IO. So now you need to thread all that IO through all your functions, and "turn you code into monadic code" (I think that's the term).

Other languages (like Erlang) don't care, and you can log whenever you want.

---

Flamewar off-topic: it looks like hardly anyone is doing any useful logging in Haskell, because if you search for "logging in Haskell" you end up in:

- highly academic discussions on "logging actions" vs "logging of computations"

- extremely convoluted solutions that turn even the simplest examples into a mess

- a couple of libraries whose entire documentation is usually "believe me we're the shit", and if they do have examples, they are an impenetrable mess of custom types and ascii art

For every other language it literally is `logger.info(something)`

Thanks, but an answer from someone that knows the language that they're talking about would be much more productive.

And here we see the damage caused by the modern OOP. People that complain about that want to replicate in Haskell the lob4j philosophy of adding logging into every interface, because with data and IO chunked everywhere inside object interfaces, you never know if you can ever repeat an execution in a development environment to verify it.

The thing is, if for some reason you really think you need to log inside a pure function, you either need an intermediate variable or your perceived needs are severely misguided.

> And here we see the damage caused by the modern OOP. People that complain about that want to replicate in Haskell the lob4j philosophy of adding logging into every interface

And here we see a person slinging unsubstantiated accusations

> if for some reason you really think you need to log inside a pure function, you either need an intermediate variable or your perceived needs are severely misguided.

Clear demonstration of "it looks like hardly anyone is doing any useful logging in Haskell".

Because, as we know, the fact that "you can repeat an execution" immediately makes your need to log anything in that execution as "misguided".

What exactly do you expect to gain by logging inside a pure function?

> the result would be something like unsafePerformIO in current Haskell, where it's hard work to ensure that it's used correctly.

Not really, unsafePerformIO has its place - just its not in typical Haskell programs.

Reply on news.ycombinator.com