Hari's Corner

Being a professionally qualified individual myself, I think it is fair to say that most of us have some reasonable expectations of what we want from our jobs. I think it all boils down to the following aspects:

1. Expectation of proper, proportionate reward in return for the application of expertise to solving problems. The reward may be a combination of job satisfaction, recognition and also monetary and material compensation.
2. Reasonable independence of thought and action in following a career path, subject of course to the guidance of experts and more knowledgeable professionals in the field.
3. Lack of restraints on our working environment and the flexibility to work within our comfort zone, subject of course to the inevitable deadlines and time constraints.
4. An aversion to close or constant supervision by colleagues or superiors.

Of course, some of these points also apply to non-professionals but I think professionals are a bit more sensitive on these points, particularly the last two. I think most of us are far more interested in the quality of the actual job we do than on the peripheral aspects of how it is done. The difference, I think, between professionally qualified folk and the rest, is that we professionals actually prefer to determine these parameters on the basis of a considered judgement formed of collective experience, norms and standards set out by the larger community of the particular profession rather than those determined by the immediate boss.

In return for these perquisities, professionally qualified people have a greater degree of responsibility and answerable to not just clients or immediate superiors, but also to the profession and society at large, which may in some cases, also include a legal duty to adhere to a code of conduct as in the case of practising lawyers/advocates.

Here's my rendering of one of India's greatest revolutionary freedom fighters, Netaji Subhash Chandra Bose.

I've been reading a lot about this great man, both online and from books lately and his life story is an inspiration to all patriotic Indians.

Here's wishing a very happy new year to all my friends and blog readers in advance. Have a great time.

Hopefully 2012 will bring cheer and good news to all.

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.