Some people I talk to have struggled with the usefulness of a dynamic language such as IronPython. To understand why dynamic languages are faster to develop in, let’s take a look at how developers design. Robert Glass, in his article The Cognitive View: A Different Look at Software Design, references studies that show that:
designers, mentally and at lightning speed, were doing the following things:
- They constructed a mental model of a proposed solution to the problem.
- They mentally executed the model—in essence, running a simulation on the model—to see if it solved the problem.
- When they found that it didn’t (usually because it was too simple), they played the inadequate model back against those parts of the problem to see where it failed, and enhanced the model in those areas.
- They repeated steps 1-3 until they had a model that appeared to solve the problem.
Now, look at what Benjamin Pollack does when using what he calls REPL in Smalltalk:
- Add or modify a few methods in a couple of classes
- Open up a Workspace (Smalltalk’s REPL) and print out the results of some arbitrary code that tests what you just wrote
- If you hit a bug, you can easily inspect any value in the entire system to find the error
- Once you find it, make the change, massage any “damaged” data back to pristine state by hand using the Workspace, and then resume execution where the breakpoint happened to see whether your fix worked
If you map steps 3 and 4 in the second list to step 3 in the first list, they are almost identical!
So developing in a dynamic language (or at least a well-constructed dynamic language) works closer to how you think. And since the essence of software development is design, removing artificial barriers to understanding helps you develop faster and/or with higher quality.
I’m not advocating throwing away .NET or Java, but for solving business problems, when I want to focus on the domain problem and not the implementation in curly braces, End If’s, or angle brackets, dynamic languages are a (good) answer.