[Zope] Zope needs this (and Dynamo has it)

[Alexander Staubo]

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl]
> Sent: Thursday, March 09, 2000 1:15 PM
> To: Zope Mailing List (E-mail)
> Subject: Re: [Zope] Zope needs this (and Dynamo has it)
> 
> 
> Alexander Staubo wrote:
> > > From: Martijn Faassen [mailto:faassen@vet.uu.nl]
> [I list a number of projects about improving Python]
> 
> > People are indeed working on Python, but not to the extent of more
> > popular projects like Linux or even, I believe, Perl.
> 
> I don't know enough about Perl to judge this, but to me, there's
> plenty of activity out there. Of course there could always be more,
> but lots is happening.. We have _three_ independent implementations of
> Python, for instance (Python, JPython and Vyper, and then there are
> projects like Python2C).

True enough, though I'd have liked to see more, and I'd have liked to
contribute more, too, which is to say, I'd like to contribute at *all*
-- no time for that at the moment, however. Ironically, I'm too busy
using it to improve it.

I find it ironic that JPython is even *slower* than CPython. Curious --
is anybody using it for anything worthwhile?

> > Compiler/language projects have, historically, not thrived in the
> > collaborative world of open source software -- for very 
> specific reasons
> > inherent in the concept itself of languages and compilers. 
> Still, I'm
> > very impressed with the evolution of next-gen GCC (formerly EGCS).
> 
> Sure, it's not easy to do. I would debate that compiler/languages have
> not thrived in the open source world, though. There seem to be
> quite a few successful open source languages around.

I'm not disputing the success of these languages. Perl, Python, PHP,
Pike -- they're all quite successful at what they aim to be (*). But
people tend to use languages rather than contributing to their
development. You can't just evolve a language indiscriminantly, which is
why we have Guido and Larry, the benevolent dictators. You can't just
go, "oh, and I added iterated loops today". Every damn little feature
requires at least some kind of ratification process. Languages are much
more susceptible to breaking.

(*) Except possibly Pike. I'm ashamed to say it, but I find myself oddly
attracted to this language, if mostly because of its speed and
interesting resemblance to C. Pike is a good example of "how to make a
powerful language/interpreter system that's also very fast". Pike has
had a type system from the outset, which is a definite edge over Python.
 
> [assessment of Vyper with which I agree]
> 
> > Anyway, while I have not been monitoring the Python 
> type/interface SIG,
> > it seems to be moving quite slowly.
> 
> That's the nature of discussion lists, almost. There are some 
> prototype
> implementations of type-checking systems for Python, though (I think
> two or three independent ones, in fact).

Where?

The type system SIG has a funny intro: "Recently, the types SIG has come
under attack for inactivity, and in response Paul Prescod has offered to
guide the SIG towards accomplishing a single specific goal: to develop
an optional static typing system for Python. The December 1999 archives
of the SIG show the discussion that lead to this decision."

Reading this stuff now. It's interesting. I hope they get it right.
Maybe I'll chip in.

What's interesting about Dylan is that, because it relies on static
information such as type hints and class/method relationships to be
efficient, the developers of Functional Developer (formely Harlequin
Dylan) are facing a design problem related to how they compile programs.
They've actually put all of the various libraries into shared DLLs.
Unfortunately, this means they lose the benefits of the optimizations
that can be made through the use of static compiler information. When
you load up the [latest beta of the] Developer IDE and compile a
program, it consumes a whopping 45MB of RAM. And it's damn slow. The
absence of such optimizations is one reason for this hogging tendency.
So they're planning on providing a "whole program delivery" option
whereby all libraries would be statically linked.

> [Python people say speed is generally not the problem]
> > > It is _less_ of a problem, but most Pythoneers are indeed 
> > > interested in
> > > speeding of the language. I haven't heard of zealots who 
> want to hold
> > > back speedups, as long as it doesn't do away with the power.
> > 
> > I'm not saying they're holding back, but rather they're 
> dismissing speed
> > and scalability as being a problem. I firmly believe that speed is
> > Python's number of problem today, and it's keeping Python from being
> > used in more applications.
> 
> Hm, but in my experience Python has been shown to be plenty 
> fast enough
> for the majority of applications. You're probably right though, and I
> agree completely that a faster Python would be very nice.

I have several apps where I would rather use Python, but where speed is
so significant that I would either end up writing a lot of the code in
C++ for speed (which is painful due to the lack of integration between
the two languages -- Python classes can't inherit from stuff in the C++
extension, for example).

I also have a database-centric Zope app that causing me headache. The
ZODB is *way* too immature to replace a database right now -- fine for
the kind of stuff that runs on zope.org, not for us. ream

> 
> > Python has plenty of problems, but they're tiny by 
> comparison and imho
> > they're mostly artifacts of Python's currently somewhat 
> anemic syntax
> > (eg., only two kinds of loops, no "switch", no protected members, no
> > constants, no syntax for declaring mutability).
> 
> I suggest you go discuss these things on comp.lang.python. :)
> 
> I don't miss switch. Functions are first class objects, and 
> dictionaries
> can be used instead of switch when necessary. Also, good 
> object oriented
> design tends to kill switch statements anyway.
> 
> I think the two loops are fine, though it would be nice to have the
> current constructs to know about iterators. I believe Guido is
> taking that into consideration. Also there's the list-comprehension
> proposal which may help here. 
> 
> I don't think you'll see protected members any time soon.
> 
> I'm not sure what you mean with syntax for declaring 
> mutability, though
> it sounds interesting.
> 
> > Imho Python's second big problem is what you might call, in 
> lack of a
> > better term (I'm not wearing my compiler-writer hat right 
> now, sorry),
> > contractual semantics -- anything from static typing (pass 
> a string to a
> > function that takes an int and you get either a compilation 
> error or an
> > exception) to interfaces (the ability to enforce semantic 
> compatibility)
> > to design-by-contract constructs.
> 
> The types-sig is reaching consensus about optional static typing and
> Guido does want to include that into the language in the 
> future (beginnings
> in 1.7, full implementation in Python 3000 aka Python 2). 
> Interfaces are
> being considered too, and Jim Fulton in fact has an 
> interfaces proposal
> out there (that may get used in Zope's code base).
> 
> I think using a unit testing framework can substitute for design by 
> constract constructs myself.
> 
> [snip]
> > > It'll be pretty difficult to make a beast like Zope exploit 
> > > type-hints, though, I think.
> > 
> > I disagree, but there's only one way to find out -- implement it (or
> > simulate it very carefully).
> 
> Okay.
> 
> [snip code generator extension idea]
> 
> Something like that would definitely be neat. The hard part would be
> in the translation process, of course. The other part is in the
> interfacing with regular Python; do you allow your translated function
> to refer to other Python objects? If you do, you're opening a can of
> worms. If you don't, then it starts to look like the 'Swallow' subset
> of Python I proposed once; a strict subset of Python with 
> added full type
> annotations, which is translatable into C or native machine code.
> 
> > It would be an interim solution for certain CPU-intensive 
> modules, in
> > anticipation of such built-in functionality in CPython 
> itself. Possibly.
> 
> If you're starting such a project I want to hear more about it!
> 
> [snip]
> > > All true. Anyway, the only thing you're wrong about is that 
> > > Pythoneers aren't
> > > interested in improving performance. They are, but I grant 
> > > you they're not
> > > performance nuts like users of C or C++. :)
> > 
> > Well, I guess they're too busy arguing about whether Python 
> should allow
> > assignments as expressions so you could do "while line = 
> f.readline():".
> > ;-)
> 
> Not to mention indentation! Anyway, the people who keep bringing these
> things up don't tend to be the Python nuts (mostly they're 
> the newbies).
> 
> Regards,
> 
> Martijn
> 
> 
> _______________________________________________
> 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 )
>