Weekly Challenge – Look Back

Last week I set myself a challenge of listening to only Bach’s music for a week and it is time to write about that experience. I am very glad to write that I could stick with that simple goal without swaying!

I got to listen to some great music by Bach by sticking with this goal and I could cut down the myriad distractions with this goal. Now, some of the most favourite compositions are very much ingrained in my mind which is fantastic as I’m a big Bach admirer.

Sometimes the urge was very strong to listen to some other music which I enjoy a lot as well. I have a wide range of taste when it comes to music thus to confine to one genre even for one week was not an easy task. Eventually it paid off by limiting distractions which was very beneficial for studies and reading. My mind no longer tried to ‘lip sync’ with a song as it is impossible to do with classical music! Furthermore, as Bach’s music is very harmonic I find his music much better to ‘put on and forget’ compared with more complex music, for example that of Beethoven.

I have scrobbled more than 900 times during this period, so much so that now Bach is the fourth highest most listened to artist on my last.fm page. Useless statistic… but good to keep track on my music habits nonetheless.

I found that sticking with a public challenge very useful to stay on track. Although at times I was very close to break the rules – for example by listening to a Youtube music video! But I managed to stick with the goal steadfastly and that was mostly due of the public nature of the goal even though not many people will ever get to see the post or take an interest!

This lead me to think about accountable goal setting and I came across Brent Yorgey’s excellent post[1] about how Beeminder changed his life. Beeminder was one of the best things I discovered last week. I thought of signing up for the service and more importantly to start using the service to keep track of my goals in a very quantitative way.

[1] Beeminding for fun and profit

Weekly Challenge – Only Bach!

I thought of starting weekly challenges on a regular basis. I want to get into the habit of sticking with a simple goal without exceptions. Thus, I thought of starting the weekly challenge goal setting with the simple goal of playing only Johann Sebastian Bach‘s music in private listening for a week starting from 12th October, 2014 (till 19th).

It will not be active listening for the most part, but rather music which I normally put on when I’m working. This would also be a good opportunity for me to explore as much of Bach’s compositions available through Spotify.

I will be able to keep track of how successful I’m with sticking to the goal by analysing scrobbles on my last.fm profile. I hope this is going to be a good prelude for more challenging goals in the future!

Back to Blogging Regularly

I haven’t been blogging for quite some time now. I would like to change the situation with more regular posts about subjects that interest me. Writing a post about getting back to blogging is a good start, I guess.

Following are some of the subject areas I would like to blog about in the future.

  • Functional programming with a special focus on Haskell, a topic I’m really passionate about
  • Parallel processing and concurrency
  • Unfamiliar or advanced topics in C++ such as new concepts and constructs introduced with the C++11 standard
  • Other random things such as interesting books or any other topic which I fancy writing about

I have come to realise that blogging about something makes me think deeply about that and dig deeper to gain a more thorough understanding so that I can actually convey something useful to an interested reader. Thus, even if there is zero actual readership for my posts I end up with a net positive by committing myself to blog regularly.

Till the next post then!

Very Simple Graphs in Haskell

I suddenly felt an interest to generate graphs for simple integral functions in Haskell. Following is a quick inelegant solution I cooked up after dinner today.

markLine line x
  | length line > x = (take x line) ++ "*" ++ (drop (x+1) line)
  | otherwise = line

markLineMulti line pos = foldl markLine line pos

displayGraph x y pos
  | y == 0 = putStrLn $ let line = foldr1 (++) $ take x $ repeat "+"
                        in markPositions line 0
  | otherwise = do putStrLn $ let line = "+" ++ 
                              (foldr1 (++) $ take (x-1) $ repeat " ")
                              in markPositions line y
                   displayGraph x (y-1) pos
    markPositions line y = markLineMulti line $ 
                   map (\(x',_) -> x') $ filter (\(_,y') -> y'==y) pos

graph f x y = displayGraph x y [(x', f x') | x' <- [0..x]]

Here’s the cute little graph for y = 2*x in a 20 by 20 grid.


Improvements to this would be to enhance graphing function to handle negative x and y axes as well add ability to display real functions (with integral approximations).

Awesome Tiling Window Manager

Another episode in the journey of optimising the development environment primed for efficient keyboard usage.

After doing some background research on tiling window managers I finally decided to try one out for real in day to day usage. This drive was partly due to the realisation that they are much better suited for a keyboard junkie like myself than common desktop environments, be it Unity in Ubuntu or Windows 8’s (crippled) desktop environment.

Awesome or Xmonad…

Within the myriad choices available for Linux in terms of tiling window managers Awesome WM and Xmonad seems to be the ones which are most popular and feature rich. Being a Haskell fan, my first thought was to try out Xmonad, but after some more digging and playing around in a Arch Linux VM I decided to settle for Awesome (for now).

Installing awesome in Ubuntu was a breeze. Awesome is available in Ubuntu repositories although I had to add a PPA1 to get the latest 3.5.1 (Ruby Tuesday) version.

sudo add-apt-repository ppa:aguignard/ppa

sudo apt-get install awesome awesome-extra

After installing I just had to log off from the current Unity desktop and as expected Awesome was available as a choice for desktop environment.

Control anything from Keyboard

The best thing about awesome is that you can control everything from the keyboard. Want to switch to a different window arrangement…? – just press Mod4 (Windows key) + Space. No need to even touch the mouse. All the keyboard shortcuts are listed in its man page and there’s a lot!2

Using multiple workspaces which are tag based in Awesome is very intuitive. It is the first time that I can say that I have truly made use of workspaces efficiently in a Linux desktop. I have always found the default workspace switching be it in Unity of vanilla GNOME is too clunky and heavyweight for my taste. On the other hand switching to a different workspace in Awesome is as easy as Alt + Tab application switching in other desktop environments. I think workspaces in awesome comes close to Emacs’ buffer switching level of ease and effortlessness.

By default, Awesome is configured to use 9 workspaces. They can be customised to specific needs such as web browsing, coding etc. with different window management policies suited for those needs. So far I’m using three workspaces – one dedicated for browsing, one for music and one for coding/writing.

I highly recommend anyone to try out Awesome as a lightweight and efficient replacement for traditional desktop environments.

Importance of a REPL

Read Eval Print Loop or REPL1 in short is one of the luxuries few programming languages offer out of the box and something I think should be more commonplace in practice today. Granted some languages are more suited to incremental development than others. For example, it is hard to imagine a REPL for C++ would ever reach the level of REPL offered by languages like Common Lisp.

It is not the case that only dynamic languages can provide a good REPL although they generally tend to have better ones. For example Haskell is a language with a strong static type system, yet it provide a good REPL in the form of GHCi2 which can be used to iterative development.

Problem situation

A problem most statically compiled languages like Java, C/C++, C# have in common is that they all involve a fairly elaborate compilation step which before you can see the results. Here, by results I include both the program output and auxiliary output like unit test results.

This process although we are very accustomed and take it as part of the package when we use such languages breaks the flow of thought which is very important for programming practice. The time you wait for your code to compile no matter how small that it will be is a break from you main task – which is developing the solution. Exacerbating the matter, it is not uncommon to see build times of more than a couple of minutes even for small C++ projects especially if they are badly structured in the first place (templates… I blame you too!). Hence the XKCD joke:


I think this compilation step is a constant source of anxiety for a developer worrying first whether it will compile without throwing a bunch of syntax errors or type errors, then worrying whether it is doing the right thing by inspecting it through running the program or checking unit test results.

Even if you are working on a very specific part of the project, to test out the new code you wrote it is highly likely that you have to build the whole project just to run your unit tests in the languages I have mentioned before.

Immediate Feedback Loop

A REPL addresses this delayed feedback loop problem giving you a playground to interact with your code. Developing in a strictly compiled language is like sending your code to a factory to be built and your program (or error report) returned back through mail. Well, that’s a bit of an exaggeration… but not much since working with a REPL is like having a lively conversation with your code and the compiler.

No longer you have to wait for the compilation process to get feedback about your new code. You can simply try them in the REPL first and tweak it to your heart’s content before even touching the source file. On the other hand If you want test the new function you wrote as part of the solution you can just try it out by calling the function in the REPL by just loading the function. Languages which offer REPLs all provide functionality to this painlessly. Common Lisp and Clojure are good examples for this.

REPL makes you more adventurous

As a consequence from the above property REPL makes you more adventurous to try out new ideas because you no longer have write a new function and wait for the whole project to build to see how it works.

You are no longer afraid that you’ll break something by modifying the code directly in the source files because you can simply try them first in the REPL environment and test your assumptions. REPL cuts the elaborate steps like checking out files, modifying it, then compiling it and finally seeing the results by giving you the opportunity to interact with existing code like a dialogue. You can ask questions from your code and get answers immediately (not by mail).

Encourages best practices

When you use a REPL as another tool for development you tend to follow best practices like modularity, less coupling and functional decomposition more consciously. It is tedious if not practical to load a 100 line Clojure function to the REPL to test it out, so chances are high that you won’t even think about writing such code in the first place if you use a REPL regularly. More likely scenario would be you’d break up that function to manageable (and more maintainable) sub functions and glue them as required to get the functionality.

Practices like these leads to more high quality code bases. I think this is a very important indirect consequence of regularly using REPL as tool in your development arsenal.

More opportunity to refactor and improve code

Since a REPL provides you with a very good playground to interact with your code and modify it freely without the fear of breaking it this enables you to identify and try out more avenues to refactor and improve existing code.

If you think the function you wrote to do something two weeks ago can be improved if you used a different technique – then you can simply try that out in the REPL. Then what you would do is apply the tests you wrote for the original function and see whether they pass for the new function you wrote. If all is green then you might do some empirical testing to see the performance differences between the old function and the new one in the REPL itself. If your assumptions seem to be still valid then you just cleaned up and improved old code without even touching your code base!

Programming languages like Go with fast compilation time reduces the lag of the feedback loop but still does not provide the best attraction of a REPL which is for me is the ability to interact with code as an on going conversation.

For a developer who has not really experienced the convenience of a REPL will not really get the importance of a REPL until he or she tries out a language with first class support for such tools such a Common Lisp with its venerable SLIME3 and even new comers like Clojure with its nrepl4. It is great to see that most of the functional programming languages like F#, OCaml and of course Haskell provide REPLs with comparable functionality but they tend to be still somewhat limited when compared with languages in the Lisp family.

Acme Editor – First Impressions

Brief History of Editor Usage

For years now I have been using both Emacs and Vim as my primary editors for most of my coding and writing outside of work. For any prolonged length coding session my go to tool is Emacs in evil-mode1. For quick editing tasks it is Vim. Common in both scenarios would be my preference to Vi bindings. I really like the fact that I do not have to lift my hand off the home keys to do even complex text operations. I think evil-mode combined with Emacs’ unmatched power of extensibility offers best programming environments for many of the languages I’m really passionate about – Haskell, Clojure, LISP and OCaml to name a few which have great Emacs support.

I have invested time to learn Vi bindings to do text editing efficiently so that whenever I have to use an IDE the first thing I would do is look for a Vi emulation extension. Thankfully, both Visual Studio and all the Java IDEs I happen to use have excellent Vi extensions.

Sublime Text of which I have only good things to say has a good Vi emulation in the form of its Vintage mode even though it is not very extensive. But I do not think it offers the level of power Emacs offers for my daily use; org-mode would be just one feature which is hard to replicate in Sublime which is essential for me (even to write this post!). Besides, I would prefer to use an open source editor whenever possible.

Trying out Acme

Just out of curiosity and to expand my editor horizons I thought of giving a shot at using acme editor which is favoured by some notable programmers such as Rob Pike (who is the author of acme), Dennis Ritchie and Russ Cox2.

Acme comes with Plan 9 from User Space (plan9port)3 install which includes tools from the original the Plan 9 operating system. This port of Plan 9 tools supports many popular Unix and Unix like operating systems such as FreeBSD, Mac OS X and mostly importantly for me Linux as well. Installing plan9port on Ubuntu is not a difficult task at all. Project’s installation guide page is sparse, but that is because it is very little you have to do to get it installed on your system of choice4. If you are a Ubuntu user make sure you have installed xorg-dev package before you try to install plan9port.

First Impressions

Acme is a non-modal editor like Emacs. But, unlike Emacs acme relies on mouse rather than keyboard for most of its functionality. In fact, to use acme to its full potential you need to have a three-button mouse which would not be a problem these days since that’s the most common type now. Since it is non-modal I think it would be easier for someone who has not tried an advanced editor before compared to trying Vim for the first time. There won’t be different modes for navigation and entering text as it is the case with Vim which I think helps new-comers.


Above image shows a typical coding session which I would normally use Emacs for. Working on a Clojure source file also having separate buffers for a nrepl session and one for a shell with lein5 running in the background (in this case evaluating clojure-koans).

The coolest thing about acme is that most commands you run from your shell can be run inside acme itself! For example, in the image shown above the buffer which is at the bottom right corner is actually running a live lein session. Thus, when I make a change to the source file I’m working on (in the left side column) lein will evaluate the file automatically and also update the pass/fail status of unit tests! That is pretty impressive given how little I had to do to get this level of integration.

Top most buffer in the right hand column shows the highlighted command which I used to run the current lein project. To get this live buffer running all I had to do was to a) write the command: lein koan run b) highlight that with the left mouse button and then c) middle click on the highlighted command. Acme will then pop up another buffer with the results of last command – in this case it is a live lein evaluation of unit tests. Sure, I can do the same thing with Emacs equally easily but what is most impressive here is the philosophy that anything you write can be executed as a command. In acme text can be commands and commands can be text. Nice…

What I miss…

Well, this is a no-brainer… I simply hate to use the mouse when I’m in coding/writing mode! And that is not for the lack of practice for advanced mouse usage since I’m not new to mouse-gestures or mouse chording since I use FireGestures6 for Firefox extensively. Yet, I still prefer the Vi way of navigating and command execution using just the keyboard.

What if acme had Vi key bindings? :)

I think simple yet very powerful ability to execute any shell command is very powerful at the hands of someone even at an intermediate level competence with command line tools. You can come up with all sorts of text manipulations simply by combining commands in a functional manner. This is the power and elegance of Unix philosophy. I think acme is another demonstration of that principle.

An editor like acme cannot be judged by less than a day’s use! So I plan to use it time to time for my usual editing tasks and see how I get along with acme. For anyone interested in trying out acme I recommend this video showcasing acme usage7.


Terminal Happiness in Windows

If you are like me who prefers the power of a terminal environment like zsh or bash in Linux (or Mac OS X for that matter) that’s something you’ll find lacking in Windows. Default DOS prompt of Windows is a long way off from a customized zsh shell in Linux in terms of usability and power. In my opinion, even the much improved Powershell is hampered by its default interface which does not offer much of an improvement over age old DOS prompt.

The good news is that it is fairly easy to setup a really good terminal environment in Windows. This is a brief guide to setup a comparable terminal environment in Windows using Cygwin and ConEmu combo.

Setting up Cygwin

We require Cygwin to provides us with the Unix like environment under Windows. Cygwin implements a substantial part of the POSIX API which is the foundational standard for Unix and Unix like operating systems.

Installing Cygwin under Windows is a very simple affair.

  • Grab the Cygwin setup.exe file from the official site.
  • Follow the installation procedure of the setup wizard. Setup will require you to provide a directory to keep local installation files temporarily which will be separate from your Cygwin install directory. As per the installation directory selecting a top level directly like C:\cygwin or similar in another drive would be the best option.
  • Packages to install – Cygwin by default installs the base package which contains most of the widely used Unix commands like ls, grep etc. There are tons of Cygwin packages you can choose from the setup, so it could be bit too overwhelming when you run the setup first time. I suggest first install only the base package and the important ones like: zsh, git, curl and wget. There are tons of suggested packages for a good Cygwin setup around the web such as this. Make sure to install the highlighted packages; we will require them for later customizations.

Setting up ConEmu

Cygwin comes with a console configured with bash shell – which unfortunately is not much of an improvement over DOS prompt of Windows in terms of usability. That’s where ConEmu comes in.

ConEmu is a console emulator with support for tabs and loads of other features with excellent customizability. ConEmu can be either installed as a regular Windows program or run as a portable application. Grab the installer or the archive release if you plan to run in portable mode from http://code.google.com/p/conemu-maximus5/downloads/list. I have found that even the cutting-edge alpha releases to be stable for everyday use.

After completing the setup when you first start ConEmu it will start the default Windows command prompt. Integrating Cygwing bash or zsh shells with ConEmu is really simple. Click the new command prompt button with green + button. It will ask for which prompt to run.

  • To run bash shell provide:
    C:\cygwin\bin\bash --login -i 
  • To run ZSH shell provide:
    C:\cygwin\bin\zsh -l -i 

These commands start the respective shells as the login shells which loads up customizations specific to your own login. These customisations are stored in the Cygwin home directory which under default install directly will be under: C:\cygwin\home\USER_NAME\ with USER_NAME replaced with your windows login name. ConEmu will remember these shells so next time you start you can simply select the shells from its combo box without manually entering them again.

Customising ZSH

Standalone ZSH shell provides more niceties than a default bash shell, but it can be easily spiced up by using a framework like oh-my-zsh. Oh-my-zsh contains loads of customisations and many themes for ZSH shell. One standout feature I regularly use is its nice git integration as shown below.


If you are a heavy git user installing oh-my-zsh even for this features is worth it. To install oh-my-zsh follow the instructions given in the github page for the project. I suggest following the manual installation since I have found that automatic installation is not very reliable under Windows. Make sure to run the installation from a Cygwin shell. The fourth step given in the manual which is to make ZSH the default shell is not important for our setup since we will be using ConEmu in the first place.

Some more goodies for Coders

Given a typical coding session involves more reading than writing code having a powerful code search tool is really important. Cygwin comes with the venerable grep tool which provides fast regex based search can be used for this purpose. But there are other tools which are designed for this use case such as ack or Silver searcher. For example these tools will conveniently ignore files in your .git directory which you would not normally want to search in.

Even if you are using a modern IDE like Visual Studio you will start to appreciate the power of command line code search tools once you try them which I highly recommend. Both of these tools can search even large code bases in a fraction of a time an IDE will take for the same search query. Not to forget they provide full power of regex search not only for your search terms but also what types of files you want to search in (say a query like .cpp files starting with a name like Command*).

Of the two tools I have mentioned above setting up ack is the simplest under Windows. To install ack to be used in a Cygwin shell follow these steps.

  • Grab the ack.pl Perl script using following command. Make sure to run this command in a Cygwin shell, otherwise you will have to provide the Windows path to your Cygwin bin directory.
    curl http://beyondgrep.com/ack-2.04-single-file > ~/bin/ack
  • Make it executable
    chmod 0755 ~/bin/ack
  • Now try out whether it is working correctly.
    ack --version

If you see the ack “about” message you are good to go.

Sublime Text like Fuzzy Matching in Haskell

After reading a Python implementation of Sublime Text like fuzzy matching this morning I was compelled to try this out in Haskell. So, here it is.

import Text.Regex.PCRE
import Data.List (intercalate)

-- By string =~ pattern we'll get the start of the match and the length of 
-- the matchas a (start, length) tuple if there's a match. 
-- If match fails then it would be (-1,0)
score pat str = case str =~ pat' :: (Int,Int) of
   (-1,0) -> 0.0
   (start, len) -> calcScore start (start+len)
   pat' = intercalate ".*?" $ map (:[]) pat
   calcScore start end = 100.0 / (fromIntegral ((1+start) * (end - start + 1)))

I’m using regex-pcre package instead of the default POSIX regex package bundled with Haskell to match the original Python implementation as closely as possible. Python, as most other languages default to using a Perl compatible regex engine.

intercalate function is used to transform the search term pat into a fuzzy pattern. As an example pat = “foo” will be tranformed to a pat’ = “f.*?o.*?o” which is the one we’ll be using to match against the supplied string parameter str.

If the match is successfull we’ll get the start position of the (first) successful match along with the length of the matching string. For our calculation we require the end of the match which is start + len in this case.

You can find the Python implementation and a good explanation of the rationale behind the calculations from the original post.

Hello world!

Hello everyone, welcome to my blog about random stuff I happen to write about.
Here’s a customory hello world in Haskell which occupies most of my hobbist development time these days.

main :: IO ()
main = do
    putStrLn "Hello, world!"

This is a really a mis-placed start in Haskell if anyone reading this is hoping to become a Haskeller because I think this does not capture the functional beauty of Haskell. So, we’d give another try… How about a recursive Quick sort. Ok, Quicksort it is:

qsort :: Ord a => [a] -> [a]
qsort [] = []
qsort (x:xs) = qsort lhs ++ [x] ++ qsort rhs
  where lhs = filter (< x) xs
        rhs = filter (>= x) xs