PHILOSOPHY(Y)  User Contributed Perl Documentation  PHILOSOPHY(Y)



NAME
       PDL::Philosophy -- what's behind PDL?

DESCRIPTION
       This is an attempt to summarize some of the common spirit
       between pdl developers in order to answer the question
       "Why PDL"? If you are a PDL developer and I haven't caught
       your favorite ideas about PDL, please let me know!

       An often-asked question is: Why not settle for some of the
       existing systems like Matlab or IDL or GnuPlot or what-
       ever?

       Major ideas

       The first tenet of our philosophy is the "free software"
       idea: software being free has several advantages (less
       bugs because more people see the code, you can have the
       source and port it to your own working environment with
       you, ... and of course, that you don't need to pay any-
       thing).

       The second idea is a pet peeve of many: many languages
       like matlab are pretty well suited for their specific
       tasks but for a different application, you need to change
       to an entirely different tool and regear yourself men-
       tally. Not to speak about doing an application that does
       two things at once...  Because we use Perl, we have the
       power and ease of perl syntax, regular expressions, hash
       tables etc at our fingertips at all times.  By extending
       an existing language, we start from a much healthier base
       than languages like matlab which have grown into existence
       from a very small functionality at first and expanded lit-
       tle by little, making things look badly planned. We stand
       by the Perl sayings: "simple things should be simple but
       complicated things should be possible" and "There is more
       than one way to do it" (TIMTOWTDI).

       The third idea is interoperability: we want to be able to
       use PDL to drive as many tools as possible, we can connect
       to OpenGL or Mesa for graphics or whatever. There isn't
       anything out there that's really satisfactory as a tool
       and can do everything we want easily. And be portable.

       The fourth idea is related to PDL::PP and is Tuomas's per-
       sonal favorite: code should only specify as little as pos-
       sible redundant info. If you find yourself writing very
       similar-looking code much of the time, all that code could
       probably be generated by a simple perl script. The PDL C
       preprocessor takes this to an extreme.

       Minor goals and purposes

       We want speed. Optimally, it should ultimately (e.g. with
       the Perl compiler) be possible to compile PDL::PP subs to
       C and obtain the top vectorized speeds on supercomputers.
       Also, we want to be able to calculate things at near top
       speed from inside perl, by using dataflow to avoid memory
       allocation and deallocation (the overhead should ulti-
       mately be only a little over one indirect function call
       plus couple of ifs per function in the pipe).

       We want handy syntax. Want to do something and cannot do
       it easily?  Tell us about it...

       We want lots of goodies. A good mathematical library etc.

AUTHOR
       Copyright(t) 1997 Tuomas J. Lukka (lukka@fas.harvard.edu).
       Redistribution in the same form is allowed but reprinting
       requires a permission from the author.



perl v5.6.1                 1999-12-09              PHILOSOPHY(Y)