This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Productivity unexplained Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

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!).