Adam Hathcock’s Life in Software

Oh, right—sorry, I forgot. That devil will whisper, "You know, if you write this code in Visual Basic .NET, you can make the entire codebase Option Strict Off and Option Explicit Off, make the compiler shut up and you can go home early...." Hell, they've been whispering that bit of subversion since 2001. And ye Gods! The leveled cities! burned forests! cute little kitten bodies! all over the place! It's fortunate that we C# developers have kept all those Visual Basic developers on the straight-and-narrow path of true salvation static typing.

Maybe I am a static-typing fundamentalist, but you cannot say that the "dynamic" keyword in C# should be used in anything except Javascript/COM interop situations (okay, there are probably others, but it is a specialized case).

The author argues (and whines) that VB (something else I wouldn't hang my hat on) made people much more productive than C++. It did, but they had worlds of differences between them. VB.NET and C# have near zero. C# just shouldn't have dynamic/duck typing. If you want that, THEN USE ANOTHER LANGUAGE.

At least, he concedes there are different tools for different jobs. Unit testing is an area that a dynamic language excels in. I simply hate using a loosely typed anything in any kind of project that involves more than one person. Tribal styles of coding develop too easily.

Dynamic languages have their place. Just not in my C#, thank you.

Lately, I've been trying out some of the new .NET 4.0 language features.  Specifically, I've been looking into ways to trivially combine late dispatch and late binding in order to build general purpose convenience objects.

The usage of dynamic feels so wrong in this example. I guess I don't see the purpose of this. To be more like javascript? No thanks.

I've seen this meme come out of programmers more and more and it just doesn't seem accurate.  The statement goes something like this, "Design Patterns were only useful because C++ (or Java) was so broken.

Steve Rowe brings up the fact that most design patterns were thought of in the Smalltalk community. The big bad ass where many things OOP and Dynamic were created first.

I hate to sound like a old man telling kids to get off his lawn but the advocation that dynamic languages FIX the need for the Gang of Four design patterns seems so teenagerish.

Does Python really know everything and can do everything better? Well, it can write easy test cases.

I know that dynamic languages like Ruby and Python give you things that you can't get  with languages like C#, and as a SOLID advocate those things seem important, but... why do I go cross-eyed when I read Python and Ruby examples?  

The quote right there is from the first comment on the article.

The article is actually decent and well-written. It's just the flaw is that it's advocating dynamic languages. I get how "monkey patching" is great for testing. But having to read and understand a large project in Python would make me go cross-eyed too. Dynamic languages are anything but well-defined.

Dynamic for test: YES
Dynamic for real world projects: NO

I think I agree that IoC in dynamic languages are silly. I also think that if you're doing a project that may require IoC with a dynamic language, then you've picked the wrong language.

Dynamic languages, to me, are domain specific and should be used minimally. I've spoken of this before but strong-typed languages give you well-contracted designs and can be the most explicit about the usage of the code.

Dynamic languages have their usages (i.e., quick and dirty projects, using them to write tests) but shouldn't be used for heavy lifting where an IoC container would live.