61–70 of 149 posts
Earlier quoted context omitted.
Not that I know any Haskell, but wouldn't smallerSorted already include x due to edit: also, how is the pivot element selected there?
Both of your questions have the same answer. (x:xs) means x is the first element and xs is the rest.
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?
Earlier quoted context omitted.
I disagree. quicksort [] = [] quicksort (x:xs) = let smallerSorted = quicksort [a | a x] in smallerSorted ++ [x] ++ biggerSorted
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?
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.
I would expect `isNotJust (Just foo)` to equal `False`, not `True`, and vice versa `isNotJust Nothing` to equal `True`.
The point has some validity (that you should try to encode data into the types if you can), but the example makes no sense in my opinion.
Really just learn it. It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts. Every programmer should learn this language even if they never plan/get to use it.
Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2]
[1] https://chrisdone.com/posts/dijkstra-haskell-java/
[2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...
Earlier quoted context omitted.
What do you mean by "either do things the Haskell (way) or you don't do them"? Isn't that the same with every language? I still don't understand why people put all sorts of unfair labels on Haskell. By labelling Haskell with "fun", we almost make it sound like it can't be used in production.
For 99% of programmers, Haskell can't be used in production.
Really just learn it. It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts. Every programmer should learn this language even if they never plan/get to use it.
But the truth is that I still don't feel comfortable writing anything more than toy apps in Haskell. I'm not really sure how to unit test things when I'm passing complex monad transformers around. I feel like I'm just guessing at best practices for arranging, say, a website of moderate complexity.
There's tons of resources for learning the language itself, but very few on actually applying it successfully to anything other than a single purpose command line app.
Great timing. I was just pondering what functional programming language I should attempt to learn in all my new downtime.
If you want to learn a functional language absolutely do not learn Haskell. If you're interested in static functional programming, learn Elm and then F#/OCaml. If you're interested in dynamically typed then learn Clojure or possibly Racket. That's it. Spending time learning Haskell as your first (or even second) fp language is a terrible idea and has done more to slow FP adoption than anything. You can learn Elm lite…