Hari's Corner

Here are some new, original Chuck Norris fact Papa Hari invented... er... discovered. Mind you, somebody else might have already thought of these, in which case I humbly defer to them. However, I have submitted these facts to the Chuck Norris Facts website.

As a kid, Chuck Norris found the blue sky too boring and got busy with a watercolour paint set and brushes. The rainbow was the result.

If you say "Chuck Norris sucks...", he appears in person; then you continue "...the strength of his enemies with a mere glance." if you value life.

Everybody celebrates with fireworks. Chuck Norris celebrates by pulling off meteorites from their orbits and creating shooting stars.

The East India Company was created because a young Chuck Norris expressed a casual desire for Indian seasoning in his gravy. The rest is history.

Cyclones are created whenever Chuck Norris takes a deep breath and creates an intense low-pressure area in the region.

Probably these would make good Rajnikanth facts, except probably the East India Company one (Rajnikanth being an Indian)

I'm currently developing a résumé/CV editor creator in Python and PyQt4. Like most of my software, it is licensed under the GNU GPL v3.

Here are some of the screenshots of the GUI:

While I have implemented saving and loading files in the native BiaCV format (which is a JSON file), I am planning to include an export functionality which will allow the document to be converted to more usable formats like text, HTML and also OpenDocument flat ODT (no Microsoft Word, though you can use OpenOffice to convert the FODT file to DOC if you want to).

You can follow the progress at my gitorious repository. As always feel free to check it out if you have the time and provide your feedback.

Following up from my previous article, I have made some progress and gained some insights about Haskell. Here I will share some of my "insights" of how to approach the forbidding task of learning a functional programming language from the eyes of a newbie. I realize of course, these might not be correct from a purely conceptual point of view, but it's more of a mental approximation of how I see them at the moment. I think some of these tips might be useful for other newbies to Haskell as well.

Think of functions as transformers, not as containers of actions

Adjusting to the functional programming paradigm is always a challenge, and I think one key adjustment is how you identify "functions." In procedural or OOP, functions (or rather methods) are containers or groups of actions performed sequentially. In functional programming language functions should be seen as transformers, in the mathematical sense: it takes an input and transforms it to something else.

This makes it a lot easier to learn functional composition, higher order functions and so on. This change is actually not as easy as it sounds, though. For an experienced traditional programmer, functions, procedures or methods all mean very similar things and getting old ideas out of the head can be a bit tough. So don't worry too much if it doesn't sink in at once.

Recursion is easy: if you work it out backwards

One thing about recursion is how intuitive and smart a solution looks when it is presented. But not all newbies to the FP paradigm can "get" how it can replace the normal for and while loops in procedural languages.

My advice: when approaching a problem that demands recursion, don't start from the recursive case. Rather think about the base case first and how you get there from the more general cases. This is actually something I find rather intuitive, but it is not the obvious way of thinking about a solution to a problem coming from an imperative programming background.

Try to write your own working code and go from there

Tutorials are nice, but they are just learning aids. I would suggest avoiding the temptation to look up solutions from tutorials when you get a bit more experienced.

Actually writing working code, even for reasonably trivial problems, can be enormously fun and satisfying, particularly in Haskell. Writing code that compiles properly can be a thrill, because Haskell's strong typing system really works well to identify MOST kinds of obvious mistakes, but of course, writing a correct program is more than syntax correctness. For simple programs, if it compiles, it's correct.

My order of practicing writing your own programs would be something like this (of course, feel free to disagree with this list):

1. Simple calculator that takes two values and performs an action based on user input. Areas of a triangle, area of parallelogram etc.
2. Fibonacci series, and other basic recursive patterns.
3. A Caesar-cipher encryption function.
4. A program that reads a string of characters and identifies it as either an integer, a floating point number or a word.
5. A program that reads an integer number and outputs its English equivalent. E.g. 1200 : one thousand two hundred. (this could be where it gets harder though)
6. A postfix (or reverse polish) expression evaluator.

Once you write the code, find out from experienced Haskell programmers what mistakes you made and how you can write it better. The Haskell community is full of generous and kind folk who help newbies a lot (#haskell at FreeNode is particularly nice).

After that, you can pick and choose, but generally try to advance one concept at a time.

Thinking before a single line of code is the right approach

In Haskell circles, it is a common saying that you would spend more time thinking about the problem than implementing it. This is not strictly true, particularly for a newbie, but it has merit which you will appreciate as you progress. In the functional programming paradigm, solutions are worked out in a methodical and mathematical fashion and thinking ahead is often a big part of it.

Finally don't pressurize yourself to learn quickly

One mistake is trying to swallow too many concepts at once. It doesn't work like that. Everything takes time to sink in, because it's all so new and different. Learning yet another procedural/OOP programming language is easy if you already have some background in procedural/OOP programming, because the concepts are familiar. Not so with FP.

Haskell seems to have a reputation for being hard and academically oriented, even in Functional Programming circles. And actually reinforcing that idea can lead to mental blocks in a newbie. Learning it with an open mind can work wonders. Allow the learning to happen at its own pace and enjoy the process. Thinking of "how I will ever be productive in Haskell" is counter-productive. Rather learn for the sake of learning and feel good about the knowledge you already possess.

Hope this helps. As always I welcome feedback and tips from the Haskell community.

My thanks to yitz at the #haskell IRC channel at freenode for submitting my previous article to reddit. There are some interesting comments in there. My thanks to all those who contributed comments, both here and at reddit.

Note: this is not a post bashing either functional programming or Haskell, but from a newbie's perspective, why learning a functional programming can be painful especially for those programmers who have a strong foundation in OOP and procedural programming. Rather my intention is to encourage learning the FP paradigm and warn about potential pitfalls. Again, being a newbie myself, I appreciate that this might not be a true representation of what functional programming is all about, but that is not the purpose of this article. My thanks to the folks at #haskell on FreeNode and others for their thoughts and insights. As a result I'll be making small corrections/additions to this article as I go on.

Following up on earlier article on my learning Haskell, I have to say that learning a functional programming language is unlike anything I've learned before. In many ways, functional programming is like learning to program all over again and it's not something like OOP which just extends the concepts of procedural programming into new directions. Without further ado, then...

The learning curve is not linear

This is to be expected. Diving straight into functional programming, I found that the basic concepts aren't that hard at all and this can lull one into a false sense of security. Things like statelessness, immutability of "variables", lack of side effects, and pure functions are theoritically quite easy to grasp. But it's one thing to be familiar with a concept, but totally another to model and condition your mind to map a problem into the functional approach.

One fundamental early pitfall could be recursion. The most common problem that is introduced when teaching recursion is the factorial problem. It's actually quite simple and ridiculously intuitive when presented as a solution. Here is how a factorial is defined in functional style (pseudo-code):

factorial (0) = 1 
factorial (n) = n * factorial (n-1)

What it means is that you define a factorial of a number N as the number N multipled by the factorial of N-1. So the function calls itself till it calls factorial (0). This is called a "base case" (where recursion is terminated). This is fairly easy to understand. However, it is far from intuitive from the point of view of working out a solution for a problem that one might solve using an iterative approach.

A real world problem may illustrate this better: counting pebbles. The instinctive way to counting a number of pebbles that are laid out in a row is simply to point a finger at each pebble, one at a time, and mentally increment a counter for every pebble you point at. This is an iterative approach. Another less obvious (but still easy) method is simply to pick up a pebble and keep it in your palm and repeat the function until you run out of pebbles. The number of pebbles in your palm at the end of the process is the answer. You've just "folded" the problem using an accumulator (your palm) instead of using your finger (counters). Of course, there will always be a debate as to which is more efficient but that is besides the issue but I think it's a good way to mentally "map" recursion and iteration as any.

Functional programming favours the second approach and FP languages support recursion by optimization techniques, even implicit recursion through folding - a concept that keeps recurring in the FP paradigm.

Recursion is only the tip of the iceberg though. But it is certainly an early barrier that needs crossing.

Too much theory can be off-putting

One thing I found when searching for tutorials/articles on Functional Programming is theory. You'll run into a lot of theory and they can easily confuse you and lead to a conclusion that "functional programming is for academicians". While it's inevitable that you need some grounding in mathematics for functional programming, it's not strictly a requirement. But even then, the terminology can be heavy, especially with relation to the more advanced concepts like Functors, Monoids, Monads etc. I confess that I still don't know them and trying to even familiarize myself with them is frustrating. I would suggest that letting go of these topics initially and focussing on the basics as more important.

Tutorials that make it seem simpler

Actually for Haskell, the excellent guide "Learn You A Haskell for Great Good" makes Haskell seem ridiculously easy at first look. But actually the learning difficulty begins when some of the more advanced concepts are introduced. Pitfall one for most people I expect will be "higher order functions." It doesn't become 'slightly harder' after that. It becomes ten times harder unless you are already conditioned to functional programming intuitively. Actually I would recommend reading a few chapters early on and try to really grasp the basics first. Going too fast, like with imperative programming languages, will lead to confusion.

Everything "looks" intuitive in functional programming when presented as a solution (ignoring the more advanced concepts and syntactical complexities involved, for a moment). Arriving to that solution is precisely where you find the roadblocks.

My recommendation would be probably to swallow the concepts in small bits and write working code on your own for simple programs using those concepts. It might be slow going, but then again, learning is never a piece of cake.

Forget the Zealotry or just ignore it

This might seem controversial, but a lot of articles I read on the internet sound a lot like zealotry to me, extolling the virtues of Functional Programming and making it appear that imperative programming are for the mentally inferior ape-types. Sure, that is putting it a bit high, but it can be a bit depressing to read such articles. Whether FP paradigm is truly superior or not is besides the issue. Point is, to a newbie, it can seem daunting and downright depressing to see your second nature (read: imperative programming methodology) trashed like that. Frequently you come across "code samples" solving the same problem: one with the imperative approach with exaggerated clumsiness and the other (almost unreadble, but elegant looking) functional solution ("isn't that clever!" kind of solutions)

Ignore that (except for the code bit which can be educational once you're more comfortable with FP). Such talk/writing adds nothing of value to a newbie and to my mind it creates too many expectations about what FP can offer. While terms like "expressive", "rich", "elegant" and "graceful" are thrown around frequently in reference to FP, to a newbie it is just marketing talk in my opinion. Maybe it can deliver, maybe it cannot. But as a newbie, such articles are a distraction from learning and can even lead to demotivation (why don't I just *get* it?)

And finally...

The above are just some of the few pitfalls that a programmer new to FP paradigm (with a focus on Haskell) is likely to fall into. I might add, there are a few other points to add to the above, but they are relatively minor and can be overcome with familiarity and practice.

• Type system: This is specific to Haskell, but nonetheless, the strong, static type system can be an irritation and annoyance to those used to dynamically typed languages. However, with practice, it gets easier to understand and one actually begins to appreciate its strengths.
• Syntax and syntactic sugar: I never heard of the latter term until I came across Haskell and I confess that these elements can be a bit confusing at first. Every new programming language (including imperative languages) has this issue, so it's not unqiue to FP paradigm (though it can be a slightly harder hurdle in FP).
• Associativity: This is another common term used in FP paradigm and learning the associativity of functions can be a little confusing as can concepts like compositing, currying etc. Simply learning to "read how this code works" can be challenging at first and takes time to begin to understand.
• Laziness and lazy evaluation: This is specific to Haskell and while the concept itself sounds very intuitive, it can be a bit confusing to understand "how" it works in practice especially if you're still thinking like an imperative programmer. I would suggest forgetting about understanding it and just take it for granted until you run into a situation where it actually matters whether a function works lazily or not.

These are just some of my observations from a very "newbie" level. Unfortunately I've not found too many articles or essays documenting things from a total newbie's perspective and while the LYAH guide comes close to "understanding" the newbie, it is still written by a person who is well experienced and knowledgeable in Haskell and the guide sometimes reverts to "expert-speak" inadvertently. I welcome suggestions and feedback on this article from everybody!

Postscript: Reactions and Responses

There is some misunderstanding in reference to the bit about "recursion." My point wasn't that recursion is difficult or hard or unfamiliar to a programmer from an imperative background. My point was a recursive solution to every kind of repeating pattern is not always intuitive for those used to iterative thinking. And that could be a minor roadblock in understanding Functional Programming early on,.

I made a post about Haskell on this website:

I am a newbie to Haskell myself, so my perspective is purely from a beginner point of view, but within three days I have picked up the most basic concepts and feel fairly comfortable with the functional style. At least, mentally I am now ready for pattern matching, recursion and other fundamental concepts of functional programming as opposed to imperative, iterative approach to programming. Will I be able to write a full-fledged GUI within a week or even a month? I doubt it. But just the process of learning itself is rewarding.

My suggestions would be to learn the bare minimum you require to write simple 'hello world' type programs (with slowly increasing complexity) and then go on from there. Trying to digest everything at once can be very frustrating, as can be the task of trying to write a "real" application. Stop reading tutorials. Yes, this goes against the grain, but really tutorials tend to either over-simplify some things or lead to confusion. The "Learn you a Haskell" tutorial is an exception, but even there, don't try to approach all the concepts head on.

If I might make a small comparison. Learning another imperative programming language is like getting to understand a different accent/dialect in English if you are already familiar with English.

Learning Haskell is like learning German. The script looks mostly the same, but it's a whole different thing altogether. If after learning for a few weeks, you can speak a few words in German and communicate basic ideas, you're already progressing well. Haskell is somewhat similar.

Yes, well, learning Haskell can be compared to learning German if you only know the different dialects/variants of English. The alphabet is mostly the same, but it is just not English!