4 ms·
People tend to pick one side or the other of this issue and then argue for it. It's rare for anyone to change their mind, and even when they do, it's usually ju
by gruseom 17y ago
People tend to pick one side or the other of this issue and then argue for it. It's rare for anyone to change their mind, and even when they do, it's usually just a boolean toggle to the opposite position. Most people believe (even if they don't say it) that the opposite camp is, basically, stupider.
The entire subject is remarkably evidence-free. That's surprising; you'd think (on the surface, at least) that it could be studied objectively. Of course, we all have our individual experiences as programmers, but those aren't worth much as evidence, because we interpret our experiences to suit our pre-existing belief. Indeed, we don't even notice experiences that contradict it. (I've seen static typing proponents go on about how compilers catch bugs and then spend hours tracking down an InvalidCastException.)
In light of the above, I'm more interested in hearing what people have to say in favor of the position they disagree with. The debate is too tiresome otherwise, entirely predictable.
Although I currently favor dynamic languages, I recently started the thought experiment of asking myself, when fixing a bug, whether a good type system would have caught it. Certainly there are times that the answer is yes (though not always). The difficulty, of course, is whether the aggregate benefit would outweigh the cost.
- strait 17y agoThat the subject is remarkably evidence-free reflects on the evolution of computing technology that's cascaded all the way up to the way we program at the highest level. We're so adept at noticing the differences between static typing and dynamic typing, but evaluating them much more objectively inside the entire computing environment context is like comparing two heaps of random trash and trying to decide which pile makes the best art piece. How is that for an evidence-free assessment? :)
- gstamp 17y agoThe problem is obtaining this evidence is really hard. So many considerations are involved during the coding of a non-trivial system. It's hard to isolate all factors involved. I remember code complete presenting some evidence that 100-200 line functions are the best size but how true is that really? What consideration does language have on that? Most people these days would see that functions that size as way too long.
- nostrademons 17y agoI don't really have a strong preference either way. The bulk of my professional work is in JavaScript with a fair amount of Python and C++ thrown in. I dislike the C++, but that's probably because the type system is brain dead rather than because the type system is static. I do most of my hobby hacking in Haskell, which has about the strongest type system imaginable. I'm hacking on a programming language of my own design, which will have static typing, but not to catch errors. I want static type inferencing because it lets the compiler generate usable, machine-checked, cross-referenced, auto-updating documentation from my source code, without having to update this myself. I've found that I rarely have type errors in dynamically typed languages, as long as I program as if they were statically typed. For example, if my JS function only takes strings or objects with certain fields, I just document those and I almost never make mistakes with them. However, if I start defining functions that return string|int|bool, then I start getting confused. Do this often enough and it becomes essentially impossible to reason about my program. Ironically, I've found that a good portion of my bugs in statically typed languages are type errors, in the form of null pointer exceptions. Haskell's Maybe type is the way to go here; yeah, it makes looking things up in a dict inconvenient, but I can't count the number of bugs I've avoided by being forced to deal with nulls up-front and not having them pollute the rest of the program.