Python so far

[Courageous]

> > Python may be too slow for some tasks, but in the area
> > of programmer productivity, very little beats it, and
> > arguably the environments that do (e.g., lisp) have too
> > many other negatives associated with them.
> 
> Care to explain?

Very high learning curve. Syntactically heavy weight. High
current cost of maintenance. Continually deteriorating
support and availability of technical expertise. Expensive
license fees from Franz. Paucity of recent commercial publication,
indicating failure of advancement of the state of the art
vice recent trends.

> I think Common Lisp already has some good solutions to many issues
> confronting Python now:

Yeah. The Gods Of Python ought to take a look at the first
three of these, but if they do number four, they're all first
up against the wall when I become Supreme World Leader. :)
 
> - Optional type declaration;
> - Optimizing compiler (taking advantage of the type declaration);
> - Powerful macro (superseding the need for preprocessor);
> - Pseudo case insensitivity...

This actually irritates the shit out of me. One day I'm going
to have to get even with my coder friends who treat case in
their lisp files AsIfITDoesNTMatTEr.

> Even the syntax (parentheses) became an asset after I learnt to use
> Emacs effectively.

Arguably, it's a very bad sign when a language is so complex
that it requires an editor tuned to it in particular in order
to be effective in the language.

For example, try compiling any decent sized lisp files in ACL
without doing it from inside an emacs buffer, and watch the
nightmare begin. The interpreter will happily have aneurisms
without so much as indicating the line it was having trouble
with. Perhaps the lisp "gurus" I am learning from aren't so
guruish, but they insist that there isn't any straightforward
way to request the line number of a load/compile failure from
the interpreter.


C/