Hello Javascript Promises!

Wierd that I’d write a “hello” post on promises after I wrote [Bye Bye Javascript Promises!][bbjsp]. This post has a two fold agenda. One is to point out that I’m not against promises per se, and the other is to introduce something new in the JS world - well, the same old new - data flow variables, which was what promises used to be called.

cspjs has an experimental branch dfvars branch that introduces a syntactically simpler way to work with promises. cspjs could interop with callbacks, but ignored APIs being written using promises. Now it can also interop with promises in the dfvars branch and I’d like some feedback from the JS community on this.

Read on →

Errors, Recovery and Async Code Flow

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.

Read on →

Biking to Work in Chennai

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.

Read on →

Two Trends Towards Partial Programming Language Freedom Everywhere

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.

Read on →

Wash Dishes. Don’t Collect Garbage.

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.

Read on →
comments powered by Disqus