5 comments:

I got tweaked by this guy. I think he makes some valid points, and he made me think about what I felt about dynamic languages. So I've kind of been on a search to prove to myself whether my sense of Smalltalk, etc. is correct or not. I have been known to delude myself into thinking something is the cat's meow, when in fact it's good, but not great. I've been writing up my own programming problem as an exercise to compare Smalltalk to C#, and then I'll analyze the qualities of both. I think Kata 4, which is another link in the chain from what you link to, could be another one to try.

I agree with some of his criticisms of the things he quoted. I think the claim that programs written in dynamic languages are 80-90% smaller than those of conventional languages is an extreme one. I mean, you can get a 1:5 gain in some areas of a program, but not all. I'd say 50% smaller would be a decent estimate.

I think some of the Ruby quotes were overly exuberant as well. I can relate to them, but I agree with his criticism that when one has to make a decision about what technology to use, you need to put the passion aside for a moment and use some metrics to see what you'll really gain out of it.

The parts that tweaked me were where he said that dynamic languages don't really save you time or in lines of code. I thought his doubts about this brought up good questions in my mind, since my initial impressions of Smalltalk were that it does produce more "bang" per line of code. I realized I hadn't really proved that to myself.

An advantage of most dynamic languages he didn't even cover was you gain more powerful constructs.

What manifest static language fanboys always seem to miss, this guy included, is that programming in dynamic languages isn't just their existing style minus type declarations. Without types getting in the way, the style in which one writes code completely changes.

Even when not doing meta programming, ordinary constructs like functions become much more useful. Consider the following dynamic function and how many variants you'd have to write in a static language to achieve the same functionality.

function max(a, b){ return a > b ? a : b;}

In JavaScript, Ruby, Smalltalk, Python, we'd be done, this works for all cases and all types. In a static language, you can't do this without templates or generics and even then it might not be possible for all future types, so you end up with many different versions of the same function where the only difference is the declared input and output types.

Duck typing enables more than just less typing, it enable method level polymorphism which GREATLY reduces the need to repeat yourself just to make the damn compiler happy. That's where a lot of code reduction comes from, beyond the obvious runtime code generation meta programming stuff.

Generics give static languages much of the code reduction that dynamic languages enjoy, but favor the compiler, where dynamic language favor the developer.

Manifest static typing limits the mistakes you can make, but also limit you expressiveness in the process. Once you grow beyond making the silly mistakes, you start feeling restricted by static languages rather than protected.

Manifest statically typed languages aka Java, C++, C# are training wheels to protect you from yourself until you learn how to really program, something many programmers never actually learn.

Type errors just aren't the big monster in the closet they're made out to be and the cure (manifest typing) is most definitely worse than the disease. Most problems solved by manifest typing are caused by manifest typing.

Hi Ramon. I agree that Hacknot (the author of the article I referenced up top) doesn't get the advantages of dynamic languages. He prefers the security that a strongly typed language provides. I agree that it can start feeling like a straightjacket after a while. That's why I find this stuff exciting. I think there are some inherent assumptions in these languages. You have to understand what they are in order to be effective in them.

This is just me speculating, but I think the reason Hacknot doesn't see any advantages to dynamic languages is 1) he's inexperienced in them, and 2) he tries to use them like he would a strongly typed language, or tries to get them to act like one (which you can do, but it requires more code). He admitted he had written "a few utilities" in them. I doubt that's going to show their true power.

I disagreed with his tone. He gave no credence to dynamic languages whatsoever. He doesn't see the point. He conflates "intent" with a programmer knowing exactly what types a previous programmer's code would input and output. He says he believes in Design by Contract, which is a fine notion. It was pioneered in the Eiffel language, which is strongly typed from what I understand. I don't know what he's been programming in, but before templates came along in C++, and generics came along in .Net and Java, programmers frequently had to deal with not knowing what they were getting out of a container, because it would just come back as "Object" and had to be typecast.

Nevertheless, I thought he made some good points, and his criticisms brought up some good questions.