Beyond Dynamic Languages
Everywhere I turn, all I read about is dynamic languages. Apparently, there is a small yet growing contingent of programmers that think dynamic is the only way to go. These guys are frustrated with the shackles of static type systems that force them to write clean code. And apparently, there is also a small and growing contingent of media types that think “hey, there’s a buzzword I haven’t heard before, let’s use it until we wear it out.” And they have. Believe me, its paper thin and about to be ripped through like a rubber eraser pulling double duty.
However, I’m not here to debate the virtues of dynamic languages. Some of these languages have really cool features, but that’s beside the point. It’s the dynamism that’s at issue and for some purposes dynamism is simply the better model. When you are dynamic you don’t have to know upfront the correctness of any particular thing. You just do what feels right and let the runtime figure out the rest.
That’s why I’m here today advocating the next logical step. It’s not enough to simply have dynamic languages. Sure, they make some of your programming tasks a bit easier to perform, but how much time do you spend programming anyway? Most developers produce on average one line of quality code per week. It’s not that they are lazy; it’s just that the ‘coding time’ turns out to be a small fraction of the overall product cycle.
So as you can see, what we really need to do is to take the advancements that dynamism brings to programming languages and apply them to those other things that busy your day.
Dynamic Meetings – Don’t plan specific meetings with agendas. Just show up in a meeting room at the same time everyday. It doesn’t have to be the same room, just pick one at random. At five after the hour, go around the room and ask each person that happened to show up in the same room as you what they’d like to talk about, write it down on a whiteboard in some order and then have at it. It doesn’t matter if you don’t have enough context to have a meaningful discussion. No one is listening anyway. It’s a good meeting if someone spontaneously decided to bring donuts.
Dynamic Design – This works best as part of a dynamic meeting. Take notes, but not too many. You wouldn’t want to fence your ideas in too soon. Doodling helps the creativity flow; be sure to use multiple colors. Don’t worry about getting agreement or buy-in from others, they aren’t paying attention anyway. They are working on their own ideas and drawing their own cartoon stick figures. When you think you’ve got a good concept, go away and write some code. Eventually, everyone will figure out something to do and will be busy writing code too. Don’t worry about integrating it all together. Its all just code, ones and zeros, adds, shifts and branches. The runtime knows what to do with it.
Dynamic Testing – Don’t make a plan. Don’t do code coverage, write unit tests or abide by any particular testing methodology. Let the runtime do it for you. Just load the program in ‘Test Mode’ and execute. The runtime will proceed to apply a series of random tire-kicking algorithms that will give the dynamic code a good workout. Believe me; you couldn’t have planned it anyway. With dynamic code you’re never quite sure what it does until you run it.
Dynamic Debugging – Yes, even dynamic programs will have bugs, though you might not ever know for sure. If you think the code is acting flaky, you may want to do something to fix it. It will probably mean looking at the code or some facsimile of it in some tool that will help you understand it. The old-school way would have been to use a debugger, set some breakpoints and walk through it, observing the behavior, looking at variables, etc. But that would require too much static knowledge about the code, things like specific variables, types, and ‘lines’. Since we’ve done away with these antiquated notions we’ll need a new style debugger that will help us deduce the problem without actually using any particular facts, a precognition engine if you will that uses advanced artificial intelligence techniques to divine the future. It’s either that or printing out text.
You see, if we take dynamism just one step further, we can vastly simplify the work we do now, by offsetting the part about doing a good job and getting it right until sometime later when hopefully we've moved on to another project.
But I digress
Matt
Comments
Anonymous
April 28, 2006
I have seldom read such an astoundingly ill informed post.
What makes you think dynamic typing stops you writing "clean code"? Type declarations and casts create a lot of duplication and noise in poorly designed statically typed languages such as Java, C#.
But the following sentences really take the cake:
"With dynamic code you’re never quite sure what it does until you run it."
"Yes, even dynamic programs will have bugs, though you might not ever know for sure."
Do you really think that a static type system can tell you that your program doesn't have bugs?
"[A debugger] would require too much static knowledge about the code."
No, a debugger needs dynamic knowledge of the code because it's inspecting it at run-time.
This post is a perfect example of why my work has such problems hiring .NET developers -- they are almost all entirely clueless. Even worse, they are proud of their cluelessness.Anonymous
April 28, 2006
Mat, dude... you've got to seriously chill out!! This post was one of mattwar's typical humorous entries (it's filed as such).
If you take this entry seriously, I shudder to think of how you would intepret his entry on Microsoft's new YODA programming language ;)
(http://blogs.msdn.com/mattwar/archive/2005/10/09/479008.aspx)Anonymous
April 28, 2006
Haha, Mat, you're the clueless one here ;)Anonymous
April 29, 2006
I completely agree with you Matt.
This reminds me of the time when people used to think goto statements were the most powerful thing ever.Anonymous
April 29, 2006
goto's still are the most powerful thing ever. A function call is just a goto with a round-trip ticket.Anonymous
April 30, 2006
I wouldn't call it a small contingent.
Consider nearly every scripting language out there, particularly Python, which has a fairly strong following dating back years. Python was my favorite language until I learned C#, actually, and I still recommend it to new programmers.
In fact, I'd say the dynamic camp is not merely non-small, but that most people carry the secret, guilty desire for more dynamic language features in their lives. Why else do we have a reflection API and (now) Lightweight Code Generation?
And, you note, C#3 and VB9 are exposing at least some aspects of them ...
... In a statically typed way, of course.
(otherwise funny post, btw)Anonymous
May 01, 2006
I know this is supposed to be a humorous article, but it's about as funny as "You silly Germans! How can you put a car together with tools not labelled in fractions of an inch?!"
Obviously you don't like dynamic languages, but learn a little about them before publicly talking about them. I've seen incomprehensible Perl code, and I've seen incomprehensible Java code (great steaming piles of it), so what?Anonymous
May 01, 2006
After LISP, no language has been pleasing to me. I just want to go back to the deeply nested parentheses. Give me back my EMACS!Anonymous
May 01, 2006
WM_LOLAnonymous
May 02, 2006
The comment has been removedAnonymous
May 03, 2006
SmallTalk anyone?!?! ;-)Anonymous
May 04, 2006
Someone should make a SmallTalk clone named ChitChat.Anonymous
May 05, 2006
The comment has been removedAnonymous
May 05, 2006
Great! Now I don't have to write the contra post and I can focus all my energies on my stand-up routine.Anonymous
May 07, 2006
One small comment. Why must every tool be compared each other. Dynamic languages had a well established place.
The real goal should be to incorporate the most useful features of dynamic languages into statically typed language to increase productivity.
There are no real opponents here, the winner should be the human programmers, not the tools.Anonymous
May 08, 2006
The comment has been removedAnonymous
May 08, 2006
The comment has been removedAnonymous
May 10, 2006
Language is context based (dynamic) and static. It seems to work well for us.Anonymous
May 10, 2006
Matt, have you gotten yourself into one of those unlimited R&D roles with no budget limits jobs?Anonymous
May 10, 2006
The Sky.NET is the limit! The code is done. Now to just turn it on.Anonymous
May 10, 2006
The comment has been removedAnonymous
May 11, 2006
As both a C++ (static) and Python (dynamic) expert I can tell you that the difference lies entirely in the fact that C++ is 10 times quicker and with Python you spend 10 times less for coding the same WELL working code.
Python has excellent support for unit testing and lets you test every class in an extremely simple way - thats why I am sure that everything works with Python while I am not yet in C++ without lint...Anonymous
May 25, 2006
I didn't even finish reading the post man, you definetely need to to get that anger and frustration out of your system. Want to see if dynamic languages are worth it? Try IronPython or the new Ruby implementation for the CLI. But if you just can't stay away from strong typing then you are better off coding in assembly or even better, straight binary for crying out loud.Anonymous
July 17, 2006
PingBack from http://blorgh.wordpress.com/2006/07/17/matt-does-not-like-dynamic-languages/Anonymous
June 02, 2007
Veg, in case you missed it, you get burgers (with meat or not) in Ruby and binary, assembly, types and more is still the language your programs indirectly writes. Great blog Matt, might even get me to use this dynamic RSS thing or hey why not ATOM-hammer (Sattelite from random electronics and intertwingly approach ). Had a great laugh looking at script kids get their frustration and enthusiasm out.Anonymous
September 26, 2007
最近似乎有一种类似混乱的观点提出，说.NET的未来是转向DynamicLanguages，你看LINQ就是基础，C#3.0,VB9的某些特性无非是很久之前许多DynamicLanguages...