Cora Johnson-Roberson

2022 has seen amazing progress in machine learning. Text-to-image models like Imagen and DALL-E 2 have reached impressive levels of realism and aesthetic quality, while large language models like ChatGPT display unnerving prowess in coding and written communication. The pace of progress is dizzying, and the potential effects on society are not yet clear.

Dear Dad,

This story starts with one of your gifts to me. You’ve given me many gifts over the years: your confidence in my abilities, your compassionate listening, your reading Tolkien to me at night, your patience with me whenever I made mistakes or hurt you. Most crucially, though, you gave me a model of how to be a person perceived as a man, without rooting your selfhood in the domination of women. I have no idea how you were able to accomplish this in our patriarchal society – but Dad, since this is a letter to you and we’re both still here, I hope you’ll tell me yourself in your own good time (and that you don’t mind my sharing this).

This post takes the minimal Scala wrapper for UIMA from the previous post and extends it to make use of UIMA Asynchronous Scaleout (UIMA-AS), an extension to UIMA that allows for multicore/distributed analyses. UIMA-AS requires a lot of XML configuration files, which we can generate programmatically for convenience.

UIMA (Unstructured Information Management Architecture) is a general framework for analyzing unstructured content (especially text). The Java implementation of UIMA provides some infrastructure for natural language processing, but you’ll need some other pieces to actually perform analyses.

In this series, I aim to cover some ways to get started using UIMA with Scala, with the ultimate objective of creating a simple server to run analyses on request. This post will walk through some trivial analysis pipelines and show how to iterate over the results.

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 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.

One of the great motivations for using Nix to develop Haskell was the ease with which I can swap in profiling libraries (see this blog post for info). Another is the availability of binary caches for many of the other packages on which Haskell packages depend.

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.¹ Feminist and critical race theorists reveal how “objectivity” conceals and perpetuates gender and racial biases in the construction of knowledge.² In light of these insights, along with the persistence of race in the visible aspects of digital media,³ 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?