HELP! Must choose language!

[jerf at compy.attbi.com]

On Tue, 31 Dec 2002 19:14:54 +0000, Bengt Richter wrote:
> IMO it's more important to do one version based on objects than
> to duplicate procedural habits of thought in several languages.
> I'm wondering if programming newbies would benefit from doing
> the object-oriented version first. I suspect so. And Python makes
> it easy enough.
> 
> Python is fine for doing it both ways (with meta stuff as bonus).

It took me a while to realize this, but I now think that my absolute
favorite thing about Python is how easy it makes it to do things *the
right way*, the first time. Often, it's even *easier* to do it "the right
way" then to kludge your way through the wrong way even once.

An example of what I mean from C++: Before the standard string libraries
were available enough to count on them being there, the tempation to just
write "char something[80]", despite the well-known dangers of
constant-sized buffers on the stack and the difficulty of secure
programming with them even in non-hostile environments, was often
overwhelmning. One would generally write code with constant-sized buffers
and frequently and dangerously just ignore the limits.

Once string libraries became reliably available, one can just write
"string something;", and suddenly "the right way" (more or less) is
*easier* then kludging along in C-style string manipulations. I actually
witnessed this transition in my local Uni's C++ cirriculum as a teaching
assistant and it made my life easier as a teaching assistent as well as
the student's lives easier.

In Python, you get a two-line effective Singleton pattern (Borg). Proxies
are easy. In another thread I posted a proxy-alike that when you need, you
need, and while I'm sure you could pull equivalent tricks in some other
languages, I bet none will be easier then Python. It's easier to write an
iterator-generator and a seperate function to do whatever it is you want
to do with the iterator then to merge data manipulation and traversal into
one function, as people so often do in other languages. (One of my recent
projects at work was just such a seperation, in Perl. The lack of
generators made the iterator's 'next' method very tricky to write, and probably
impossible for anyone else to modify in the future, even with my extensive
commenting and seperate paper documentation.) Adapters are typically so
easy it's scary. Queue makes it easier to do threading correctly then muck
about with semaphores in many cases. Metaclasses give one a shot at doing
things when the class system isn't enough. All bound together with a
simple and clean syntax that makes these features easy, not extremely
esoteric.

In the larger programs I write, I am frequently faced with the question,
"Should I kludge this feature in, or do a more general and theoretically
correct meta-solution and include the feature as a special case?" Python
is the only language I've used where the second option is frequently and
reliably actually easier then the first, *even if you only intend to build
that one feature on top of the more correct solution*.

To connect back to the original posting... it's a shame when people are
merely helped in their procedural ways without at least showing them the
better ways. Some people will program in
Python-that-might-as-well-be-COBOL, and perhaps the tutorials should start
with procedural to ease the learning curve, but they should at least be
exposed.