In fact, 9 years ago, a man by the name of John K. Ousterhout, foresaw the industry moving toward the use of scripting languages. He wrote an article for IEEE entitled: “Scripting: Higher Level Programming for the 21st Century”. In it he explains why “system” languages should be come less prominent for common use than scripting. His argument is that as more and more coding frameworks become available, more programming work will be “gluing” existing code together. The need for developing a system from the ground up will diminish. Nine years later with the existence of huge frameworks such as .NET, it appears that he was right.
Dr. Osterhout is not just your average programmer. After receiving his BS degree in physics at Yale and his PhD in Computer Science from Carnegie Mellon University, he became a Professor of Computer Science at U.C. Berkeley, and a Distinguished Engineer at Sun Microsystems. He created the Tcl scripting language.
He clearly recognized the potential dynamic languages held when he said:
“I hope that the programming language research community will shift some of its attention to scripting languages and help develop even more powerful scripting languages for the future. Raising the level of programming should be the single most important goal for language designers, since it has the greatest effect on programmer productivity; it is not clear that strong typing contributes to this goal.” (John K. Ousterhout, Scripting: Higher Level Programming for the 21st Century)
Then there’s Robert C. Martin of Object Mentor. Robert is the founder of Object Mentor and the author of several agile software books and software craftsmanship articles. He is a highly respected agile development mentor. The interesting thing about Robert C. Martin was that he was a proponent of statically typed languages until he started using test-driven development and re-considered his position. He realized that the use of test-driven development completely changed his view:
“I thought an experiment was in order. So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose. My unit tests kept my code on the straight and narrow. I simply didn’t need the static type checking that I had depended upon for so many years. I also realized that the flexibility of dynamically typed languages makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler.” (Robert C. Martin, Are Dynamic Languages Going to Replace Static Languages?)
Bruce Eckel agrees with Robert C. Martin. Bruce questions the basis for thinking that strong typing is what is needed for better programming by exposing the fact that compiling your software in a static language shouldn’t deceive you into thinking that you have bug-free code without actually writing the tests that prove it.
“But without a full set of unit tests (at the very least), you can’t guarantee the correctness of a program. To claim that the strong, static type checking constraints in C++, Java, or C# will prevent you from writing broken programs is clearly an illusion (you know this from personal experience). In fact, what we need is Strong testing, not strong typing.” (Bruce Eckel, Strong Typing vs. Strong Testing)
“A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.” (Paul Graham, Hackers and Painters)
Could it be that developers need the space to develop their thoughts? Could it be that restricting them at the language level is not only ineffective as Bruce Eckel says but that it also interferes with their ability to produce creative solutions as Paul Graham implies?
For those of us who practice test-driven development, Kent Beck sees how static typing actually interferes with the process of programming test-first by requiring you to assert what you are not yet sure about:
“The problem with types is that they force you to say things that you don’t know are true, just to get the compiler to bless your program. ‘Here is the interface between these two objects’ is a good example of the kind of thing you are forced to say before you know it’s true. The interface between two objects invariably changes. I like not having to specify it when it is sure to change. Instead, I can say ‘This object needs an object like that in order to work’. I know this is true (for now) because the code demands it. When the code changes and the interface changes, I change the code (which I know needs to change), but I don’t have to change anything else.”
Clearly there is expert opinion out there that considers dynamic languages to be beneficial, especially when practicing Test-Driven Development. Hearing the opinion of experts is one thing, but trying it for yourself is another. I highly recommend that you try it, preserving your final judgment until then.