not safe at all

[Greg Jorgensen]

"Dennis Roark" <denro at earthlink.net> wrote in message
news:kr81ltkck185fba69ukgvn5hf1ivtosvar at 4ax.com...

> Dynamic typing, or binding, reference variables that can
> change the type pointed to, are to me still part of a weaker
> type safety than if they were not there.

Typing and binding are not the same thing. In C, C++, Pascal, etc. the name
and type of a variable are attributes of the variable name. The variable's
content (or what it points to) doesn't have any name or type--it's just a
chunk of memory that is interpreted and manipulated according to the type of
the variable name used to refer to it. The most obvious example of this is
the C/C++ union:

  union {
    int    ival;
    float  fval;
  } u;

u.ival and u.fval are different variables with different types referring to
the same (untyped) chunk of memory. In statically-typed languages like C,
variables can't change their types. A cast only tells the compiler to use
different rules to manipulate the memory the cast expression refers to; it
doesn't change the type of any variables.

The contents of a typed variable can be changed, but the variable can't be
rebound to another chunk of memory. C and C++ simulate binding through the
indirection of pointers. But because the compiler can't detect rebinding a
pointer, the programmer has to deal with memory management (C, C++), and all
the problems that ensue, or the language can simply disallow pointers
(Java).

Python doesn't have variables. Python has typed objects, references to
objects, and names that are bound to objects. The binding is dynamic: a name
may be bound to different objects of different types at run-time (as your
example code demonstrates). The type is a property of the object, not of the
name. Note that Python doesn't have or need pointers.

Dangling pointers and undisposed objects and chunks of memory are the
biggest problems for C/C++ programmers. The language type enforcement does
nothing to deal with these subtle and hard to find problems. An industry of
debugging and testing tools developed alongside C++ to help programmers find
and fix memory management problems.

Java is one solution: a typed language with name binding rather than
pointers. Java's C-derived syntax and complexity are a lot for new
programmers to master, and buggy and incompatible JVMs plague more
experienced programmers. Python is another solution. Python's simpler
syntax, rich built-in objects and standard library, and vastly simpler
runtime environment make it a good choice where Java is too bulky or
complicated.

I've been programming professionally for 25 years and I've mastered a lot of
languages. I still usually "think" in C, but Python is now my language of
choice for almost everything. My current day job involves building a huge
logistics system for an auto manufacturer. We're using Oracle PL/SQL and
Java. I can say without exagerration that if we were using Python we'd be
done by now, and our bug list would be one-tenth of what it is now. The
biggest problem we face is the multitude of programmers at widely varying
skill levels, trying to master complicated and subtle languages and tools,
and get their code to work with all the rest. If we were using Python the
skill gaps would be narrower, and easier to see and fix.


> So let's hold back the ad hominem
> attacks and help each other progress.

I agree--some of the postings are out of line.

> Originally [in Visual Basic], there was not a way to
> force declaration of variables.  It was programmer pressure
> that forced MS to introduce the "option explicit" code
> directive which requires declaration.

The OPTION EXPLICIT feature of VB does the same thing as Fortran's IMPLICIT
NONE. VB has typed variables and the VARIANT type, which is just a UNION
with a "current type" attribute. I don't know when OPTION EXPLICIT was
introduced, but I'm pretty sure stronger typing and avoidance of the VARIANT
type was pushed so VB could play nice in the COM/DCOM world, and not in
response to programmer pressure.


Greg Jorgensen
PDXperts LLC
Portland, Oregon, USA
gregj at pdxperts.com