Wake up & Code

I have lost count on the number of drafts I have saved on this blog. Drafts with tempting titles, promising potentials but a lethargic author. You'll find that this post has been conveniently labelled as my daily dairy but you know as well as I do that it's probably not a dairy account of my activities and it's definitely not daily. I take pride (maybe misplaced) in what I post here. Quantity is least bit of my concerns regarding this blog. I am consistently agitated by such an example of lack of creativity and discipline i.e. this blog. This makes me constantly sad yet consistently careless about any of this, so I digress.

Dreams are a projection of desires on the murky canvas of night empowered by the unshackled nature of sleep. Mostly a dream is all about the statement of “what”, the beauty of which is rarely bothered by the enquiries of “how” or the suspicions of “why”. The easiest way to claim success or reach the end of an abyss is to experience a dream of the corresponding genre. This paragraph is getting out of context, this article is getting out of hand; so I digress again.

Often when one dreams about something, weird things happen. Everything is either so easy or even the most trivial things seem taxing. But for the intent of this post I am going to focus on when dreams apply leaps and leave gaps in order to get from one point (in the dream) to another. For example if I am dreaming about travelling on a plane then my brain would automatically abstract out certain details so as to stay on the main topic i.e. travelling on a plane. I wouldn’t have to sleep through an entire taxi ride from my home to the airport, would I? The dream would just make things happen. One moment I’d be getting ready for the journey and the next moment I’d boarding the plane. Easy as pie. My point is the automatic abstraction of details that happen in a dream. And of course when one wakes up then things become normally difficult. Every details starts to matter and every action consumes resources like time and effort. The idea (dream) of travelling on a plane becomes much more painful when one encounters facts like:
There is too much luggage. Public transport won’t do it this time. A separate vehicle is needed specifically to carry all of this to the airport. I don’t have a separate vehicle. Booking a cab seems to be the logical thing to do. To book a cab I need the app. To download the app I need internet. Mobile data will take too much time. Need to find Wifi. Need to know the password. Need to download the right app. Need to know how to use that app. Need to be aware of any first time offers the cab company may be offering. Etc, etc, etc, you get the picture.

You see how the details start to pile up on you as soon as one starts to actuate a dream.

A similar pattern can be observed in the life of a "logician by ambition and programmer by default". The fundamental of any programming assignment can be classified into two categories:

1. Coming up with a solution (forming an algorithm) or simply understanding an already existing solution (learning an algorithm).
2. Implementing/ actuating the solution (coding the algorithm).

The above procedure (also an algorithm in its right) is vulnerable to the same implications I described earlier. Code is to an algorithm what reality is to a dream. Meaning that just like a dream tends to abstract finer details focusing on the intent rather than the implementation, an algorithm too tends to be intentionally obscure for the purposes of being bold and clear rather than being detailed and clumsy. As an example consider an algorithm that can tell you the order in which you should go about completing your to do list (topological sort). The algorithm is simple enough:

1. List down all of your tasks.
2. Assign dependencies, like what tasks needs to be done in order to attempt a particular task.
3. Make a graph of this scenario where tasks are the nodes and the dependencies are directed edges.
4. Start scanning the graph for a node that does not have any dependency (an in coming edge), when you find one, do that task and remove it from the graph with all the edges originating from that node.
5. Repeat the above step on all the remaining nodes until no node remains in the graph.
6. Once the graph is empty, all your tasks are complete.

Of course the algorithm sounds simple and elegant but coding it invites many painful considerations:

How do I take input from the user regarding what are the various tasks? How do I make my program understand which tasks are dependent on others? The algorithm said something about graphs, how do I represent graphs using my basic data types? I know, using adjacency lists. Wait, how do I form the adjacency lists? Should I include the right header to handle lists or should I use simple arrays? Should I represent each task with a class or just leave them be a string containing the name of that task? How do I keep track of the number of dependencies left for each particular task? How to adjust the graph for when some task is complete. How do I store the order in which each task was completed? Etc, etc, etc, you get the point (or in this case the paragraph).

I don’t know if have been able to describe how I feel 

about this. Feelings are always hard to describe.