tim at vegeta.ath.cx
Mon Jul 16 03:24:40 CEST 2001
Me parece que Peter Hansen <peter at engcorp.com> dijo:
> Tim Hammerquist wrote:
> > But what does 'larger' mean in this case? Larger than the MySQL engine?
> > Larger than a linux kernel? Larger than the Red Hat install scripts?
> Yes. Yes. And yes.
Ok. Not hard. And not hard.
> (Oh, sorry... how big are those programs? No, wait, it doesn't matter.)
No, it doesn't. The use of 'larger' was just vague IMO.
> > I wouldn't implement a RDBMS in Python. Nor would I implement a word
> > processor in assembler.
> Neither would I. An RDBMS would most likely need performance beyond
> what Python could provide, but if that were not the case, Python would
> most certainly be an option. (I don't know what assembler has to do
> with this discussion, but I would prefer Python over it for writing
> a word processor, performance issues aside. Performance issues
> included, I might use a little bit of assembler for the hot spots
> of the word processor, but a more reasonable choice would be C, of
> course. A good way of writing very large applications in Python
> would be to have the performance-critical parts coded not in Python,
> then spend the development effort where it counts on the higher level
> complex functionality, and testing.)
You've made my points for me. =) (Tho I'd probably do the DBMS in C,
with a Python front-end and API hooks.)
> > *nix OSes (like BSD) have attained an incredible scalability.
> > And what language is the
> > majority of the core of BSD written in? It's written in C, which does
> > not even claim to be an OO language.
> Typical Python applications, even really large ones, would not likely
> have the sheer number of programmers working on it that the BSD core
> has had, nor the length of time they've worked on it.
True. Python's age and amount of support were not the point. The point
was that even C can implement large, scalable, OO-type ideas like
> > An application's scalability has much more to do with the programmer's
> > use of algorithms and abstraction than with the language in which it's
> > implemented...no matter how much money ActiveState has invested in it.
> Did you write all this just for this jab at ActiveState? I know of the
> opinion some people have of them, but I didn't sense that *someone*'s
> posting contained anything more commercial or biased than what many of
> the rest of us, who don't work for ActiveState, have written.
Maybe I was wrong in my inferrence, and this probably isn't the location
for personal opinions on corporate business practices. But no; the jab
just came to me while writing.
> You're right about algorithms having more to do with this issue than the
> language, but some languages support better algorithms (by making
> their implementation easier and less buggy) and faster development than
> others. Those are merely two of the ways in which Python supports
> "larger" applications.
All very good points. I have certain reservations, tho. I dread
waiting for Microsoft Word to startup as it is, written in compiled C++.
I fear for the speed of anything of that scale and complexity
implemented in Python.
My $0.03US <wink>
Me? Lady, I'm your worst nightmare -- a pumpkin with a gun.
-- Mervyn Pumpkinhead, The Sandman
More information about the Python-list