We’ve reached the point in our project where the group is beginning to get into basics of coding.
I find this phase of the project very engaging. I think all of us have at some point thought “I could make that (application/database/widget/user experience) better,” and digging into code opens the door to just how that might be done… even if we are talking about baby steps here.
There has been a lot of interesting discussion in the past couple years about the perceived merits of “everyone learning to code” (for example, this piece from Aug 2013 on Slate.com presents a skeptical view of this notion; another interesting recent discussion is here, on the Communications of the ACM website). A little knowledge can be a dangerous thing. In our case, I think that as a group we’re reasonably (and realistically) focused on gaining a basic literacy in the language(s) we’re most likely to encounter, without expecting to become expert coders - but learning enough to implement our History of Morningside Heights project.
I’ve had some early skirmishes with coding: in the late 1980s I did some coding in the early audio programming language Csound:
I would type text files of instructions to create sound, and then send them to a PDP-11 computer in the basement of MIT’s Experimental Media Lab:
After a few minutes, sound (often a dreadful shock) would come back, and it would be back to the drawing board, to refine the code in the instrument definitions and score file.
The reason I mention this ancient ritual is that I am relieved to see that the proposition of learning and writing basic code has become easier, much easier, over time, and there are now many options for languages where significant parts of the repetitive “grunt work” and housekeeping routines have been taken care of for programmers. Things have gotten more modular. In addition, many free and user-friendly beginning coding sites and resources have sprung up, such as Codecademy. Alex, our fearless instructor on matters digital, has also recommended sites like “Learn Python the Hard Way” (but, the term “The Hard Way,” I admit, gives me pause!)
One of the questions that confronts me, and probably others of us dipping our toes into coding, is “which of the many languages could/would/should I learn?” I’m not sure what that the answer is, but suspect it might run something like this - learn a basic familiarity with those languages that we might commonly encounter in our partnering with faculty and technologists on digital projects, and then, go more in-depth with a language (or languages) with which we ourselves might want to learn to build things (yes, we can!). With suites of languages and modular tools focused on building web applications, the ever-increasing availability of APIs and open data sets, it begins to seem plausible that one can build something, without being a dedicated computer science expert. For example, I was motivated and impressed by a recent project built to synchronize highlighted scanned music notation with audio playback, the Augmented Notes tool. The author, Joanna Swafford, was able in a couple of years to learn the skills to be able to do this. For me, Python seems to be a good place to start. I’ve begun the Codecademy tutorials, and am excited to attend a class on Python for humanists. Python makes sense for me because I had a chance to informally poll a crowd of researchers at a recent Music Information Retrieval event the Libraries hosted here on campus, and although a lot of earlier work in this area was done in Matlab, Python emerged as a strong recommendation for new work going forward. I plan to pursue this as my entree into current coding, and then branch out from there, as it intersects strongly with my desire to learn to work with Music Information Retrieval tools and techniques, and with some of my personal creative interests.
So, “Hello World,” off I go on the coding adventure. Wish me luck!
