Who's minister of propaganda this week?

[Kris J. Zaragoza]

On Wed, 14 Mar 2001 17:50:05 +0100, Nicola Musatti
<objectway at divalsim.it> wrote:
>Hi,
>I'm a Python curious not yet sold to the advantages of typeless
>languages; I tend to think that typelessness is suited to a set of tasks
>that has only a limited overlap with the tasks for which static typing
>is preferable. I have a question and a provocation for you.

Just a minor nit:  The languanges that are being discussed are not
actually typeless.  They are typed, but dynamically.  Every object in
Python, for example, has some type associated with it, and as a
result, the semantics that follow from that type.  You cannot thus put
a string in the middle of a mathematical expression.  Relatively few
of the "scripting" languages in popular use today are weakly typed or
typeless (Perl and TCL come to mind.)

>
>Cameron Laird wrote:
>> 
>> In article <98nu1m$12e at dispatch.concentric.net>,
>> Phlip  <phlip_cpp at my-deja.com> wrote:
>>                         .
>> >Robert C. Martin meant two things. A> If you write wall-to-wall unit tests
>> >when you code, if you use a typeless language you will add bullet-proof
>> >features faster than if you use a statically typed language, even though
>> >the former has less built-in error checking at type conversion time. The
>> >latter supports refactoring easier.
>
>But those things that the compiler used to check for you may well have
>become new tests for you to write: if the trade-off between the decrease
>in actual code size and the increase in test number is negative, even
>the better support for refactoring turns out to be an illusion. 

But this assumes that a reduction in the number of lines of code is
the goal.  It is not.  The goal is to build a robust system as quickly
as possible in the face of constantly changing requirements.
Refactoring and constantly running unit tests are two techniques that
allow for this speed and robustness.  Having the compiler check type
semantics doesn't contribute nearly as much.

Then, of course, there is the matter of how expressive and legible the
resulting code is.  See below for more on this.

>
>[...]
>>   Expressiveness ... is a far better aid to
>>   correctness ...
>
>Here I'm puzzled, but maybe it's only a "language" problem. What do you
>mean by "Expressiveness"? I ask because until now I thought
>expressiveness was an advantage of strongly typed languages (namely,
>C++) over typeless ones.
>
>Best regards,
>Nicola Musatti

Expressiveness means different things to different people.  There is
(currently) no objective standard by which it can be measured.  My
personal take on expressiveness is fairly simple:  How easily can I
express my data, models, and algorithms without getting bogged down in
language details?

Consider C++ as an example.  I actually like C++, despite all its
warts.  It's an incredibly powerful language, and allows for some very
efficient code generation in resource constrained environments.  I
like the feeling of being close to the machine when writing C++ code.
However, I don't consider it a very expressive language.  An
inordinately large amount of any C++ source file is dedicated to
either bookkeeping code for the type system, or various other
syntactical details.  This extra code results in clutter that does not
necessarily---in fact, rarely---contribute to clearly expressing the
intent of the code.

Consider Python as the contrary example.  (This is c.l.python, after
all.)  Python provides a highly interactive environment, allowing one
to type code in at a prompt and have it immediately executed without
need for a potentially lengthy compile and link cycle.  This allows
for a very different style of programming.  As you said above, there
are problem domains where this is extremely appropriate.  Exploratory
programming and algorithmic experimentation are, I believe, two such
areas.  These are, however, a critical part of any non-trivial
project.  Understanding the problem domain, properly modelling data,
and selecting the most appropriate algorithms can provide for enormous
benefits.  The best way to do these things is often to simply
experiment until things fall into place.  Python allows for a great
deal of experimentation in a very short amount of time, far shorter
than with C++.  In experimenting with more alternatives, you may be
able to find the most optimal selection of algorithms and data models
to solve the problem at hand.  This translates to a significant
competetive advantage in the business world.  The right selection of
algorithms could result in orders of magnitude increases in speed as
compared to competitors.  Likewise, the correct selection of data
models and architectures can lead to significantly greater
flexebility, allowing for much easier adaptation whenever the
requirements of the system change.  

Of course the only thing missing, then, is the robustness of the
system.  As others have already said, however, the judicious
application of unit tests (especially automated unit tests that are
regularly run) helps achieve this robustness at a level that static
type checking alone will never achieve.

I will admit that this isn't a formal proof.  Nor is it, one could
say, a strong argument.  I am, quite literally, half asleep as I type
this, so I hope you will forgive the lack of well-structured
arguments.  However, I believe that what I've stated could prove to be
good food for thought.

Salud!

Kris

-- 
Kris J. Zaragoza           | "Unfortunately, most people can't out-think a
kzaragoza at mediaone.net     | grapefruit."  --Jon Bodner