"My approach to language design has always been that people should learn just enough of the languages to get their jobs done. They shouldn't have to learn the whole language to begin with. - Larry Wall "
I am one of those people who would much rather hire a programmer to write scripts to my specifications, but is not in a position to do so. Instead, I set out to teach myself the basics of a programming language so that I could perform permutation tests on data. It seemed to me that something so simple as the random permutation of an array could not be that difficult, and that basic input and output of data was so common, in any language, that even a beginner should be able to accomplish that correctly.
I shopped around for a while and even tried to do it in Nisus Writer (go figure!), until I saw a small and elegant script that included both AppleScript and perl. Using apple script, it called for an input file, and then the data was read into a perl array, concatenated and written to disk. I am very grateful to the author of that script, because at that point I was completely stuck with my data analysis. I had run into the limits of an Excel sheet and this script solved that specific problem. With this I already had input and output, so I just needed a small subroutine to do the permutations and presto!: a working permutation script (feel free to laugh at my naivité).
I thought I was ready when I saw the Fisher-Yates shuffle (page 121 of the Cookbook) and with a big smile sat down to write my first script. It turned out not to be that easy, but not too difficult either. Perl baby talk may not be nice to look at, but if it is fault free and gets the job done, then it is the answer semi-computer-savvy people like me have been looking for. I can even envision a Lego style of programming in Perl, were students are offered pre-built subroutines to toy around with. This would allow, for example, its use in a course-like environment, where the course is not about programming but something less arcane, like statistics.
But there is one lurking danger. At some point I will (have to) publish my results, in the knowledge that most of my scripts, save some components that I considered worthy enough to post, will not have been properly reviewed by knowledgeable people. As the responses to this post pointed out, I was lucky to have put it on public display here. But I would make myself very unpopular if I started to put all my individual scripts in 'craft' just to be sure if they are correct.
This leads me to the following questions:
1. Is it just a matter of programming self-confidence, to be able to say "this is finished and correct", without a uneasy sense that there may possibly still be a mistake somewhere.
2. What would you advice a "I just want to apply the basics correctly" type of monk like me?
3. What are the inherent dangers of cut and paste programming?