Home Original page

Python suitability

skaller skaller at maxtal.com.au
Sun Dec 26 11:41:09 EST 1999 
Alex Martelli wrote:
> 
> John Skaller writes:
> 
> > > 6. Many of the things you do in C++ are to over come it's own
> > >     limitations.
> >
> > The main limitation of C++ wrt python is the ugly syntax,
> > and the quantity of it that is required to do something which is
> > simple in Python. After all, Python is written in a subset of C++.
> > Python simply 'pre-makes' some design decisions for you.
> 
> An interesting way to put it.  But, actually, it's an _extended_
> subset, because it makes use of some things that (alas!) are
> not in standard C++: things such as deploying separately
> compiled modules, and accessing certain elementary OS
> functionality (such as getting a list of files). 

	To back this argument up: Python refuses to standardise
a GUI, in Viper it is standardised, I guess for much the same
reasons you give.

> The 'subset' relationship probably does hold for JPython, since
> Java is not as shy as C++ about offering standard and
> portable models for these issues (and others, such as
> threading); 

	Yeah.

> > This is an advantage if these decisions suit your application,
> > and a hassle if they don't, and you have to work around them.
> 
> Probably a fair point about any 'higher-level language'
> whatsoever (including C++ versus assembly).  The key
> issues here would seem to be, how wide is the range of
> applicability of the 'pre-made design decisions' (how often
> are they limiting rather than empowering), and how
> much of a hassle is it to work around them when need
> does arise.  I think Python (and C++, when scored against
> machine language) does very well on both scores, while
> other "higher-level" languages may not be as suitable.

	I think Python scores well when it comes to making
small utilities, but it begins to fall apart for larger systems.

	Let me predict, for example, that Zope will become
almost unworkable soon: Python just cannot hack such a large
beast. C++ on the other hand, makes getting started
much harder, but it then scales better.

	I think this is because better support for
abstraction and modularity ends up being more important
than more application oriented support.

	To put this another way, by example: having
a built-in FTP/HTML library may make small web jobs
easier in Python than C++, but once you get to a bigger
job the amount of work that would be required to design
and implement those components becomes relatively smaller,
and the problems integrating components -- in general --
becomes more dominant.

	To give an idea what I mean: compare
Python 1.4 to python 1.5.2: the latter has packages.
Packages allow much larger jobs to be done with python.
[Interscript is strongly package based, and would be unworkable
without them]

	Now, consider what the Types-SIG is doing, allowing
some form of optional static typing -- this again will
allow python to 'scale up' to larger jobs.

	The real problem is that such 'ad hoc' enrichments
are necessary to allow scaling up, and also end up destroying
the essential simplicity of the system.

	What is needed is something _intrinsically_ scalable,
from the ground up. And we know what that is in theory;
but not how to apply it yet: we _know_ that the fundamental
concepts of computing are based on ideas of abstraction,
and we _have_ a known scalable theory of abstraction
(category theory). But we don't know how to apply it
to computing, and we're not yet willing to put our
efforts behind it: today's income stands in the way
of tomorrow's advance. (which is probably the way it
should be, since theories often break when one tries
to apply them :-)

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850
More information about the Python-list mailing list