Alex Kessinger is a programmer who lives in the bay area. He is always trying to make websites, cook, and write a little bit better then he did yesterday. You can find more from Alex at his blog, on Twitter, and Google+.
Like you, I want to be a better programmer. It's not only my job to do so, it's something I have a deep desire to do. There are many ways to get better at programming, but the best way is to understand a new idea. This can be as simple as finding new code and fully understanding it. This small act can impart a new point of view.
When this happens to me I don't always recognize it on first use, because it can be a struggle to think from a new point of view. However, eventually I undergo a personal paradigm shift; and I will understand it. My brain will click with the machine-like inevitability of clockwork, and I will feel like I did something good. Experts call this flow -- learning something new puts me in that state, and the upward spiral repeats itself.
An example of this is the self-executing anonymous function. This is a pattern; it's an isolated chunk that can be learned. And, despite that fact that it's such an elegantly simple idea, there are a couple of ways to do it.
This simple pattern has many variations. Should we learn them all? Most people will learn one method, add it to their mental toolbox, and move on. This is good, and it should apply everywhere, not just to simple patterns like self-executing anonymous functions.
There is a lot of code duplication here. Sometimes it's work done without actually making the original much better. So, why are many of us compelled to do this? It's the same reason we have all done it -- the common illusion that we can make things better. We will always be able to write a better implementation of that framework, or this library; it's hard to stop listening to those urges.
Another reason we create is that learning someone else's code is almost universally distasteful. My first manager at Yahoo explained it best: "The reason all programmers hate other programmers' work is because you aren't those other programmers."
Before you tell me my position is too hardline: here is the caveat. You can't forget about innocent discovery. I can see someone screaming that a good way to get better at programing is to tackle hard problems, and even if you fail, you will learn something. It's hard to argue with that point, but what I'm talking about is every half-launched project on GitHub that purports to be the fix for every problem people in that domain are having. Registering unfinished projects with package managers eats away at all the meaningful package names.
Now, I know there will always be a reason to create. The hard route is to figure out how to use someone else's code. Try it the next time you decide to use a new library or framework. The best documentation is the source code itself.
dynamic approaches to API design -- especially from authors with a Ruby
or Lisp background. While it's possible to create your own languages
Objective-J -- this isn't always required. It's tempting to make an API
DSL-like, but are we better off using simpler, more established
Yesterday I wrote about a Sinatra-like library for creating super-simple
between URLs and HTTP methods. These definitions return a string. In
this case, the library implicitly returns -- you don't need to return
from the functions themselves. Matt
Brubeck noticed this and commented on the
"It's clever how they're using "eval" on the function body to save you
from typing "return", but is it really necessary?"
I think this was a great point. I try to err on the Douglas
eventually leading him to conclude the following:
found need to use an uber function. The super idea is fairly important
in the classical pattern, but it appears to be unnecessary in the
prototypal and functional patterns. I now see my early attempts to
As people experiment with novel uses of eval, new
Function and with over the coming years, will we
reach a similar conclusion? Is it worth creating rich and innovative
twists on what is possible or should we stick to straight-forward uses
of the language?