OO misconceptions

[Tim Hammerquist]

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
abstraction.

> > 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