Haskell ?!?!
May 28th, 2009WTF?! Haskell ??!
Why am I so enamored by Haskell? Especially since my pursuits over the past year have been in the direction of new media and digital media art and away from the likes of hardcore bit and byte pushing. As I read, learn and dabble with more artistic endeavors I came across a very interesting fact from Betty Edwards, author of “Drawing on the Right Side of the Brain“: drawing and art is about seeing. In that light my interest in Haskell makes complete sense. For me, Haskell, and functional programming in general, is a way to see computation more clearly. I am finding that the paradigm shift which functional programming forces is producing a new, more clear way to **see** computationally. Ironically, the mathematical rigor that grounds functional programming allows a level of expression through computation that is not bound by digital thinking. This does not mean that functional programming is better than imperative programming. In fact, I have yet to be convinced that any substantial modern graphical-application could benefit from functional programming. (My intuition says that this is not true and I look forward to delving deeper).
In imperative programming you tell the computer how to solve a problem: “execute these steps with these conditions”. In functional programming you define equations that define solutions to portions of a problem. The combination of these functions, or in the case of a single function its conditions, prescribes the solution. I find the resulting simplicity, conciseness, and interpretability of these programs to be poetic. Furthermore, reading the solutions can provide more insight into the nature and “shape” of the problem. This observation connects to a recurring observation that I have had in my art projects: working through the challenges to convey and communicate the ideas in my head gives me a greater appreciation for those ideas - their shape, texture, nuances, and implications.
Some Haskell
Here is an example Haskell question that I completed at the end of Chapter 3 in Real World Haskell. The problem was to right a function that converts any list into a palindrome. (Palindromic sequences are sequences that read the same forward and backward.)
palindromize (x:xs) = [x] ++ palindromize xs ++ [x] palindromize x = [x]
That’s it!! The two equations define two different parameter patterns for the function. The first takes a list with at least two elements and the second takes a list of one element. The ‘++’ operator concatenates lists. The heart of the first equation is a recursive call to the function with every element EXCEPT the first element from the input.
Some More Haskell
How about determining if a list is a palindrome? I used two different solutions to solve this problem. The one that I am presenting here was informed by Programming in Haskell and uses functions that are not covered at this point in Real World Haskell. I am presenting this one because it is more concise and is more readable.
isPalindrome xs = reverse (drop half xs) == take half xs where half = length xs `div` 2
To me that solution reads plainly even for the Haskell uninitiated. What’s going on here? I am taking the second half of the list, reversing it and comparing it to the first half of the sequence. But my solution is too verbose! Here is a solution that I found at Final Cog, by Chris Dew.
isPalindrome x = x == reverse x
Hmm, that IS the definition of a palindrome. Maybe not poetic, but expressive; Expressive without being disjointed from the problem domain.
I am pretty excited to keep playing with Haskell and to get to a level of proficiency where I can start testing some of my ideas.








