First of all I should say that there are no current plans to port slippery chicken. But: 

A humourously intended (though sarcastic: you know who you are!) post on my Facebook page asked me why my algorithmic composition software is written in Common Lisp and not something more modern (and Lisp-inspired) like Python. My first response might be something dismissive like “would you entrust your life’s work to a child?” (Python was nine years old when I started working on slippery chicken.) But that would be churlish. Python is now a well-respected and widely-used programming language. Back in 2000 however, a mature language like Lisp was perfect for me and for music projects, especially given that longevity was key to my decision of which language to use. In any case, as a proper response to the Facebook comment I reach for some presentation notes written for a talk at Goldsmiths College at the slippery chicken symposium there in 2016. My talk went through the issue of porting and considered several alternative languages. I include the considerations below, in all their bullet-pointy glory.

why port?

  • because Lisp is not (currently) the world’s favourite language
    • (((((and people say hurtful things about all those parentheses)))))
  • it’s not easy to release as a self-contained application
    • though implementations like LispWorks and Allegro CL make it possible

possible languages

Scheme

  • Scheme is a dialect of Lisp
  • would allow embedding
    • and perhaps integration with Common Music / Grace
  • but no (easy/flexible) looping
    • and isn’t object-oriented

Clojure

  • Clojure is very “Lispy”
  • is great at concurrency and therefore multi-core, multi-threaded applications
  • but slippery chicken is not CPU intensive and not multi-threaded
    • nor does it need to be
    • (plus clojure spits in the face of object-orientation)

Haskell

  • Haskell co-designer Paul Hudak is also one of the founders of the Computing and the Arts program at Yale
    • and author of the book The Haskell School of Music – From Signals to Symphonies
  • lots of packages online
  • but it’s statically typed
    • and purely functional (not object-oriented)

C/C++/Objective C

  • all of these and others (e.g. Java) are essentially compiled languages
  • so they don’t have
    • an intepreter
    • dynamic typing
    • native lists
  • but are extremely popular / supported
  • and integrate well into applications

Python

  • python is
    • a dialect of Lisp
    • interpreted
    • object-oriented
    • dynamically typed
  • python lacks the macro support of Lisp
    • though SC hardly takes advantage of macros
  • but python is much slower than Lisp (sometimes by a factor of 100, according to some)
    • then again speed isn’t a real issue in SC
  • so this would be the language of choice were I to port

so why not port (to anything other than python)?

  • First and foremost: 84,000 lines of code
  • Again: 84,000 lines of code
  • we love our objects
    • slippery chicken’s fundamental design is object-oriented
  • we love our interpreter
    • querying and manipulating object slots and other data is part of our musical workflow
  • we love our lists
    • not having to think about memory management and how many pitches or dynamics or rhythms we’ll need speeds up workflow
  • or more simply
    • Lisp rules
Share Button