A post on high-dimensional arrays by @isomorphisms reminded me of APL and, more generally, of matrix languages, which took me back to inquisitive computing: computing not in the sense of software engineering, or databases, or formats, but of learning by poking problems through a computer.
I like languages not because I can get a job by using one, but because I can think thoughts and express ideas through them. The way we think about a problem is somehow molded by the tools we use, and if we have loops, loops we use or if we have a terse matrix notation (see my previous post on Matrix Algebra Useful for Statistics), we may use that.
I used APL fairly briefly but I was impressed by some superficial aspects (hey, that’s a weird set of characters that needs a keyboard overlay) and some deeper ones (this is an actual language, cool PDF paper). The APL revolution didn’t happen, at least not directly, but it had an influence over several other languages (including R). Somehow as a group we took a different path from ‘Expository programming’, but I think that we have to recover at least part of that ethos, programming for understanding the world.
While many times I struggle with R frustrations, it is now my primary language for inquisitive computing, although some times I dive into something else. I like Mathematica, but can access it only while plugged to the university network (license limits). Python is turning into a great scientific computing environment—although still with a feeling of sellotape holding it together, J is like APL without the Klingon keyboard.
If anything, dealing with other ways of doing things leads to a better understanding of one’s primary language. Idioms that seem natural acquire a new sense of weirdness when compared to other languages. R’s basic functionality gives an excellent starting point for inquisitive computing but don’t forget other languages that can enrich the way we look at problems.
I am curious about what are people’s favorite inquisitive languages.
3 responses to “R for inquisition”
“I like languages not because I can get a job by using one, but because I can think thoughts and express ideas through them.”
That’s the way I’ve come to view languages too. A couple of times in recent years with processing outputs from rather large groundwater simulation for make movies–private sector no software budget. I used awk to process the output files getting the data I wanted, used a couple of fortran codes to 1.) build binary data and 2.) build R input for individual frames, and finally wrapped the awk and fortran codes in an R script which set up directories, made the frame images, a little QA stuff, and bang it was done. Quick implementation because of the abilities of the different languages, runs were reasonably quick (R alone died on the vine), and everything was free. Can’t beat it.[Awk is a really neat tool]
As far as striking out in interesting directions–well lisp (CL mostly and Scheme) and prolog are truly engaging, but…. Flirted with APL long ago and a little more with smalltalk. Of the newer languages Haskell looks appealing so if I experiment with something new maybe it will be that. Clojure–well it is too closely hooked to java (development).
Anyway you asked. It was nice to run across this topic. Have fun.
Getting older by the moment.
Thanks for the comment. You reminded me of the post explorations in unix at Dr Bunsen. I find that for highly specialized jobs a combination of tools is best, although it requires good documentation of the process to make it reproducible, versus having code in a single language.
I can resonant with that Bunsen post intro. Though I came up thru the days of the mainframe and JCL, I initially learned some unix perspective when I was using DOS. The tool-set mentality really struck home and since that I’ve always tried to keep a number of unix tools on my MS machines. Needless to say, linux and OS-X figure in there now. There is/was always the chase for the best science platform.
Just as the ‘nix tools shape the numbers and text, different languages were the tools that I used to shape my thoughts on the machines. Breaking out of a ‘program’ mindset is the one of the best things than happened to me. I found mixing high-level tools eased the documentation and QA of a project. A big problem was the inside sell–getting buyin from project management–they often only see spreadsheets and widgets, even it those are totally irrelevant.
I hope you are able to always keep some inquisitive programming in your work. One has got to have some fun with the machines.