Zope & Python

[Alex Martelli]

"Leon Booyens" <leon_booyens at xsinet.co.za> wrote in message
news:39c208eb$0$231 at hades.is.co.za...
> Hi,
>
> I asked one of our specialists if we should not consider using Zope
instead
> of tomcat and Python instead of Java.
>
> His reply was as follows :
>
> Do you agree with all these comments ?

Of course not, or else we would hardly be following this group:-).  But
the first key issue is the usual one: whether compile-time-enforced
static typing is mandatory (or even particularly advisable) to develop
big apps (the current buzzword for which is "enterprise") or not.

Users of languages such as Smalltalk or Erlang (or Python:-) clearly
think it isn't.  The whole "Extreme Programming" methodology (which
has clearly gained buzzword status:-) was born out of Smalltalk use
(for a _huge_ enterprise application, as it happens), and makes
static typing basically irrelevant due to its fanatical insistence
on testing -- your tests MUST be good enough to catch a zillion
possible logical errors (which simple type-checking would miss -- or
do you think any Java application is magically bug-free?-), so of
course, as a side effect, they'll also catch any type-error, they're
the easiest kind to catch (in a language that is *strongly* typed,
albeit dynamically: this applies to Smalltalk just as well as Erlang
or Python; it may be somewhat worse in a language that's truly weakly
typed, such as Perl, but that is not at issue here and now).

Erlang is the language used at Ericsson to develop applications which,
besides being huge & complex, pose extremely strict requirements of
quality and availability -- they control telecom switches & other
equipment.  Bluetail, another Swedish company that uses Erlang about
exclusively (www.bluetail.com), "provides software to ISPs for making
high-availability fault-tolerant mail handling systems" and more
generally "manufactures and markets content-intelligent traffic
management software for high-volume Web computing environments".

They've just been acquired for US $152 Million by a US company; not
bad for a company that's about 1 and 1/2 years old and has 25
employees -- that's a cool US$ six million per employee, with
a couple million dollars' worth of spare change.  Note that the
key technical people in Bluetail are (some of) those who invented
Erlang back in Ericsson -- their bet was to leave and found their
company to prove that their technology (Erlang) was just as good
for developing other kinds of complex applications, currently in
great demand, and needing top quality and availability as well as
intrinsically very complex logic -- the software infrastructure
for e-commerce, basically.  What the US buyers are buying is,
basically, the Bluetailers' know-how and technology, with a view
to deploying it widely in their own applications -- and, again,
that technology's focus starts from Erlang, a *dynamically* typed
language, just like Python.

You can also look at the BeOpen Pythonlab site for a selection of
firms that are using Python today for business-critical software,
just as General Electric (and untold-many others) are using
Smalltalk, just as Ericsson and (now) a Nortel affiliate are
using Erlang.


Of course, there's a strong and classic school that holds
otherwise -- best represented, probably, by the languages
Haskell (with the most elegant strong-static typesystem I've
ever met) and Eiffel (with a rather rigid typesystem, but one
or two surprising 'oops'es from that, called 'covariance').

This school holds that compile-time typing IS the start of
reliable software; the inventor of Eiffel also invented (or
at least systematized and popularized -- I'd give Djikstra
and other '60s scientists the real credit for the _invention_)
"Programming as Contracting".

I will note in counterpoint that the second-most-prominent
paladin of "Programming as Contracting", after Meyer (the
inventor of Eiffel) is Robert Martin -- see his site at
http://www.objectmentor.com/).  While still a C++ guru,
Martin is now  also rather enthusiastic about Extreme
Programming (which he thinks may be a right way to apply
Rational's Unified Process UML-based methodologies) and
Python (to which he has contributed a unit-test framework,
an important little nugget towards the application of XP
in Python).  (anther Python enthusiast you might want to
meditate on is Bruce Eckel, best-selling author of "Thinking
in C++" and "Thinking in Java").  Programming-as-contracting,
of course, is used in designing programs to be coded in
Smalltalk, Erlang, or Python, much the same way as it's
used when the coding is to be in C++, Java, or Visual Basic;
Eiffel stands out because, given his inventor, it has direct
language support for contract-based assertions, but in most
other languages they're used at design-time and run-time,
and this holds for Java just as well as for Python, neither
of which has direct language support for them.


Anyway, neither Haskell nor Eiffel currently command a huge
market-share in software development -- though they're among
the few that can claim real compile-time type-safety (*almost*
so, for Eiffel).  Haskell and Eiffel enthusiasts criticize
popular languages such as C++, Java and Visual Basic as not
being strong enough for safety in their compile-time checks,
and maybe even too lax at runtime.  They have a point.  If
compile-time type-checking is SO important as to disregard
the huge programmer-productivity advantages of Python or
Erlang, why stop mid-stream at languages whose typesystems
are "almost" compile-time safe...?


Actually, types' connection to reliability is quite iffy; they
DO, however, have pretty good connection to *runtime efficiency*.

Java, Haskell, and Eiffel, don't really do an outstanding job
of exploiting this; but the languages that give you the fastest
executables today, such as OCaml and C++, *do* crucially depend on
their somewhat-rigid typesystems for that -- languages with dynamic
typesystems have a harder time optimizing to the fullest (it's
not *impossible* -- languages such as Common LISP, and Scheme
with its 'stalin' compiler, show this -- but it's a much harder
job; the compiler has to "infer" the type information which in
other languages the programmer is obliged to explicitly state;
a co-operation between compiler and programmer, where the latter
doesn't *have* to state type-constraints but is *allowed* to do
so when he wishes -- for expressiveness, or to help optimization --
seems best to me in the long term; OCaml, and even Haskell, are
mostly founded on this principle).


I'll leave it to others to answer the other points, by pointing
out the huge richness of tools available for Python, how easy
it is to interface it to just-about-anything, to train programmers
to use it, etc, and how well Zope scales up (it's definitely not
tied to Apache...).  The theoretical issues connected to types
are those which most interest me right now... and, though coming
from a strict-compile-typing background, I'm more and more
convinced that the approach to types of Java is _not_ carrying
its weight.  Maybe Haskell's purity, or OCaml's intermediate
approaches are best, maybe Erlang's and Python's greater fluidity
(no doubt _with_ help from type-inferencing and optional type
indications by the programmer) -- I think that in fact these
languages will converge in the long run towards more similar
approaches than the dichotomy about typing might suggest.  But
it's not the same 'middle-ground' as occupied by Java (perhaps
the worst in this regard -- C++ at least has templates to help!
Java's templates will help if and when they finally arrive...),
with a LOT of load on the programmer to specify types everywhere
and YET a lot of runtime typing risks (all the downcasts needed
from Object, for example -- yecchh...).


Alex