Results from the Fall 2009 Usage and Installation Survey - PDLPorters/pdl GitHub Wiki

The survey was begun in early November of 2009. As of November 9, 49 people had responded. It was initiated by David Mertens, who also came up with most of the questions. If you think any of the questions were silly, you know who to blame! Each question is given below as well as the possible responses and how they broke down. Every question required an answer except the second one.

TOC

Answer	Respondents	Percent
I write code that directly uses PDL on a regular basis.	24	49%
I make regular use of PDL through a script I wrote a while back, but I don't directly use PDL much.	10	20.4%
I used to use PDL, but now I primarily use some other software for numeric programming.	5	10.2%
I could never get PDL to install.	4	8.2%
I think it might be useful but I could never figure out how to use it for my needs.	6	12.2%

Answer	Respondents	Percent
Small and nimble number-crunching library with 100% guaranteed installation from cpan.	21	46.7%
Full numerical analysis suite, like Matlab or IDL, with built-in GSL and data visualization.	24	53.3%

Answer	Respondents	Percent
Smooth and trouble free	14	28.6%
Minor trouble	22	44.9%
Rather difficult	14	28.6%
So unbearable, I quit	5	10.2%

Respondents had the opportunity to describe what kinds of difficulties they encountered. These included the following:

• in 2.4.4 a test failed, could install via fforce install
• Debian installation was trivial, but the demos didn't work and 3D graphics were absent. CPAN installation failed. I had to install manually, checking the pre-requisites carefully.
• After installing (under Windows) even some trivial example code gave errors, which I could not resolve. The ActiveState ppm probably is incomplete. I will not (learn to) develop in PDL if much of the features do not work out of the box.
• most difficulty on Mac OS X, especially regarding graphics packages (pgplot, plplot).
• On Windows, it wasn't until recently that I could get the PGPLOT or any PDL plotting to work. On the Linux side I use Ubuntu and it seemed to work without any issues. I am still on 2.4.3 though.
• Couldn't get it to recognize/use my opengl install.
• Installing needed libraries and helper programs (e.g. PGPLOT) not easy.
• FORTRAN dependencies and GSL dependency on Windows. Some modules never installed due to lack of external dependency, but I don't use those modules so it doesn't matter.
• recommended libraries were not available at install time
• Sorry, can't remember. Likely external dependency stuff.
• Missing libraries, dependency trouble, compability issues
• dependencies, glitches with selection of fortran compilers, weirdness of PGPLOT installation
• installing TriD
• PGplot hard to install on cygwin
• Multiple troubles, a nightmare to install
• I became a PDL developer to get things to work.
• Proper finding and linking of libraries (especially PGPLOT, but also GSL and some others) under Mac OS 10.6. Ugh.
• MS-Windows was the worst platform. Have many compilers but different parts needed GNU stuff and others Visual-C. Number of dependencies too large for successful build - always 1 that would break.
• crapping out on PLPLOT and PGPLOT builds
• On a CentOS 5 machine, I did have to install PGPLOT manually, of course, and had to install the code manually but a lot of that was for a non-root installation. On Ubuntu, everything but PGPLOT seemed to install with very difficulty. But I want to add that I really like using PGPLOT, so I wanted to put up with its problems.
• I had lots of trouble trying to install from CPAN. No less than two hours of painful scrolling through cpan error logs, and googling around for answers. finally I got it installed, but only after serious determination on my part.
• On any new (Linux) system, getting all the dependencies and header files that I need requires multiple Makefile.PL iterations.
• I put my sysadmin through this, and didn't install myself. The biggest problems were the HDF hooks, and PGPLOT. I looked at the PLPLOT install and didn't even ask my techs to attempt that.
• did not work with the default installation of perl; needed to install perl-devel.
• 1. Dependencies, 2. use PDL; fails with use warnings fatal => qw (all); Point 4 below: downloaded packages and followed by-hand instructions. Ended up writing an install script.
• I had to run the installer before I got a clear sense of the required external libraries that I had to install.
• PLPLOT and HDF wouldn't install on Mac OS X

Answer	Respondents	Percent
Compiled from source	23	46.9%
Through CPAN	31	63.3%
Using ActiveState's PPM	7	14.3%
Through my OS's software package manager (apt-get, yum, pacman)	20	40.8%
I installed SciKarl	2	4.1%

Answer	Respondents	Percent
Yes	13	26.5%
No (or I don't care)	36	73.5%

Answer	Respondents	Percent
Yes	22	45.8%
No (or I don't care)	26	54.2%

Answer	Respondents	Percent
Better guidance for beginners (possibly including better documentation).	7	14.3%
Better documentation.	9	18.4%
Work with GPUs.	3	6.1%
Easily integrate with my C-code	1	2%
Plotting capabilities out-of-the-box	8	16.3%
Minimal footprint.	2	4.1%
Hassle-free CPAN installation.	10	20.4%
Packaged with my OS's package manager or standard installer	2	4.1%
Other (please specify)	7	14.3%

Specified 'Other' responses included:

• All of the above excepting the C-Coding.
• all of above! or C-code integration if need to choose one
• A better editor integration - e.g. with Emacs/Eclipse etc.
• more straightforward/complete complex numbers integration
• provide basic Matrix arithmetic features without depending on other packages
• De-bundle it. I'd like PDL::Lite to be an easily-installable module that doesn't depend on any graphics libraries. It would be great to have and I wouldn't mind having it as a dependency on my applications or modules. Also, I think that interactive CPAN installation is a bad idea, as it hinders batch automatic installing of several modules; and most often than not it's confusing for users.
• GUI like Matlab has