Bulk Code Generation 150 150 craig

Bulk Code Generation

As much fun as coding can be, I prefer to write code that generates code.

My most recent effort is gostd2joker, which collects information on Go’s standard library (the packages provided in its source tree) and generates the Go and Clojure code to provide access to some of those APIs within Joker, a Clojure interpreter that is written in Go. While there remain substantial limitations in terms of which APIs are eligible for transformation, the resulting list of converted packages is noticeably larger than that for “vanilla” Joker.

Having successfully deployed a few Joker scripts on my email server, mainly to test the waters (but also to replace fairly ugly Bash scripts with more-elegant Clojure code), I’m looking to further my use of Clojure. I’d like to achieve “Clojure Everywhere”, in which all my full-stack code (UI, backend, and quick-running scripts) is written in Clojure on top of various hosts (JVM, JavaScript, and the Go runtime).

Much work remains to be done, mainly to instill, in Joker, a proper concept of the Go runtime as a “host” to parallel Clojure’s JVM and ClojureScript’s JavaScript engines, thus introducing Go types (native and those provided via packages), field and method access to them, instantiation of instances of them, and so on.

The result should be quite useful, not only in my own research and development, but potentially to others who might find a quick-starting, low-overhead scripting language, with full access to the Go runtime, to be a formidable tool in their scripting arsenal.

Can you envision using such an enhanced version of Joker? If so, how?

Housekeeping Note 150 150 craig

Housekeeping Note

I’ve started deleting users who haven’t commented on, or posted, anything, to get rid of the many likely-spam/bot users.

The bulk-delete tool I’m using doesn’t let me filter on whether a user has a profile image, and it appears to have already deleted at least two legit-looking subscribers. So I’m holding off deleting more for now.

Please login and comment/post on occasion, at least for awhile, as I clear out inactive users. (I’ve added a plugin to reduce new-user registrations from known spammers as well.)

Thanks for your cooperation!

On Sustaining Free-software Ecosystems 150 150 craig

On Sustaining Free-software Ecosystems

How can organizations that depend on free-software components ensure that they are maintained and available, which requires (first and foremost) funding component developers? This article explains some different approaches to that problem.

Open source sustainability

Performance of LispZeroGo vs LispZero (C) 150 150 craig

Performance of LispZeroGo vs LispZero (C)

Over the past several weeks, I turned my attention to assessing the performance of various Lisp implementations, focusing on suitability for short scripts, launched as processes, very frequently as is consistent with the traditional Unix model and exploited by messaging systems such as qmail.

Here are some interesting results on the use of Go, versus C, as an implementation language for a Lisp interpreter (Clojure in particular, though that’s not involved in these results):


tl;dr: Go is. Really, really fast, at least on this simple code and its few tests. It’s certainly not enough slower than C to justify implementing a Lisp interpreter in C, especially when there’s already a decent, albeit young, Clojure interpreter written in Go.

There’s plenty to be said (and has already been said) about Go versus C. I found debugging Go code to be challenging, as the use of GDB was discouraged, and Delve does not meet my requirements for easily debugging such low-level code. But the packaging system (the go tool) is fairly well-thought-out, easy to come up to speed on, and surprisingly free of warts.

Great job, Go people!