I see that Larry O'Brien is using argument by assertion this month in SD Times:
I've previously talked about how explicit versus implicit typing is inserted too often into the entire debate over dynamic languages ( Ignoring the Scripts, Feb. 1, page 29). In an explicitly typed language, the programmer must state that foo is an integer before assigning foo the value 2; in an implicitly typed language, the programmer doesn't. I'm boggled that people argue that implicit typing is a slam-dunk productivity advantage.
Once a codebase gets beyond, say, a few thousand lines of code, you can no longer comprehend it in a top-down manner by reading over the entirety of the source and stepping through a few sample runs. Instead, you've got to dive into the middle, where you think your task is, and start putting together the program structure in your head. For jobs like that, which will become even more common as the corpus of sample and open-source code on the Internet grows, you need all the type information you can get.
I spent many years as a C programmer - yes, I know that the type system in C is far from perfect - but in this case, the example works, because O'Brien's take is that the magic type declarations help the developer make sense of the code. They really don't. If I'm looking at a large body of code, I'm looking for program structure - objects that do things, sets of objects that collaborate. The type declarations are completely meaningless in that regard - whether something is an int, a float (etc) doesn't tell me anything of real value - looking at the API of the object (does it have one? Did the developers actually create one? ) is far more meaningful
I've looked at large bodies of C code, C++ code, Java code, and Smalltalk code. By far the easiest to "grok" quickly is the Smalltalk code - because I can dive right in and see living objects. I once had to debug a socket communication issue between a Java app and a Smalltalk app. I was able to run through the Smalltalk code live, in a debugger (with real objects), and see what it was doing - which pointed me to the Java side of the equation. Over there, I quickly diagnosed the issue - for reasons I still can't fathom, they were sending 80 bytes of data (while expecting to send an entire XML file) and thinking it would work. Did the fact that the socket objects all had type declarations on them mean anything to me? Nope, didn't help a bit. For the most part, the extra verbosity got in the way (I know it's a socket for gosh sake, get the stupid words out of my face!).
But Visual Basic has been and can be an implicitly typed language, while the "dynamic language hacker" traces a genealogy that runs from LISP to Smalltalk to Python. What truly reshapes productivity in those programming systems (note, I didn't say "languages") is an interactive workspace. This has nothing to do with finger typing or compilation speed or debugging (or rather, it doesn't reduce to just these things). Even if you've never used any of these languages, you have undoubtedly used an interactive workspace with your database.
I suppose he never stopped to ponder why it is that dynamic languages tend to have such interactive tools, while static languages generally don't (yes, Eclipse has "edit and continue". No, it doesn't always work, and it's not nearly as flexible). Might be that the rigidity of the static side makes such tools a lot more expensive to build - which explains the dearth of them. O'Brien agrees that interactive tools help - he doesn't consider why they exist in dynamic land, and tend to be lame to non-existant in static land. He might want to spend a few minutes considering the implications.