Think of Dynamic languages like riding a bike.
Sure, you only have two wheels,
But what you propose is like keeping the training wheels on full time.
When some experience will show, that after training,
You can ride better without them.

s/Dynamic languages/Languages with pointers/
s/Dynamic languages/malloc()+free() languages/
s/Dynamic languages/Assembly language/

All of these are Real Programmer fallacy arguments.

Real Programmers don’t like it when computers solve problems for them. Where’s the thrill in that?

First of all, you seem to be reading this post as a static typing vs. dynamic typing argument. It’s not. It’s simply showing some of the features of static typing which aren’t usually part of the conversation around type systems.

Second, you’re basically saying that you are callous to the ways in which dynamic typing brings in accidental complexity to your system. That’s not a surprise: everyone gets comfortable with their ways of coping with life’s difficulties, and then it’s “no big deal”.

This habit includes Java people, BTW. I once showed a Java person this bit of Groovy:

class Foo {
  int bar
}

That code translates (handwave) into the following Java:

public class Foo {
  private int bar;
  public int getBar() { return bar; }
  public void setBar(int newBar) { bar = newBar; }
}

We’re talking half as much code in Groovy vs. Java. That’s a huge win, and I was expecting them to be dutifully impressed. They weren’t, though, and their response kinda stunned me: “Oh, you just use the IDE to generate that. That’s not really a problem.”

1) Good Information to learn what read evaluate print loop actually meant and nice to see a statically typed language with this.
2) This is a non-point in reality for careful coders as they check for explicit 0’s NUL’s and Falses (unless they are using a language where there is no difference like C). Treating NUL, 0 and False as the same unless they really are is a horrible practice that no-one should indulge in even if the language foolishly lets you.
3) This is also a non-point for careful coders. A careful coder would never employ duck-tying on an object unless they knew it really did behave like the object the code was expecting. I never once had a problem with this, there wasn’t any need to write tests because if I wasn’t 100% certain I wouldn’t use duck-typing.If you need this security you’re doing it wrong. However it was nice to see that you can do this in a statically typed language too.
4) Completely agree, I’ve always just called them API’s.
5) More feature-abuse, lambda’s are Ruby’s real closures and you can pass as many of them around at once as you like.
6) I like OCaml’s syntax, but once again you are going on about the safety of static typing. You wouldn’t go poking around with the ports responsible for reflashing BIOS in C and so long as you follow simple rules while using dynamically typed languages then it’s really a non-issue. In fact, the only type problem I have ever, ever come up with in dynamically typed languages is trying to use reserved words as variable names when I was new to a language and passing the words around instead of the variable I wanted to. Obviously this only happens when you are a newbie to a language and are bound to make mistakes, whatever language you use.

7) This point is also about gaining a type-safety feature that just isn’t necessary unless you write sloppy code.

Your post was interesting, but you could have called it instead “Why you should use a statically typed language if you are unable to control yourself and not abuse the features of a dynamically typed one”.

I don’t understand why people find it so hard to not abuse these features, I really don’t. I don’t take shortcuts like importing things from other namespaces into mine to avoid typing a few extra letters, I always make exclusive checks (if a is nil/nul(l)/none) in flow control statements rather than ambiguous ones (if a then …), and provide an “else” clause to catch results that should never happen anyway. And I never experience this pain statically typed language enthusiasts think I must do, or have to write these tests as the scenarios they dream up cannot happen in my code.

It’s worth mentioning I grew up on statically typed languages. The only major benefits I can think of for them are:

1) When you have to write code to work with other peoples code and the organisation you are part of is run and staffed by idiots who won’t accept that sloppy code is not OK. I’ve never had a problem with this but I can imagine if you are prepared to work just anywhere it’s a big deal for you (personally I’d rather work in the fields doing labour, than work for a poorly managed IT department that also won’t let me shape policy, in fact, that only just beats out McDonalds for me).

2) The awesome code completion and refactoring you can get in statically typed languages that you just cannot (practically) have to the same level in dynamically typed ones.

All the other ones can be solved by not rm -rf’ing your codes chances at life with lameness.