Language Rants: Weak Typing and Misc.


Originally posted: July 4th, 2007

(Note from July 2010: Yes, I know I refer to dynamic typing as "weak typing" here. "Weak typing" includes more than just C's implicit reinterpret casts. Dynamic typing IS a form of weak typing: deal with it.)

Years of condemnation to the seething underbelly of the programming world known as "web application development" has driven me to this plea:

Please, for the love of god, no more weak-typed languages!!! I can't take it anymore! That includes you too, duck-typing. (Yes, I realize many of those languages optionally allow strong types, but that's just a bandage, and often an afterthought.)

Here's the generalized rule of thumb these weak-typed languages are breaking:

Anything that CAN be handled at compile-time, SHOULD be handled at compile-time.

(Obviously, I'm counting "parsing interpreted-language code" as compile-time here.)

Why is this a good rule of thumb? For one thing, optimization. If you offload certain calculations (such as arithmetic on numerical literals, ie '2 + 3′) to the compilation process, then your program doesn't have to, thus speeding it up. Fortunately, this sort of thing is already handled by most compilers, so you don't have to worry about it. (If you're wondering: yes, I have come across one notable exception: SPIN)

But there's another more important reason for this rule of thumb: Bugs. Bugs are bad. There are two types of bugs: compile-time bugs and run-time bugs. Compile-time bugs are always brought to your attention automatically, whenever your code is compiled. That makes them easy to fix. Good bugs. Or at least as good as bugs get. Run-time bugs only show themselves if you're lucky. These bugs hide and fester. That makes them hard to fix. Bad bugs.

I don't like weak typing because, while it might seem to eliminate type concerns, all it really does is change the type errors from compile-time (good) errors into run-time (bad) errors. This may not be a problem when you're whipping up "Lil' Coder's First PHP Page", but when you have a full-blown web application to maintain, you'll just waste your time hunting down bugs that could have been pointed out to you the moment they were introduced.

Languages that religiously force everything into the latest silver-bullet paradigm have also got to go. I'm looking at you, Smalltalk and Java (Clarification: I like OOP. I don't like religious OOP.) Here's an excellent explanation of one of the reasons I can't stand Java.

As long as I'm ranting on languages, VB6 is obnoxiously verbose. (Yes, I know VB6 has been replaced by VB.NET. But I'm still condemned to it anyway.) Behold:

In most C-based languages:

int var = 5;

In VB6:

Dim var As Integer
var = 5

How clunky. I have other examples of VB insanity (yea, I know, who doesn't?), but they'll have to wait for now.

2 comments for "Language Rants: Weak Typing and Misc."

  1. 2007-07-20 07:00

    Chewychompy Says:
    July 20th, 2007 at 9:14 am

    vb.net

    dim poop as integer = 5

  2. 2007-07-20 07:01

    abscissa Says:
    July 20th, 2007 at 1:00 pm

    Yea, VB.NET is definitely a significant improvement over VB6 (The inclusion of array literals is another example that comes to mind). But there are still things I would change. For example, I still find the "dim" and "as" keywords to be completely superfluous. They just add verbosity to the language without actually accomplishing anything that, as C-based languages have demonstrated, can't be done with just a variable name and a type (True, using "dim" does allow variables to be declared as variant without explicitly specifying the type, but I consider it bad style to not explicitly state the type, or to even be using variants in the first place (I prefer templates)). I would like to see a new version of VB simplify the example you gave to just:

    poop integer = 5

    Or better yet:

    integer poop = 5

    There's two things I like better about putting the type first in declarations:

    1. It makes declaration-time assignments more clear. The "= 5″ part relates to the variable, not the type (you're not trying to set "integer" to 5), so it should be placed next to the variable name, not the type name.

    2. Maybe this is just the way my own mind thinks, but I usually know the type I need for a variable before I've decided what to name it. So I find putting the type first just streamlines the typing.

    All of that does make it into a very C-style assignment, so I guess that's not surprising considering that I am a rather C-camp sort of programmer. But I can go with or without a semicolon at the end: That's an issue I'm really on the fence about.

Leave a comment

Captcha