Haskell has a huge catalog of libraries you can reach for, so you don’t have to reinvent the wheel. That said, the Haskell way can seem very different than what you see in most languages. As an example, IO—or anything causing a side effect—has to happen in the IO Monad. There are good reasons for this, but it takes some getting used to.
But let's say I want to print something in a deeply nested function which isn't of the return-IO-Monad-type. Now I have to convert the entire call-chain of functions into Monad style. Is there some tool to do this automatically?
For debug there is Debug.Trace which is about perfect.
For non-debug, you may be overestimating how useful it is to output from pure functions in production.
In general when you are in a situation where you need to change the Monad you're under, there's techniques and libraries for that (one way you define it once, give it a name, etc.).
The biggest pain tends to be going from pure to monadic in the first place, which last I used Haskell there wasn't much for but to just do it. There may be more tooling now, haven't seen.
Because some non-technical manager came to you and said, "Can't you just print out the value here? And can I get it in the next 15 minutes?" and it was pretty clear that "No" was not an acceptable answer.
Different things are hard or easy in Haskell compared to other languages. Mergesort would be the first one I'd reach for in Haskell if I'm implementing from scratch.
Quicksort isn't really hard, you just do it in IO and it looks about like what you'd see in any imperative language. (or you can use ST, but then you have to know about ST).
Performance. Internal representation.
You are not actually modifying things in place. Those are the equivalent of linked lists not arrays. That quicksort is not quick at all because the append operation in Haskell is linear. You can't use those lists to implement quicksort.
Haskell is lazy. a ++ b === (head a) : ((tail a) ++ b) (plus the base case)
It is only linear when you force it to evaluate, which ideally happens only once (amortized) in your program when the result is consumed. As long as you are careful, you don't get the bad quadratic performance that you'd get from something like eagerly appending a character to a string in a loop in Java. There are either gotchas, though, including relying on the compiler to do things in constant space that naively look linear, and also knowing when the compiler won't help you and you have to structure your computation manually.
“Modifying things in place” is, from the logical standpoint, an unnatural and even dangerous thing. A person that is not familiar with (imperative) programming often has a hard time understanding variables and assignments (similar to some programmers not understanding pointers). Mathematics doesn’t have assignments, either. That should tell you something...
It mostly tells me that mathematics does not care about runtime or space performance. Which is fine, because mathematics is about solving abstract problems, not getting a Turing machine to solve concrete problems.
Won't this have to iterate through linked lists and create multiple new heap allocations on each recursive step? Doesn't that imply n log n heap allocations just to sort a list?
Yes, but due to lazy-evaluation that won't happen until you do something with the sorted list. Your performance may just blow up in some seemingly unrelated place.
My biggest problem with Haskell is how GC and lazy-evaluation makes it very difficult to reason about what the hardware is actually doing at a given point. I know there ways to inspect and control it, but I've found myself preferring languages that have simpler mental models.
Obviously picking first element as pivot makes for a very poor Quicksort. Though I presume a better approach, say median of first, mid and last elements, would add but an extra line?
The reason the first element is used as the pivot is that these are linked lists, not arrays, so it would take linear time to access the middle and end. This isn't a real quicksort.
But you do have to invent something or you wouldn't be writing a program in the first place.
As soon as you need to control the order of execution, memory usage, IO, or any combination of those, you are fighting the language and into territory of things you can technically do and out of the realm of things the language makes easy.
