Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Beware complexity

Reply
Thread Tools

Beware complexity

 
 
Philip Smith
Guest
Posts: n/a
 
      03-13-2005
I wonder if anyone has any thoughts not on where Python should go but where
it should stop?

One of the faults with langauges like C++ was that so many new
features/constructs were added that it became a nightmare right from the
design stage of a piece of software deciding which of the almost infinite
different ways to do the same thing to use.

Result: the development of various coding standards (essentially definitions
of what 'safe subset' of the language you intended to use in all your
projects) to 'cripple' the overly complex language.

Conventions on type conversion are just one example. Without using strict
coding conventions the richness of the language could, and often did, result
in ambiguity. In my experience too C++ has defeated its own object (eg
portability) - I've given up in many cases trying to compile third party
libraries because I don't have the time to collect every version of every
compiler for every platform in existence which is what C++ seems to demand
(particularly if you are trying to cross-compile Unix->Windows).

Nothing wrong with coding conventions of course unless you:

a) Want to read and understand other peoples code
b) Want your code to work with it

There probably isn't a language in existence that provably constrains a
programmer to use one and only one 'top level' approach to code a particular
'class' of problem but Python does seem to have a way of naturally
'suggesting' this through its very simplicity.

It seems to me that from here on in the Python developers should be very
careful about adding new features to a language which (subjectively) already
seems capable of handling pretty much any 'class' of problem. There is
plenty of scope left of course for continuing to develop libraries and
optimize performance.



 
Reply With Quote
 
 
 
 
Harald Massa
Guest
Posts: n/a
 
      03-13-2005
Philip,

more often than not, all needed was included in Python years ago.

Especially:

> I wonder if anyone has any thoughts not on where Python should go but
> where it should stop?


The answer is included within the standard library. On any Python command
prompt type:

>>>import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

> Nothing wrong with coding conventions of course unless you:


So "coding conventions" are more or less rendered as something of ancient
times; Python has its Zen. (of course, as I said, included in the
standard library)

And: the fear that Python gets extended over sensible bounds maybe real.
But: Just have a look within python.devel, what happens on any (pun
intended) extension to builtins: It's a gentle and polite, nontheless
strong and hard discussion; a real evolutionary survival test.

Python is a healthy tree: it grows. But Guido and the Bots are
thoughtfull gardeneres: they are not afraid to cut bad branches.

Harald
 
Reply With Quote
 
 
 
 
Brandon J. Van Every
Guest
Posts: n/a
 
      03-13-2005
Philip Smith wrote:
>
> Conventions on type conversion are just one example. Without using
> strict coding conventions the richness of the language could, and
> often did, result in ambiguity. In my experience too C++ has
> defeated its own object (eg portability) - I've given up in many
> cases trying to compile third party libraries because I don't have
> the time to collect every version of every compiler for every
> platform in existence which is what C++ seems to demand (particularly
> if you are trying to cross-compile Unix->Windows).


Isn't that going to happen to any popular, ISO standard language? An ISO
standard, oddly enough, means that compiler vendors will compete to add
value to the standard. Having a language remain under the iron grip of 1
developer is both a blessing and a curse. Some things remain wonderfully
well controlled and coordinated; other things are suppressed according to
the idiosyncratic whim of the arch-developer.

FWIW this dilemma has had profound historical importance. It's the main
reason the Chinese didn't colonize and conquer the world, despite having a
61 year head start in maritime expansion. Isolationist agrarian Confucians
beat expansionist maritime Eunuchs in a civil war, then banned all the
shipping for 130 years. Europe, being composed of many competing powers who
would try new things to gain an advantage, cleaned up.

My point is that Python may someday grow beyond the notion of 'BDFL', as
heretical as that may sound.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."

 
Reply With Quote
 
Ron
Guest
Posts: n/a
 
      03-14-2005
Philip Smith wrote:

> I wonder if anyone has any thoughts not on where Python should go but where
> it should stop?


My feelings on this is, it's a problem of organization and
documentation. Do both of these well, and things will be manageable.

I would like to see a bit cleaner file organization framework. I think
keeping the different parts/modules/utilities/etc. Seperate and in
their own place would solve a lot of distribution/installation problems.

Having a central distribution place for people to download third party
modules in a standard install/uninstall package format would also help.

# Example directory structure.
python24
main
core # interpreter, dll's, and min.
tools # test scripts
examples
docs
standard_modules # modules included in distribution
module name
core # standard module dlls
tools
examples
docs
next module name
core
tools
examples
docs
<etc>
extend_modules # 3rd party extension modules
"module name"
core # dlls
tools # helpfull scripts
examples
docs
<etc>
tools
idle
core
tools
examples
docs
py2exe
core
tools
examples
docs
document_reader
# script to read and search all doc files
# and run related examples scripts.
core
tools
examples
docs


Ron
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Opinions on complexity _Hobbes Java 21 12-17-2005 01:49 AM
How much complexity to put in POJOs? Scott Balmos Java 6 07-13-2005 04:14 AM
2.0 Controlling password complexity in Membership =?Utf-8?B?TW9yZ2FuIFJvZGVyaWNr?= ASP .Net 3 04-22-2005 12:23 AM
NYJavaSIG - EJB 3.0 and J2EE 5 - Bringing Simplicity to the Complexity Frank D. Greco Java 0 02-15-2005 05:31 AM
reducing complexity foldface@yahoo.co.uk ASP .Net 0 10-12-2004 01:05 PM



Advertisments