Yes, this is true, the dynamic language communities have compensated for the lack of a type system with explicit type checks (or type constraints) and lots of testing. But it's still nice to have a real type system (and I don't mean C or C++ or Java; those languages also have no type system). When I compile a Haskell project successfully, I have a reasonable belief that it's going to run to completion and at least produce some sort of result. The same is not true of Perl, even with lots of tests, my programs almost always die in the middle (during development) where a runtime type check or assertion fails.<p>The reality of programming is that all functions and variables have types. If you add 42 to "hello world", you get garbage. In dynamically typed languages, you keep the types in your mind -- you know that the variable you are adding 42 is a number. In statically typed languages, you tell the compiler. The second way lets the computer do some of the work for you (ensuring that if you use the variable like a string, your program won't compile), the first way requires you to do everything. If you aren't careful, you get the wrong answer or a runtime error.<p>I think dynamic typing was a nice way for the programming language community to realize that C's type system sucked, but it isn't the ultimate answer, it's just a stopgap. It's also good that people realized they needed to test their code automatically; but that works <i>even better</i> with statically-typed languages.<p>Anyway, I am not going to give up Perl anytime soon, but I secretly wish it wasn't dynamically-typed.
Good point, but the debate is still in the "C++ vs Python" bounds. Haskell has Hindley-Milner and Quickcheck and I think the debate is elsewhere: the cost of abstractions and tools (just read another doc/paper to understand how to do this) but also their benefits (scaffoldings and cranes while programming).
I ride a bicycle in the city with a helmet, knowing that I do it in order to ride a little more dangerously. It gets me where I'm going faster. When I'm without a helmet in the city I ride very defensively.<p>I use Python and I'm very slowly getting into Haskell, I don't have much experience with static typing, but I think that the analogy will apply when I get used to it. I enjoy the safety net so that I can, in fact, be a little more reckless in my coding. Experiment a bit more, get things done a little faster, etc.
Regarding the anecdote rather than the meat of the post, I drove for years under all conditions without anti-lock brakes. These days, I still find myself occasionally fighting them. I know very well how to control the car, including through controlled skids, and that's worked its way deep into my reactions. In extreme situations, the anti-lock brakes still sometimes throw me off and slow my overall reactions, as I have to pause and adjust to their presence. I also simply cannot perform some -- often useful -- maneuvers with them that I can on a vehicle not having anti-lock brakes.<p>So... I can imagine some of the cab drivers, with years of driving experience, having some difficulty adjusting to the <i>difference</i> that anti-lock brakes make, with a corresponding increase in effective reaction time and with perhaps a surprising inability to negotiate risks as they have previously learned to and expect to.
This is true for "average drivers". The math is totally different with, say, racecar drivers.<p>I think there's a strong parallel with programmers here, and whether you're optimizing for average-case job throughput (or hobby throughput) or whether you're optimizing something specific where safety or reliability is specifically important.
The comparison of static typing to anti-lock brakes is a bit off. Anti-lock brakes are more like the function of an optimizing compiler (JIT or otherwise). Unless you're on-top of your game all the time and have race car driver-like reflexes, you can't beat it.
I worked on a 20 KLOC app of mine yesterday that has neither static type decls or unit tests and yet is AFAIK bug free. This has been the rule and not the exception in my experience. So I prefer to not have them since <i>in the general case</i> they are not needed and just add clutter and drag.