In defense of strong types

Anyone who knows my coding style probably thinks I'm going to completely contradict my title.  Nope.  I've found a new appreciation for strong checking [0], if only a little bit.  As it turns out, the additional security found in strong typing can be a cure for my least-favorite part of programming - those that absolutely shouldn't be programming at all but still managed to get higher-paying jobs than me.

Those in the strong typing camp claim that their method helps produce better programs, thanks to the additional compile-time testing.  This is absolutely true, and helped me find a handful of errors back when I wrote Java on a regular basis.  The trouble is, this extra security comes at the expense of language verbosity (ArrayList<String> stuff = new ArrayList<String>(); anyone?).  Being a liberal when it comes to programming, I prefer to have a concise language that allows for rapid prototyping and development.  This does create errors but not nearly as many as my CS Professor would predict.

Of course, this entire entry depends on strong typing being used exclusively as a sort of baseline test (My freshman mantra: "It compiles!  Ship submit it!").  It's not, I know.  Compiled, strong languages do have significant speed improvements over "lesser" languages like PHP (Others say that speed of language usually isn't nearly as important as speed of development).  However, strong typing does act as a rudimentary test.  Whenever a variable is declared, there's a "test" to ensure that it's correct, otherwise ERROR.

Liberals argue that this provides false security.  "How can we tell if the variable's value is correct, not just the type?  We need more tests!"  In either case, more tests are needed.  If you're building something significant, you need tests.  Liberal programmers are free to throw caution to the wind and depend on their own tests, claiming that the time lost to writing tests is made up by writing in a simpler language.  (I haven't found any studies to back this up, I'd love to hear it if you've got one).

So far, I agree with the hippie liberals.  It's much better to write your own tests to determine what's going wrong.  Who knows your code better: You, or a compiler?  Using strong typing for testing purposes also breaks separation of concerns, but that's a nitpick.

If you can't tell, I don't really like strong typing.  Oddly enough, I also don't like it when a program doesn't fail on what should be an error, but continues soldiering on with weird results.  (thank heaven for 'use strict';).  Back to where I was: People who get paid more than me to write terrible code.

It's a sad reality that there's a huge amount of terrible code out there.  A large portion of this code is glue between several plugins mashed together into a "website."  Scary.  However, strong typing (thanks to that very breaking of separation of concerns) forces basic testing onto whoever is using the plugin/API. The "programmer" (and I use that term loosely) must provide semi-correct data.

Of course, those who write glue code are looking for the easiest plugins to steal use.  Ones that force them to provide better code will be dumped by the wayside by both glue coders and higher quality coders with liberal leanings, so this is mostly a pipe dream.  (Conservative coders will already be working in a language with strong typing.)

So strong typing is bad because it forces you to write extra code that amounts to more tests that you'll have to rewrite anyway.

[0] In this case "strong typing" means that the language gives an error if a variable is of a type that wasn't expected.  This means that the programmer