|
I have been writing Node since late 2009 and Javascript with Rhino before that and Javascript with Rails before that. Before Node, I was used to linear program execution and was hesitant to switch to writing asynchronous code. My mental model of code was one-dimensional: do this, then do that, then do that. So I was used to exception handling for errors, and my programs were like trains on a track. This was a comfortable abstraction, but the way in which my programs were written did not reflect what they were doing in the real-world: reading from disk, reading from the network, waiting for something, doing something, responding to something, receiving something in chunks. Now, looking back, I prefer writing code that reflects what my programs are doing. There is more headspace, another dimension, no longer one thing after another, but a stack of things hovering and happening at the same time, interacting with each other, moving forwards through time. Now, instead of trying to make concurrent work appear non-concurrent, I prefer to embrace concurrency and see how I can write for concurrency. This is almost certainly different to the way in which I would have written synchronous code. Code for me is less complex now and shorter now than when it was synchronous. It feels richer and more descriptive of the work being performed. It's also faster and more reliable. In essence, I have learned to write better concurrent code. |