I am in Santa Maria di Leuca, Puglia, at the very southern tip of Italy currently, and as such only reading is on my agenda for the coming week. I’ll finish Karatani (more on progress in Section 6.0.1), and restart Jensen Suther’s True Materialism, a book I’ve been meaning to discuss with Carson Welch for a few months now—and as the summer heat really sets in, we’ve slapped a date on it.
I worked more through Karatani’s Transcritique this week and am a few hours away from having detailed notes across all of its chapters. I’ll preview my organised thoughts about it here, as next week I’ll flesh them out some more, perhaps in a blog post on my main blog.
As far as I can tell, Karatani is a critic on pretty low volume in the English-speaking world, given that he is a figure apparently as great in stature in Japan as Fredric Jameson is in America. Architecture as Metaphor and Transcritique were translated by Sabu Koshu and published with MIT Press in 1995 and 2005 respectively. Columbia University Press published History and Repetition in 2011 ; but it was not until the publication of The Structure of World History with Duke University Press in 2014 that the Anglophone Marx studies world seems to start really discussing his work.3 Duke then published Isonomia and the Origins of Philosophy in 2017, Oxford University Press Nation and Aesthetics also in 2017, and two more translations of Karatani’s work have been published by Verso in 2020 and 2026.
There may be other translations into English that I’ve missed, as Karatani has written and published more than 20 books in Japanese over the course of a career that runs from 1980 to present. But despite this good number of translations, I am now surprised that I have heard so little of his work having read Transcritique. The book argues that transcritique is the common methodological thread that ties Marx to Kant, and in turn re-reads Marx’s Capital as a transcritical reading of political economy. For the uninitiated, this is heterodox essentially because it has been much more common to tie Marx tightly to Hegel, rather than Kant, both because Marx explicitly positioned Capital as a counterpoint to Hegel’s dialectical method, and because his intellectual biography has much more obvious ties to him. Whether it matters or not for our reading of Capital and Marx is the table stakes of the debate. (Whether reading Capital and Marx in the 21st century matters is the topic of my dissertation. Spoiler: I argue that it does, and that we have few better philosophical resources for thinking about the social architecture and politics of computer science.)
I’m hung up on Karatani at the moment because he argues in Transcritique that Capital is “a Kantian critique of the ill-contained drive of capital to self-realize beyond its limit” [1, p.9]. Karatani divulges to the reader a wealth of good thinking about these terms—critique, drive, self-realization, limit—in a number of respects; but the fundamental aspect of Marx’s work that his argument’s vocabulary opens up for me is its mathematical nature. If Marx is a student of Kant, then he is a student of formalization and the ways in which we can (and can’t, or shouldn’t) claim its intricacies bear a relation to reality. As noted, I intend to digest Karatani’s Transcritique more directly somewhere soon, so that’s all I’ll say for now. What reading Transcritique has confirmed for me is that I need to read Karatani’s other work, especially his writing on Marx (Marx: Towards the Centre of Possibility and The Structure of World History), and learn more about 20th century Japanese Marxist thinkers such as Uno Kōzō.
At the beginning of the week, I wrote a full first draft of a section for a paper formalizing the kinds of experiments that we’re running. It needs a bit of work—I run the risk of overformalizing aspects of our experimentation, and we also need to do some more literature review to understand whether or not aspects of our approach go by other names in other fields of machine learning—but it was a useful start.
I also got the codebase running on my new Framework Desktop with a PR adapting CUDA (Nvidia) hardware acceleration to ROCM, the analogous software that allows GPUs to process machine learning tasks on AMD. This was pleasantly straightforward, as hardware acceleration in Python has come a long way since I was last messing with it in 2018/19. I’m really excited about this project, as I hope it will be a real contribution to machine learning interpretation from a more humanistically-centered place.
No direct progress on Rheo this week, besides tracking a few issues following from the Typst 0.15.0 release. As per the intro above, likely nothing substantive this coming week either. I am, however, reviewing the Typst documentation and reference for an upcoming interview for a limited project.
Most of my week was sunk into developing a new feature for a platform for a forthcoming investigation about migrant pushbacks on the Mediterranean. I made a false start at rewriting the whole thing in bonsai a couple of weeks ago, but deadlines have demanded that I fall back into React.
The technical details of the platform are, alas, no longer very interesting to me. There was a time when I was excited to learn about the browser, WebAssembly, and other infrastructures of frontend development, but several years at grad school have shifted my perspective pretty substantially. One of the most difficult things about frontend engineering, I think, is that it almost always means you are interfacing with designers and/or clients who don’t have substantial software knowledge directly. This is essential and necessary work in so many domains; but it’s densely difficult, and requires good communication across many channels, which means meetings, changes, backtracking.
Frontend engineering is sometimes colloquially treated as less technically requiring than backend engineering or systems programming. To me this stems from a misunderstanding about what is hard about building software, about what it means to be ‘technical’. It’s easy, relatively speaking, to identify a problem in a domain with people who all speak your language, who all generally speaking approach the problem in the same way. It’s much harder to work effectively in the squishy channels of human-to-human communication, parsing and formalizing desires as features, and doing so with a bedside manner that allows everyone to feel like they’re getting what they want. Frontend engineering is almost definitionally on the frontlines of this kind of work, the most difficult aspect of engineering, because the browser is one of the most common places where software systems get exposed to users with vastly different understandings of computation.
Grad school has been a haven for me in which I have been allowed to work without guardrails towards aims largely of my own choosing.4 I have chosen to work almost exclusively in Rust, a programming language at the other end of the spectrum: by design/definition, Rustaceans (those who work in Rust) get to work with colleagues who have a shared understanding of computation and how to handle it. An absolutely banal yet absolutely accurate observation: there is a cooperative joy to sharing a community with others who share your basic understanding of what work is! If given the choice, I can’t help but think that I would rather not do the hard, labyrinthine, and mercurial labor of translating between computational dialects, as good frontend engineers must do. Let me work in a terminal and modal text editor on a NixOS machine, so that the only people I have to explain my work to are those who already understand the vocabulary in the first half of this sentence.
Despite the above disavowal of frontend engineering, I have enjoyed learning the level of abstraction at which one needs to prompt models like Anthropic’s Opus 4.7 to get meaningful results in frontend development. It’s often not enough to say something like “make the red square clickable”, as an LLM is much more effective if you gesture using the language of HTML and CSS (“make div.nav-bar-button clickable”). Thinking clearly about data structures and how they will support the functionality in your application is also work worth doing, as Claude will not (in my experience) do it for you.
On the long train to Puglia (from Reggio Emilia, 8ish hours) I downloaded ElevenReader and started listening to some PDFs and EPUBs I’ve been meaning to read as a rest from my reMarkable. This was surprisingly successful, and I will experiment more with this synesthesia while on the beach. (Though it has no problem with the sun given its e-ink, I’ve never quite managed to read successfully on my reMarkable at the beach given the sand, sweat, and heat.)