© 2026 Reid D. McKenzie, all rights reserved.
Disclaimer: Oxlang is vaporware.
It may exist some day, there is some code, however it is just my thought experiment at polishing out some aspects of Clojure I consider warts by starting from a tabula rasa.
The following represents a mostly baked scheme for implementing ns and require more nicely in static (CLJS, Oxcart) rather than dynamic (Clojure) contexts.
In Clojure and pure functinal languages, the abstraction is provided
that values cannot be updated, only new values may be
produced. Naively, this means that every update to a value must
produce a full copy of the original value featuring the desired
change. More sophisticated implementations may opt for structural
sharing, wherein updated versions of some structure share backing
memory with the original or source value on the substructures where no
update is performed. Substructures where there is an update must be
duplicated and updated as in the naive case, but for tree based
datastructures this can reduce the cost of a typical update from
O(N) on the size of the updated structure to O(log(N)) because the
rest of the structure may be shared and only the “updated” subtree
needs to be duplicated.
牛 (Ox or oxlang) is an experiment, a dream, a thought which I can’t seem to get out of my head. After working primarily in Rich Hicky’s excelent language Clojure for over two years now and spending a summer hacking on Oxcart, an optimizing compiler for Clojure, it is my considered oppinion that Clojure is a language which Rich invented for his own productivity at great personal effort. As such, Clojure is a highly oppinionated Lisp, which makes some design decisions and has priorities which seem to be starkly at odds with mine.
As Paul Philips notes at the end of his talk We’re Doing It All Wrong [2013], ultimately a programming language is incidental to building software rather than critical. Ultimately the “software developer” industry is not paid to write microcode. Rather, software as an industry exists to deliver buisness solutions. Similarly computers themselves are by a large incidental. Rather, they are agents for delivering data warehousing, search and transmission solutions. Very few people are employed to improve software and computer technology for the sake of doing so compared to the hordes of industry programmers who ultimately seek to use computers as a magic loom to create value for a business. In this light I think it’s meaningful to investigate recent trends in programming languages and software design as they pertain to solving problems not to writing code.
When I enrolled in UT Austin’s “student startup semenar” one of the guest speaker comments which stood out to me and has stuck most firmly in my mind is that “there are no new ideas, only good execution”. This particular lecturer described how he kept a notebook full of random ideas he had for possible businesses, and talked at length about the importance of validating business models through surveys of potential customers as well as discussions with industry peers. The takeaway he left us with was that consequently rather than attempting to operate in “stealth” mode as seems to be fashionable for so many startups developing a product, he argued that ideas are so cheap and the first mover advantage so great due to simple startup execution costs that attempting to cloak a startup’s model and/or product generated no measurable advantage and had a concrete cost in terms of potential comment from consumers and peers which is lost as a consequence of secrecy.
Well, the end of Google Summer of Code is in sight and it’s long past time for me to make a report on the state of my Oxcart Clojure compiler project. When last I wrote about it, Oxcart was an analysis suite and a work proposal for an emitter.
When I first got started with Clojure, I didn’t know (and it was a
while before I was told) about the Clojure.repl toolkit which offers
Clojure documentation access from within an nREPL instance. Coming
from the Python community I assumed that Clojure, like Python, has
excellent API documentation with examples that a total n00b like
myself could leverage to bootstrap my way into simple competence.
Well, it’s a month into Google Summer of Code, and I still haven’t actually written anything about my project, better known as Oxcart beyond what little per function documentation I have written for Oxcart and the interview I did with Eric N.. So it’s time to fix that.
The history of computing machines is long and complex. This time last year, I had finished the single class I’ve enjoyed most in my academic career to date: CS 352H, “Computer Architecture”. In this class, we explored at great length the history of computing machines and the various designs which have been developed and sequentially abandoned in the pursuit of speed over the past decades.
Okay. Previously we tried to get more parallelism and work per cycle out of our machines by running two streams of instructions more or less in parallel by having two parallel synchronized pipelines. But we hit a snag with this: data dependencies in between pipelines forced us to stall, thus loosing us whatever benefit we had hoped to reap from instruction level parallelism.