Defending the Python lanuage...

[Quinn Dunkan]

On Mon, 4 Feb 2002 15:22:23 -0800, Cliff Wells <logiplexsoftware at earthlink.net>
wrote:
>We developed this approach based upon statements made by Richard Stallman
>(and common sense ;) on the GNU approach to development: 
>
>1. no arbitrary limits
>2. embed a language in your application and use that to develop parts of
>the application
>3. turn parts of the program into independent libraries  <-- repeat,
>repeat, repeat
>
>To this I would add that using an n-tier design will greatly extend the
>lifetime of a piece of software (especially since much "upgrading" often
>involves cosmetic changes or changes that are irrelevant to the function of
>the software [like supporting a different SQL backend]) and makes things
>like redundancy easier to implement.  Of course this is just an extension
>of the Unix "tools" philosophy.

To me, it seems like especially #2 and #3 contradict the "tools" philosophy (or
at least what I understand that it is).  #2 because "tools" are scripted with
the shell and pipelines, or any language which can make use of the unix
fork()/exec() and pipe() syscalls such as python.  If they become so monolithic
as to require a seperate internal language or huge rc file, they're closer to
"applications".  #3 because in the tools approach, the programs themselves are
the units of reusability, not the code within the programs.  Hence, instead of
making a libjpeg that decodes and encodes jpegs, you write [cd]jpeg programs to
do the same, and read them through a pipe when you want a jpeg (this way you
also get a nice lazily evaluated data stream).

I'm not saying that the tools philosophy is the end-all be-all or that libjpeg
should be just the tools instead of the library and the tools, or anything bad
about libraries.  Tools force a simplicity of interface (single directional
data stream started by a small number of cmdline args) which is very good in
many cases and unworkable in many other cases.  INN is a good example of a
"tools" oriented program that I can't stand... but that may have more to do
with the 500 line shell scripts than the approach.  Definately a more
reasonable language is needed for things that are out of the shell's purview...
like, say, python (struggling to appear somewhat on-topic).