From: "Hadar Pedhazur" <hadar@opticality.com>
To: <zope@zope.org>
Subject: [Zope] Hadar's Thoughts on Perl for Zope (LONG)
Date: Sat, 27 May 2000 15:28:47 -0400

It's been a while since I've communicated directly with the
Zope community, and I am truly sorry for that. I have been
so busy, that I have actually disengaged from the mailing
lists, something I was hoping to avoid doing. I have
maintained the same level of involvement with Digital
Creations, and therefore Zope as well, but the amount of
traffic on the lists was overwhelming me given my current
activity level at Opticality.

I have only seen a single post to the list regarding the
recent announcement of Perl for Zope. Paul Everitt was kind
enough to directly forward to me Eric Sink's post, because
he knows how highly I regard Eric's opinions. The most
important part of that post was Eric's clear statement that
there was discord in the community over this announcement.

Having been one of the instrumental people in bringing Zope
to the community, and having likely been the driving force
behind the decision to create Perl for Zope, I would like to
directly share the thoughts behind that decision.

Please recognize that I have not read any of the posts on
the list, and therefore, could very well be repeating
important concepts written by others. I apologize if that
ends up being the case, but rest assured that this would
only mean that I am further underscoring those thoughts,
because I didn't have the benefit of reading them first.

First, a brief history lesson. I was a major Perl coder for
5 years. I built multi-thousand line Perl programs that did
pretty sophisticated things, so I knew Perl pretty well.
Then I discovered Python. I haven't written a line of Perl
since then. This is not a put-down of Perl, but rather an
elevation of Python, IMHO. It is through my discovery of
Python that I came across Digital Creations (DC), in 1995.

I contacted DC in 1997, and asked them if they were
interested in funding. We consummated a deal in October of
1998. The deal happened only because they were a Python
shop. A month later, after lots of "active discussion", we
decided to Open Source the then named Principia application
server. I was a driver of that decision as well. So, for the
record, I'm a deeply rooted Python person, and believe it to
be the ideal foundation for Zope.

So, why would I push for the decision to create Perl for
Zope? When I was at Union Bank of Switzerland (UBS), I used
a tool that hooked into the Objective-C runtime, and unified
the object model so that it was equally accessible from
Objective-C, TCL, Perl and Python. Classes, methods,
instance data, etc., were interchangeable, and worked
transparently across languages. This was simply magic, and
we made excellent use of this in a variety of our
applications. Given how wonderful Zope was, it seemed to me
that it too could be the foundation for people who had
skills in other languages.

My original thought was to use the same tool I used at UBS
and incorporate it into Zope. This would have allowed TCL to
interact as a first class citizen along with Perl. After
much thought on the subject, we decided instead to partner
with ActiveState (AS). This adds only Perl support (for the
moment), but accomplishes a number of other goals, which
will hopefully give the community some insight as to DC's
direction on this. AS has significant Perl Zen, but has also
recently hired some of the top Python talent around. They
are embracing Python in a significant way, through Zope,
but also as a standalone programming and scripting
environment. For more on that, read:

http://www.activestate.com/Corporate/Media_Center/News/Press959117519.html

(the above will likely have wrapped poorly, and should be
re-pasted as one long URL.)

There's a more important point here though, and that is that
if DC had taken my original approach, we'd have been in the
business of managing the cross-platform codebase directly.
In fact, that alone was one of the gating factors in not
doing it. By outsourcing the cross-platform parts to AS, we
each continue to concentrate on our own core competencies.
For DC, that's Python, through and through.

We've got a world-class team of Python experts, and that
hasn't (and won't) change just because our platform will now
allow others to hook their code into it. The people
internally view this as a positive thing, so they don't feel
that they will be forced to code in Perl.

To reiterate, Zope is Python, and always will be. Meaning,
the core of Zope will continue to be developed in Python
(and C), and no one today envisions that changing.

However, there was no uproar when we introduced XML-RPC. No
one said "Hey, I don't want to be able to communicate with
other systems, Zope rules, and others must perish!"
Likewise, introducing a tighter coupling, giving others a
choice in using their favorite language shouldn't cause you
any more grief.

To me, it's about "inclusion", not about change.

I'm told that one of the protestations is that people will
be expected to know Perl if they want to get a job coding in
Zope. I guess I have a hard time understanding the problem
here. Today, those shops that do most of their work in Perl,
don't use Zope. So, they won't hire you anyway. Those who
have already embraced Zope, will want you for your knowledge
of Zope, and probably Python specifically. If Perl for Zope
ends up getting Zope installed in a wider variety of shops
and sites, then the above might become true. Wouldn't it
also be true that there never would have been an opportunity
for you to get a job there had they not adopted Zope either?

My point is that if Zope gets wider adoption because it
permits a wider range of programming choices to script its
core, then more jobs will be available. At some shops, those
jobs will have to be in Perl. But at others, "Best
Practices" will rule, and we at DC (and I too) believe that
this will continue to be Python. In fact, I could argue
strongly that indeed even in the pure Perl shops that adopt
Zope, they'll want/need a Python guru or two to track the
core of Zope, in case they ever need to tweak that as well.
This will create a larger job-base for the Python people
than we have now.

Here's my bottom line, and a bit of a rub as well. The Perl
for Zope initiative is meant to be one which purely and
simply helps the community, by broadening support for Zope,
and getting it more widely adopted. DC is not intending to
become a Perl consulting shop, so it likely won't have a
near-term direct influence on our revenues. In fact, it will
add to our expenses, as we support this wider community. So,
we've undertaken this with a view toward others, rather than
what's best for us in a "mercenary" sense. I would hope that
you would all join us in that view and mission.

Finally, I apologize deeply for the fact that I won't have
the time to debate this interactively with the community. I
will ask Paul to keep me up to speed on the nature of the
responses, and if requested, or required, I'll post again
with a summary follow-up of my views. I wish to conclude by
repeating the original introduction here. I am a deep
supporter of Python, as are all of the employees at DC. I am
deep supporter of the Open Source movement, as are all of
the employees at DC. I am deeply committed to keeping the
core of Zope in pure Python and C, so that we can continue
to deliver on the promise of our Services-based business.

I hope that my prior actions on behalf of the community will
at least earn me a "wait and see" attitude on the part of
the community as to whether the above turns out to be true!

Thanks for reading, and good luck to us all in this, and the
remaining Zope Adventures!


_______________________________________________
Zope maillist  -  Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )