So, two years ago or so I started a project in the middle of my Master's -- not a great time to focus purely on that project. The idea was to replace Node.js's

So, two years ago or so I started a project in the middle of my Master's -- not a great time to focus purely on that project. The idea was to replace Node.js's callback hell with Scheme-type promises (i.e. deferreds), ideally preventing most applications from writing `function callback(err, value) {}` ever again. The Promise library was not bad and I might reuse it in other applications; it's only 250-ish SLOC if my memory serves me correctly. But I quickly realized when using it that the project could not live up to my earlier ambitions. The problem was that I hadn't foreseen the problems in not being able to overload JS operators: something like half of the Promise library just wrapped the JS operators, so that `this.gt(that)` becomes a deferred representation of `this > that`. This kind of worked, but I began to lose interest in this general approach when I started to struggle with how to idiomatically represent (a) variables, (b) if-then-else constructs, which are right now of the form promise.then(promise_if_truthy, promise_if_falsey), and (c) composite statements. Fortunately, I found the right thing to study, and off-and-on for the past year I've been studying it. The right thing to study in this case is Haskell, because the way that Haskell reduces 'do notation' to a pure sequence of function applications is precisely what you need above to solve (a) and (c) at least. Another idea was to take a revision control system like Darcs and try to move it, as much as possible, out of the realm of IO so that it could work on an arbitrary in-memory data structure as well. (I might then try to move it back into IO by storing the internal representations in a database, which would probably look a lot like a graph database or like Datomic) This is a great idea but it has stalled because the handling of dictionaries requires 'confluently persistent tries'. There's a great paper on these by Erik Demaine et al., where basically they make functional link/cut trees and build the system out of those, then optimize them to languages which aren't functional as well. I say 'there's a great paper' on it but actually that paper is an incremental result, not a tutorial -- so while it looks really interesting it's required me to learn a tremendous amount of new concepts before I can even implement it. What I am trying to say is this: is this a code addiction? Probably, but that's not why the projects are stalling. The projects are stalling because my Master's degree and interest in physics have become more important. Computer programming has only a second-order effect on the brain; the first-order effect is distractions. We should not write articles on the problems of being addicted to computer programming, the time I spent programming yesterday, while substantial, is about as long as I've spent typing this comment today. This comment (or other distractions which might replace it, TV or comparative religion podcasts or whatever) is more of the problem than the programming. I wish the things that competed for my attention had a simple ordering relation.