Nix offers declarative dependency management, making it potentially very useful for deploying web apps with exactly the dependencies you need. While this is unnecessary for Heroku-supported languages like Ruby or Node, Haskell deployment to Heroku can benefit greatly from what Nix offers.
I'm a Ph.D student in ethnomusicology at Brown University.
My research interests include music of the African Diaspora, dance and digital media, and virtual communities. I study how queer and trans people of color integrate technology in aesthetic practice, social interaction, and embodied experience.
I also enjoy solving abstruse technical problems.
I recently learned of Nix, which bills itself as a “purely functional package manager.” It tries to keep things as self-contained as possible, installing each package into a separate directory in its store. Nix is the basis for a Linux distribution called NixOS, but can also be installed standalone.
Nix has great benefits for Haskell development. Due to its insistence on isolation and purity, different versions of packages can be swapped in and out as needed, neatly avoiding “Cabal hell” and the need for sandboxes. As much as possible, the package manager reuses compiled versions of dependencies, greatly speeding up the process after the first time.
Cabal itself might eventually adopt the kind of hermetic builds Nix offers; however, Nix works quite well already for this purpose.
I found Pavel Kogan’s post on Haskell development with Nix to be quite instructive. In this post, I hope to provide some tips for using Nix for Haskell development, specifically on Mac OS X 10.10 (Yosemite).
Insights missing from most accounts of Rap Genius demonstrate the need for further ethnography of online environments.
NB: This piece evolved from comments I made in the 2013 #DHPoco Summer School forums, and was originally slated to be part of an ill-fated special issue of the Journal of Digital Humanities. I’m finally getting around to posting it myself, as of December 2014.
Scholars in science and technology studies tell us that computers, like all technologies, are embedded in a web of social relations which profoundly shape their development and use.1 Feminist and critical race theorists reveal how “objectivity” conceals and perpetuates gender and racial biases in the construction of knowledge.2 In light of these insights, along with the persistence of race in the visible aspects of digital media,3 we may ask: does race structure computing in profound, imperceptible ways? Furthermore, if race and racism are in fact implicated in the design of our machines, how can we work against their pernicious effects within the field of the digital humanities?