A boring Saturday night

[Christopher Smith]

Mark Lewis wrote:

>Executive summary:  I use Java or C/C++ when working on projects that
>involve several programmers, have stringent production uptime
>requirements or frequent releases.
>
>I use Python (sometimes Perl) for rapid prototyping, or for projects
>where I largely work alone and the single production release is 'when
>I'm done'.
>
Hmmm... I've found for large projects you are actually better off using 
dynamic type checking languages, with perhaps the individual components 
written in a statically type checked environment.

>However at work I'm doing a project where using a dynamically typed
>language would be suicidal, for the following reasons:
>
>1. Code inspection.  With a statically typed language, development tools
>can be much more powerful.  In my Java IDE, I can hit a keystroke to see
>all places in the whole project where a variable is assigned a value.  I
>get auto-completion of method signatures, and this is just scratching
>the surface.  Static typing is the enabling technology for several of
>the most powerful tools.  Dynamically typed languages can't provide the
>same functionality, or if they do they must do it through unreliable
>semantic analysis and guessing (since full semantic evaluation of a
>Turing-complete language is one of the classic examples of a
>non-computable problem).
>
It's funny that you say "dynamically typed languages can't provide the 
same functionality", as this aspect of your Java IDE is actually copied 
from the Smalltalk environment (which has had this feature for over 3 
decades).

This is a feature that dynamically typed languages like Smalltalk and 
LISP have had forever, and which statically typed languages still tend 
to implement comparatively poorly. Assigning a type to a variable is 
orthogonal to finding all the places where it is invoked. In many cases, 
type inferancing as you are writing your code is actually incorrect, by 
the very nature of the fact that your code is not complete.

>2. Multiple-developer synchronization.  I work in a tightly coupled
>environment where I need to synchronize my code base with the other
>developers at least every couple of days.  Tracking down partial commits
>or conflicts-- facts of life when you're part of a team and not
>everybody on the team is perfect-- is much easier when the code just
>won't compile right after the merge due to compile-time type checking
>than when you need to track down breakage in a certain case that you
>don't run into for weeks after the broken code was merged in.
>
Proper use of unit testing will do this far better than the 
comparatively weak power of the Java and C/C++ type systems.

>3. Frequent releases.  When the code needs to be released frequently
>(basically every week in my case), I frequently end up doing development
>on a bugfix in version 0.9.12.2, an enhancement in the latest
>development tree, merging in parts of changes from an experimental
>branch into the release, and so forth.  In that kind of environment,
>version mismatch happens sometimes.  And allowing the compiler to find
>problems that a runtime type-checking language would only find once a
>particular code path is exercised (after a lot of QA, or <shudder> in
>production) is a big win.
>
Again, unit testing is the right way to do this, at least if you are 
doing Java or C/C++ (admittedly with C++, providing certain conventions 
are used, you can use the compiler to do this work for you, but at that 
point you are programming more like ML). The type system is simply not 
expressive enough to do design-by-contract type work.

--Chris