牛: Some motivation

27 Jan 2015

Here is some of my motivation for Oxlang. I’m sorry it isn’t shorter, I gave up on copy editing to turn in. This was originally a personal email and appears almost unaltered.

Clojure is awesome. It is grammatically simple with a classical lispy syntax, and its cheap immutable data structures enable equational reasoning about most problems and solution tools.

My top bugbears & goals:

Contributor culture. The contribution process should be as open, friendly and low friction as possible see Guy Steele’s comments, on growing a better language from one with warts through acceptance of contributions. The GHC team has a “3% rule”, in that if a change improves the language or the type checker and comes at a cost of less than a 3% slowdown it has a high probability of being accepted and acceptance/rejection is publicly debated ala LKML. Commentary on the Clojure process may be inferred.
Formalism. Formalism gives portabity and is the only real rout thereto. Parser spec. Evaluator spec. Kernel standard library spec with a features list. This enables portability of code and data structures. Keeps us out of the JVM centric mess that Clojure itself is close to right now.
Documentation. I built Grimoire (Introduction post) because frankly I think that the existing Clojure documentation is lacking and there is not interest from the Core team in improving it as evidenced by the consistent rejection of patches which change doc strings beyond simple typo fixes. Goes with formalism requirements.
Hide the host. That formalism should include the call stack and exceptions. Use the host under the hood sure, but don’t leak the host for the most part. To paraphrase Paul Phillips, Just because Java or Clojure jumped off a bridge doesn’t mean we can’t have nice things like Data.Ord. This likely means making interop deliberately second class. Possible even explicitly generated from introspection but not the common case. Musings on this may be found here.
Types (and protocols/interfaces) matter. Clojure and much of the Cognitect crew seem to pretend that they don’t. It feels like not a week goes by without someone in IRC or twitter posting a function that checks the run time type of some value against some implementation type of Clojure’s core. Aphyr obligingly posted today’s, clojure.core.incubator/sequable, I have a few. Enable static reasoning rather than pretending it doesn’t matter and that nobody does it. Edit: From the horse’s mouth. Bake in type inference and something akin to prismatic/schema.
Purify the language implementation. Practice what you preach. Oxlang/Kiss’s immutable environments absolutely required. Death to &env, *ns* and mutable namespaces, do reloading by dependency tracking.
Give thought to being self-hosting. It’s not essential off the bat, but it makes porting & compatability easier in the long run. GHC’s bootstrap & rebuild itself process beccons and Toccata plays the same trick.
Give more thought to the module system & versioning culture. I want to be able to depend on “something implementing these functions in the namespace clojure.core then require those and alias them in as such”, not “Dear lein, this exact version of this library, thanks no ranges can’t trust anyone. Okay lets just load crap up”. The language should enforce versioning b/c programmers sure as hell can’t be trusted with it. Note that this goes with my first point to lower the cost(s) of churn in the standard library.
Tooling. I’m with Chas in his comments here. As hinted in 8, the language needs to provide as much support as possible for editors, for REPLs, for packages, for optimizing, for testing. These are the things that make or break the UX of the language and if the UX isn’t good people will just go back to writing node.js or whatever the latest flavor of the week is. Tooling is hard and takes time, but it must be a goal. I also went over this in ‘On Future Languages’.

All of these (save the parser and evaluator spec) are goals towards which work can be accumulated over time once the semantics of the language are agreed upon. Tooling, types, speed, correctness analysis can all be done if changes (growth) is cheap and the goals are agreed upon.

I think that given these changes it would be pretty easy to design embedded and memory restricted targets for “Clojure”, and I’ll admit that the goal of writing an OS with this language is near to my heart but for the most part I want to improve the platform independent experience since most of the code I write isn’t platform bound it’s exploratory scratch work.