One thing is static type checking: developers detecting type errors at
compile time, rather than some hapless user running into it at run time
(i.e. after release to the public). I see many of those types of errors
in Zope and Plone products, particularly as the API of one product
changes and another product tries to use it. With Java, such
problems are likely to be detected at compile time. Runtime errors produce a
negative public
perception of software products, as well as being dangerous in critical
systems. Pervasive use of unit testing will help avoid such problems, but
that level of discipline is hard to find in Zope/Plone projects (but well
done those who do it!). On the downside, static type checking makes Java
less flexible, and requires more programming effort, and of course there
is that tedious compilation step.

Advertising

I worked in Java for web apps (as well as a few halting tries at
GUIs--ick!) before Zope. I expected type problems because of the lack of
static checking; however, I have not found it to be a problem. I don't
think programs are quite as wild and wooly as static typed languages
assume. I think it's quite acceptable to put the burden of use on the
programmer instead of the compiler, considering the benefits; that's
what he's thinking about anyway, no?

My main problem with Java is that it's a high-friction environment. It
takes a lot of work to do most things, often because interfaces have
been abstracted so far (or sometimes because of compiler hoops, but not
that often.) This is both in code and framework.

For code, go take a look at what it takes to make an XML-RPC call in
Python and in Java. I had to look this up for writing my book, and it's
quite disgusting. It all depends on the functionality, of course, but I
can't think of anything that writes quicker in Java than in Python.

Framework-wise, I found that it took at least three separate helper
programs to set up an reasonably productive, understandable, and
maintainable development environment for J2EE, and that's not even
counting an IDE.

Zope 2 development generally has a lot less friction, and is usually a
lot higher-level. As a result, I think it's several times faster than
Java development. Possibly even many times faster. It does seem to make
up for this by being more mysterious, but you can learn those things in
time. You can't get rid of all the Java crap. (It's like the Churchill
joke.)

Zope 3, though I admit I've only played with it glancingly, seems to be
more J2EE-like in certain respects: there seem to be a lot of things I
have to touch to get things going. To a certain point, I can deal with
this, but if there's ever a "ZDoclet"...