I'm James Hague, a recovering programmer who has been designing video games since the 1980s. This is Why You Spent All that Time Learning to Program and The Pure Tech Side is the Dark Side are good places to start.
Where are the comments?
Dynamic Everything ElseStatic vs. dynamic typing is one of those recurring squabbles that you should immediately run away from. None of the arguments matter, because there are easy to cite examples of big, famous applications written using each methodology. Then there are confusing cases like large C++ apps that use dynamically typed Lua for scripting. And right about now, without fail, some know-it-all always points out that dynamic typing is really a subset of static typing, which is a lot like defining a liberal as a conservative who holds liberal views, and nothing worthwhile comes from this line of reasoning.
I have no interest in the static vs. dynamic typing dispute. What I want is dynamic everything else.
Sitting in front of me is a modern, ultra-fast MacBook Pro. I know it can create windows full of buttons and checkboxes and beautifully rendered text, because I see those things in every app I use. I should be able to start tapping keys and, a command or two later, up pops a live OS X window that's draggable and receives events. I should be able to add controls to that window in a playful sort of way. Instead I have to create an XCode project (the first obstacle to creative fiddling), compile and run to see what I'm doing (the second), then quit and re-run it for each subsequent change (the third).
There's an impressive system for rendering shapes and curves and fonts under OS X. Like the window example above, I can't interactively experiment with these capabilities either. I end up using a vector-based image editor, but the dynamism goes away when I save what I've created and load it into a different app. Why must the abilities to grab curves and change font sizes be lost when I export? Why can't the editing features be called forth for any image made of vectors?
I know how to solve these problems. They involve writing custom tools, editors, and languages. Switching to a browser and HTML is another option, with the caveat that the curves and glyphs being manipulated are virtual entities existing only inside the fantasy world of the browser.
That aside, it is worth taking a moment to think about the expectations which have been built up over the decades about how static and inflexible most computing environments are.
Code is compiled and linked and sealed in self-contained executables. There's no concept of live-editing, of changing a running system, or at least that's relegated to certain interpreted languages or the distant memories of Smalltalk developers. Reaching for an open source JPEG library is often easier than using the native operating system--even though the OS is clearly capable of loading and displaying JPEGs--especially if you're not using the language it was designed to interface with.
We've gotten used to all of this, but there's no fundamental law dictating systems must be designed this way.
(If you liked this, you might enjoy The UNIX Philosophy and a Fear of Pixels.)