D
David Mertz, Ph.D.
A reader of my book (I dunno if the printed or electronic version),
emailed me with a common misunderstanding about typing. I thought other
readers might benefit from my note to him too. Not that there's
anything new... but maybe it will stave off the next round of the error.
-------- Forwarded message --------
|According to how the terms "strongly typed" and "weakly typed"
|(or "dynamically typed") are used among computer language folks, your
|statement is a contradiction: A language is either "strongly typed" or
|"dynamically typed".
Unfortunately, your misunderstanding is fairly widespread. It's also
absolutely, categorically, COMPLETELY wrong. That's why I made a point
of the fact that Python is strongly, dynamically typed in my book.
Well... I guess "used among computer folks" is vague--some computer
folks use terms wrong, of course. But in terms of conceptual clarity, I
was quite precise and accurate.
The axes strong/weak and dynamic/static are entirely orthogonal to each
other. The former has to do with whether objects can be treated as
different types across different contexts, the latter has to do with
when typing occurs (compile time versus runtime). These axes are both
more like scales than either/or choices. Some languages are
-relatively- more strongly typed than others; there's not a single
boolean for "strength". For example, Haskell is MUCH more strongly
typed than almost any language, even though Java is roughly on the
"strong" side of the scale.
All four quadrants occur in real languages (understanding that some are
closer to the edges than others:
Dynamic Static
+---------------+----------------+
Strong | Python | Java |
| Common Lisp | Haskell |
| Ruby | Fortran |
+---------------+----------------+
Weak | Perl | C |
| TCL | C++ |
| Basic | xBase |
+---------------+----------------+
The bottom right quadrant is worth commenting on. Given the use of
castable pointers in C (or even null pointers), it is easy to treat a
memory location as different types of values, despite the nominal type
declaration. In contrast, you can never do this in Python (but some
people get confused about the fact that NAMES in Python are just
bindings, not the object itself, which might be pointed at by zero or
more names).
For more information, see any of the thousand threads on c.l.python
where this has come up.
Yours, David...
emailed me with a common misunderstanding about typing. I thought other
readers might benefit from my note to him too. Not that there's
anything new... but maybe it will stave off the next round of the error.
-------- Forwarded message --------
|According to how the terms "strongly typed" and "weakly typed"
|(or "dynamically typed") are used among computer language folks, your
|statement is a contradiction: A language is either "strongly typed" or
|"dynamically typed".
Unfortunately, your misunderstanding is fairly widespread. It's also
absolutely, categorically, COMPLETELY wrong. That's why I made a point
of the fact that Python is strongly, dynamically typed in my book.
Well... I guess "used among computer folks" is vague--some computer
folks use terms wrong, of course. But in terms of conceptual clarity, I
was quite precise and accurate.
The axes strong/weak and dynamic/static are entirely orthogonal to each
other. The former has to do with whether objects can be treated as
different types across different contexts, the latter has to do with
when typing occurs (compile time versus runtime). These axes are both
more like scales than either/or choices. Some languages are
-relatively- more strongly typed than others; there's not a single
boolean for "strength". For example, Haskell is MUCH more strongly
typed than almost any language, even though Java is roughly on the
"strong" side of the scale.
All four quadrants occur in real languages (understanding that some are
closer to the edges than others:
Dynamic Static
+---------------+----------------+
Strong | Python | Java |
| Common Lisp | Haskell |
| Ruby | Fortran |
+---------------+----------------+
Weak | Perl | C |
| TCL | C++ |
| Basic | xBase |
+---------------+----------------+
The bottom right quadrant is worth commenting on. Given the use of
castable pointers in C (or even null pointers), it is easy to treat a
memory location as different types of values, despite the nominal type
declaration. In contrast, you can never do this in Python (but some
people get confused about the fact that NAMES in Python are just
bindings, not the object itself, which might be pointed at by zero or
more names).
For more information, see any of the thousand threads on c.l.python
where this has come up.
Yours, David...