57 Replies - 14383 Views - Last Post: 01 June 2010 - 06:46 AM

Re: Week #6 Challenge: Haskell

Posted 11 February 2010 - 10:09 AM

Paul-, on 10 February 2010 - 07:47 PM, said:

This was a challenge, no kidding. First, my openSUSE, although having several GB of software, it has no Haskell. I had to compile from sources, including installing missing libraries: what a pain. Then I struggled with the Haskell syntax...

I'm assuming you didn't build GHC from source, right? The Haskell Platform is the way to go these days, and it's usually dead simple to compile. Just need an easier way besides erroring out to let one know one needs a certain library.

MentalFloss said:

As it stands, the source code I've seen so far must be the closest thing to magical incantations I've ever seen regarding my understanding of programming.

Pure functional programming is pretty bizarre for a while, and certainly takes some effort to learn coming from OOP and imperative programming. However, the experience will Haskell will serve you very well in languages you already use. After you learn Haskell, you'll understand the benefits of functional programming, and ways to use it properly, and then you'll be able to take advantage of functional features in otherwise non-purely-but-still-functional languages like Scala, Clojure, C# (I hear it gets more functional all the time), and even marginally Python.

How is that for motivation? :p

My intention with this challenge and the Clojure challenge I hope is used in the future is to try to get you guys to see the beauty in functional programming, instead of viewing it as some bizarre paradigm that is completely useless in anything except academia.

One thing I will mention here that I didn't mention in the challenge is that the phrase "Haskell is purely functional" is very important. Purely functional, and just functional are different things. The reason Haskell is so difficult is at first is because you guys are all used to mutable state and mutations, and purely functional languages don't straight-up allow such things (though you can use IORefs and various other things to simulate mutable state). Other languages like Clojure for example aren't purely functional. It's a strongly functional language that gives up purity for practicality, but still doesn't directly allow you to mutate mutable state. You have to do so through refs and atoms and other concurrency primitives, but it's still easier to grok than the way Haskell does things.

What I'm trying to say with the very verbose paragraph above this one is this: if you have a bad experience this week, or in the future, with Haskell, don't give up on functional programming because of it. Haskell is pure, and that changes things significantly. If you like what you see, but don't think Haskell can give you what you want (it can, but it takes time and patience to learn how), there are other functional and inpure languages like Clojure and Scala (sorry, I like the JVM) that you could use as well.

Re: Week #6 Challenge: Haskell

Posted 11 February 2010 - 12:40 PM

So this felt like learning how to ride a bike but instead of ever being successful and taking off the training wheels I just kept falling, scraping my knees and elbows while crying in the fetal position accepting that I will never be able to ride the Haskell bike.

Originally I wanted this to keep a balance that way a user could ideally play until their balanced had been spent. This example is more of a guessing game that rewards you by doubling your bet and nothing more. A bit lamer than I originally expected but I learned something nonetheless.

Re: Week #6 Challenge: Haskell

Posted 11 February 2010 - 02:42 PM

Raynes, on 11 February 2010 - 09:09 AM, said:

Paul-, on 10 February 2010 - 07:47 PM, said:

This was a challenge, no kidding. First, my openSUSE, although having several GB of software, it has no Haskell. I had to compile from sources, including installing missing libraries: what a pain. Then I struggled with the Haskell syntax...

I'm assuming you didn't build GHC from source, right? The Haskell Platform is the way to go these days, and it's usually dead simple to compile. Just need an easier way besides erroring out to let one know one needs a certain library.

That's exactly what happened. I had to go through several iterations to install all the libraries that the Haskell Platform required.

Re: Week #6 Challenge: Haskell

Posted 13 February 2010 - 06:44 PM

Great idea for a challenge, Raynes. At first part of me agreed with the comment by MentalFloss about magical incantations (though think the tutorial I started with is partly to blame, after switching to a new one things went a bit better). It is quite a switch when you're use to OOP. The whole thing still feels pretty akward to me, but your right, its not really that bad.

Haven't managed much so far, just gets a few numbers from the user (the putStrLn 's explain what and why well enough..) and multiplies them all. Also matches the specific heat to a substance. If it happenes to be a substance who's specific heat I can still remember, anyway. Think this is going to be a language I'll stick with past just finishing this challenge, so I'll keep adding to it as I go.

Re: Week #6 Challenge: Haskell

Posted 14 February 2010 - 11:57 PM

Oops! I originally called the function 'rev' but wanted to see what would happen if I caused a naming conflict with the 'reverse' function in the Prelude, so I renamed everything to reverse. Guess I forgot to change one 'reverse' back into 'rev'

Re: Week #6 Challenge: Haskell

Posted 15 February 2010 - 12:13 AM

erik.price, on 14 February 2010 - 10:57 PM, said:

Oops! I originally called the function 'rev' but wanted to see what would happen if I caused a naming conflict with the 'reverse' function in the Prelude, so I renamed everything to reverse. Guess I forgot to change one 'reverse' back into 'rev'

Well, it's definitely inefficient, because init has to walk the list every time the function recurses. If possible, it's almost always a good idea to use a fold (foldl or foldr) in place of explicit recursion, and it's always best if you can just use standard library functions in place of recursion as a whole. So you should think of it like this: Standard library functions -> folds -> explicit recursion. Folds are made to generalize over a specific and common sort of recursion, which is "take an element of a list, modify an accumulator value based on that element of the list, rinse, repeat, profit?????".