This post originated from an RSS feed registered with .NET Buzz by Darrell Norton. Original Post: Dynamic languages work closer to how you design software Feed Title: Darrell Norton's Blog Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx Feed Description: Agile Software Development: Scrum, XP, et al with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Darrell Norton Latest Posts From Darrell Norton's Blog

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:

1. They constructed a mental model of a proposed solution to the problem.
2. They mentally executed the model—in essence, running a simulation on the model—to see if it solved the problem.
3. 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.
4. 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:

1. Add or modify a few methods in a couple of classes
2. Open up a Workspace (Smalltalk’s REPL) and print out the results of some arbitrary code that tests what you just wrote
3. If you hit a bug, you can easily inspect any value in the entire system to find the error
4. 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
5. Repeat

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.