Zope & Python

[Tom]

Regardless of who is technically right about the value of these language
issues (static type checking, access control), it must be accepted that a
lot of people want them.

I don't see why these features couldn't be added to Python in a way that
would be completely optional and wouldn't affect backward compatiblity.

I'm not suggesting that the implementation of these features would be easy.
I'm saying that, in theory, we could have the best of both worlds.

Tom.

"Bill de hÓra" <bill at replywillfail.com> wrote in message
news:8s3vik$b5u$1 at taliesin2.netcom.net.uk...
>
> > > I have had a look at the "Zope" application server at www.zope.org,
and
> feel
> > > that it cannot be considered for use (on the server side) in an
> enterprise
> > > application because of the following weaknesses:
> > >
> > > The business-logic extensions must be written in Python, which is a
fine
> > > "glue language" for whipping up scripts and small applications in as
> short a
> > > time and as few lines of code as possible, but is simply not robust
> enough
> > > for enterprise applications.  For example, it does not allow
> compile-time
> > > enforcement of interface specifications, as C++ and Java do.
>
> This is precisely why you would want a dynamically typed language for web
> applications. There is very little empirical evidence that static typing
> actually protects programmers or adds robustness by punting type checks to
> the compiler. There is plenty of evidence to suggest it leads to brittle,
> bloated, and eventually unmaintainable code.
>
> Python is ideal not as a glue language, but in parts where you need real
> flexibility. That's why Google uses it to write spiders. Python's ability
to
> rewrite itself is fantastically powerful.
>
> Anyway XML should be your glue now.
>
> Vignette and Arsdigita use tcl. Tcl is light weight easy to learn and use
> and compact as we might expect from a scripting language. Both these
> companies build enterprise level web applications. Using a scripting
> language to build applications is not hurting them.
>
> Smalltalk is widely used at the enterprise level in the back tier, it has
> similar typing properties to Python. There are very probably more
correctly
> functioning Smalltalk programs in the world than C++ programs: and that's
> actual programs not in proprotion. Almost no-one has written a correctly
> functioning C++ enterprise level application. For what it's worth, dynamic
> typing and functional programming is becoming ascendent within the OO
> coomunity (by community I mean the 100 or so people who tell the rest of
us
> what good OO is). The value of static typing is a myth born of dealing
with
> crap C code in the seventies and eighties when C went far outside its
> comfort zone.
>
>
> > > a) It does not even support the concept of private, protected and
public
> > > instance variables and methods. The whole concept of
> "design-by-contract"
> > > relies on the availability of these features.  You cannot rely on
> > > programmers to have the discipline to comply with (nonexistent)
> interface
> > > specifications.
>
> Design by contract assumes you have a contract in place. PPP access alone
> won't give you that, nor will static type checking. You need argument
> assertion semantics in the language (which java doesn't have by the way
and
> C++s is highly ambiguous) and exception handling. Python has excellent
> exception handling.
>
> > > b) If we develop web applications in accordance with the Java Servlet
> API,
> > > we can upgrade the platform from Apache+Tomcat running on Linux to
Sun's
> > > Java Webserver, or IBM Websphere, or BEA Weblogic (BEA is the industry
> > > leader in OLTP middleware), or any number of other commercial
> > > implementations.  What is the upgrade path for Zope?
>
> You'll only need that upgrade path when some architect or business
decision
> makers decides that we must have J2EE/EJB compliance on the middle tier.
But
> tell me, in 2-5 years time when we decide that we need fully
> parallel/distributed architectures not tiering, what is your upgrade path
> from Java middleware?
>
> > > c) Java allows a wide choice of compilers, debugging and profiling
> tools,
> > > modelling tools, middleware, and libraries for everything under the
sun.
> It
> > > is a mainstream language for commercial applications, with a
relatively
> > > large pool of programming expertise and with support from most major
> > > industry players (besides Microsoft). Python may be gaining
popularity,
> but
> > > is way behind Java.
>
> Finding python programmers is a problem, yes. But if you're hiring against
a
> skill-set rather than looking for real talent, you have an intellectual
> capital issue that's probably more serious than decisions of architecture.
> No amount of compile time handholding can protect you from weak
programmers
> who are bandwagonning on Java. And a talented programmer will be writing
> useful python code in a week.
>
> Look, this is really about software layering. I would not write my network
> systems layers in Python. But I would write application level code in
> Python. Equally, I would certainly not want to code business or templating
> logic in a static language like C++ or Java. In that space servlets/JSP
are
> a three legged dog, a sideshow at best.
>
> -Bill de hÓra
>