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 (27)

  1. Mat says:

    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.

  2. JJ says:

    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)

  3. Pon says:

    Haha, Mat, you’re the clueless one here 😉

  4. Z says:

    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.

  5. goto’s still are the most powerful thing ever. A function call is just a goto with a round-trip ticket.

  6. Keith J. Farmer says:

    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)

  7. Joe says:

    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?

  8. 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!

  9. A content-free zone in which spew triumphs over flow, cliches triumph over insights, and the stream-of-consciousness has some very strange things floating in it.

  10. SmallTalk anyone?!?!   😉

  11. Someone should make a SmallTalk clone named ChitChat.

  12. Helge Jensen says:

    Static meetings: To optimize the meeting participants exchange vow’s of metting compliancy. After this initial optimization-pahse the group is free to talk about anything that the meeting was explicitly on the agenda priorly agreed upon.

    Static Design: Sit down and plan everything before writing a line of code. Who ever heard of experience making a contribution? This radically improved method of design ensures that everything is set in stone after the first few initial months or years of planning in the aptly named "The Master Plan".

    Static testing: If it compiles it *must* work. That’s what the type-checker is for! No need to write tests. If you have *co-workers* who sometimes introduce bugs, run their code through the type-checker, that’ll catch it for sure!

    Static Debuggig: Debugging, HAH! the type-checker catcher every bug in the world. Those hours sweating over adapters, casting and the duplication of the set of classes into interface declarations really pays off here!

  13. Great! Now I don’t have to write the contra post and I can focus all my energies on my stand-up routine.

  14. Fallon says:

    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.

  15. Romulus says:

    Can the Dynamic Language technique be applied to a hardware application, though?  Suppose I had just some random junk lying around — could I apply these techniques and make a crude Satellite  Tracker from a old camera light and a shoebox full of random electronics?

  16. You forgot the old joystick parts.

    — Remus

  17. Jerod Moemeka says:

    Language is context based (dynamic) *and* static.  It seems to work well for us.

  18. Mike Griffin says:

    Matt, have you gotten yourself into one of those unlimited R&D roles with no budget limits jobs?

  19. The Sky.NET is the limit! The code is done. Now to just turn it on.

  20. Garry Trinder says:

    "Can the Dynamic Language technique be applied to a hardware application, though?  Suppose I had just some random junk lying around — could I apply these techniques and make a crude Satellite  Tracker from a old camera light and a shoebox full of random electronics?"

    MacGyver could 🙂

  21. C++Python says:

    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…

  22. Veg says:

    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.

  23. Firehose says:

    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.

  24. KidYang says:

    最近似乎有一种类似混乱的观点提出,说.NET的未来是转向DynamicLanguages,你看LINQ就是基础,C#3.0,VB9的某些特性无非是很久之前许多DynamicLanguages…