The net neutrality debate in India largely lingers on what folks will have to pay for that they’re now getting for free, how much more it is going to cost them to do the same things they’re doing today, what will happen to the small business guys as the large guys take over with money power, etc. Even the (in)venerable AIB does more or less the same pitch in their now famous Save The Internet video. There is also the article on The Hindu pointing out the panel recommendations and they mostly have to do with who and what needs to be paid for and what is to be left untouched.

Much of this money-focused hoohah is a distraction on why net neutrality is important to us. If we don’t adopt a “we won’t touch the internet” policy, there is much more at stake than just a few people making more money than we think they should.

In A Mental Model for Variables and Closures in Javascript, I described an allocation based model that I’d used with some success to teach and understand the intricacies of closures, as implemented in Javascript engines. While we have plenty of tutorials on closures that describe what results are gotten under various conditions, with variables being magically “captured”, I’ve not seen many work through a mechanistic explanation of closures. To that end, here is the slide deck of a session I recently conducted which walked the participants through a mechanistic understanding of closures and objects, using the Chrome debugger. Read on to find out how to follow the deck and the rationale behind it.

I gave a talk titled “Mathemusicking with children: Doing math and music without telling them apart” at the C. R. Rao Advanced Institute for Mathematics Statistics and Computer Science on 14 March 2015, as part of a workshop on Math, music and nature.

Some years ago, I had a change of perspective on being vegetarian. The fact that I am a vegetarian was not the thing that changed, but it was the why that did.

try-catch-finally style error management is common in many programming languages. Though the underlying mechanism of propagating errors up a “call stack” is alright from a development perspective, the common syntax ends up invariably mangling the code flow. In cspjs, a macro library presenting an easy-to-use syntax for working with async Javascript code, I attempted what felt to me to be a better way to fit error handling and recovery code into the statement-by-statement sequential flow of activity.

In Bye Bye Javascript Promises, I intended to present this key reason why I wrote cspjs - error handling and recovery specification that respects code flow - but I didn’t do a good job of presenting it. I attempt that in this post.

I’d written quite some time ago about seriously giving biking in Chennai a shot. I’ve recently joined Pramati technologies in Chennai and have been biking to work (about 9km one way) almost every day for the past month-and-a-half. Here are some observations and an initial attempt at guidelines for people considering biking as a means of commuting in Chennai.

Two common backends seem to be emerging that enable programmers to choose a language and system suitable for their work irrespective of whether they’re developing server side code or client side code. Programmers who develop services that sit behind communication protocols such as HTTP have always enjoyed the freedom to choose the programming language and system that best supports what they need to develop, because clients who use system requirements placed by these languages do not get passed on to clients who make use of these services. Client-side programmers have, however, had limited options when it comes to programming language choice for various reasons, the most significant of which is perhaps accessibility to APIs for doing various things on the client device. Hence if you program for iOS, pick Objective-C. Android? pick Java. Windows? Perhaps C# .. or F# if you’re adventurous. Web browser? You got Javascript. For once, two common performant backends - Java byte code and LLVM bit code - are emerging as the common ground enabling portability and hence programming language diversity.

In computer science literature, “garbage collection” refers to the process by which unused computer memory is reclaimed for use by a program. Such memory is usually referred to as “garbage” and the “garbage collector” periodically runs to do this job. Though I understand the process to some extent, I’ve never been happy with the metaphor since it doesn’t help at all with suggesting possible techniques for doing the task and is just used to label this part of a programming system with automatic memory management. In this post, I explore “dish washing” as a metaphor for the same process and argue why it is a better one to adopt for teaching purposes.

Recent writing in the field of ethnomusicology has re-asked the question of “what is music?”. Christopher Small coined the term “musicking”, which to me expresses that there is no such thing as “music” that is apart from the act of “musicking”. Music and mathematics have shared a historical bond with each other - with mathematicians finding fascination in musical patterns and musicians relishing in artistic construction using mathematical patterns, more recently involving computational patterns. The relationship that both these activities bear to the functioning of human cognition also share great similarities. Mathematicians have long declared the activity of “doing mathematics” as a creative process that is not steeped in certainties, as a naive view of mathematics might suppose. Paralleling that, musicians also often demonstrate intellectualization of the activity of musicking that resembles a mathematical theory of the constructs that they are building. In consideration of such deep connections, in this essay, I explore the parallel thesis - there is no such thing as mathematics, there is only mathematicking - and where I name the joint activity “mathemusicking”.