Open arrdem opened 7 years ago
Thanks @arrdem for trying to making things better and challenging the status quo. I'm sorry to see Jaunt go this way, I think simply having these forks to demonstrate alternative ways forward is part of a healthy ecosystem. Good luck with Ox! I'm curious to see where that will go.
One thing I'm curious about: did you have any particular successes with Jaunt? Changes or improvements that really turned out well? Any hard earned lessons for the next person treading this path?
Versioning namespaces was an attempt to find a halfway point between immutable namespaces and the Clojure status quo of fully mutable namespaces. It turns out there are lots of subtleties here and that there are interesting ways that Vars can become "stale" (but still work!) due to partial code reloading and even common/idiomatic use. That is, versioned namespace and stale var warnings generated too many false positives to really have good ergonomics. I think you really have to go whole-hog immutable environments which is what Mikera's Kiss/Magic and my Ox try to do. It also created a bunch of problems like #150 because (typically older) Clojure code expects to just be load
ed by something and consequently in-ns
s to wherever its author thinks the defs should go. Core and pprint are particularly guilty of this.
Some of the stuff like #125 is just low hanging fruit. Why it isn't actioned in Clojure is anyone's guess, but those changes are so minor that anyone could make them and nobody is compelled to adopt Jaunt or more accurately accept it's risk in exchange for them. Likewise #45 (namespace and var deprecation) which supposedly Clojure will get a version of this in 1.9. We'll see, it'd be interesting to compare that implementation to this one. #51 is in the same boat, as is #40 and #41. There's arbitrarily much source material for this class of change sitting around in the Clojure bugtracker.
RT
support, when the real answer is that Clojure's core "interfaces" aren't generic enough and these things should be fully libraries. #43 is related to this problem.get
that isn't a static-typey as I'd like. This is the price you pay for trying to maintain compatibility. Also put the cramp on #151 and #155refer
and doing some really fancy head-standing in ns
and friends to suggest rewrites was nice, but again not compelling and made leveraging 3rdparty libraries really noisy with false-positive rewrite suggestions. This should have been a linter feature somewhere and a hard breaking change.In theory #2 could have been more linters as with #142, the problem is that if the linter is 3rdparty optional tooling rather than being baked in then nobody uses it consistently.
Using lein cljfmt
and astyle
to try to impose sanity on the codebase totally worked and was definitely worthwhile. I wish that lein kibit --replace
was more reliable because there's a lot of low-hanging syntactic fruit in terms of normalizing core that cljfmt
doesn't even try to capture.
clojure.core
is a monster, with a very non-obvious definition order largely because core
's first ~thousand lines is used defining fundamental operations and FFI to Java implementation details. This is important because it really comes to a head with the defn
and let
macros. def
, defn
and let
as we're accustomed to them all depend on the destructuring version of let
, which has a really surprisingly large transitive dependency set. While "simplifying" core
seems like a good idea at first you immediately run into this tension of should core
be a sprint to destructuring let
so that MOST of core
be written in terms of "normal" Clojure defn
and let
, or should all the FFI functions be written in the pre-defn-and-let subset of Clojure where first
and rest
are? Is doing either of these things actually an improvement? The way you solve this problem is by supporting cyclic dependencies "for real" which just doesn't work given Clojure's code loading model. This is why Ox (and Kiss and Magic) all aim for lazy loading with support for mutually recursive modules.
clojure.core
is too goddamn big. It does too much. There are a bunch of different small APIs in here that could all be their own separate namespaces.
clojure.pprint
and several other modules have no actual non-historical reason for being in core and should be removed. Except for compatibility concerns.
clojure.*
's test coverage is actually pretty spotty. Be careful.
doc/*
needs some love. It'd be cool if doc
was packaged and defs deferred their docstrings to articles in doc/
instead of having short terse-to-useless source comments.
There's something REALLY SPOOKY going in in the load order of Clojure's test suite. I did an overhaul of the test runner which helped make the fact that the test coverage is actually pretty spotty clear and made the test output more human friendly (https://github.com/jaunt-lang/jaunt/blob/develop/src/script/run_test.clj). But it looks like between writing .class
files all over everywhere (for reasons I never quite figured which may be a bug in Jaunt not Clojure) there's an ordering dependency between Clojure's test cases. If you shuffle test namespaces and try to run them in random order weird stuff happens.
I'm calling it. Jaunt's dead in the water.
There are a variety of reasons for this. I made too many changes. I didn't bake some of them well. Clojure is a very complex code base and I hit a number of walls when I tried to do various things. Things that should have worked didn't for strange reasons.
Ultimately, nobody else (with thanks to @danielcompton) ever really stepped up with ideas about what a "better Clojure" would look like. Despite grousing, the overwhelming majority of Clojure's community seems content with current leadership and direction (or lack thereof). As evidenced now by the bleached bones of Dunaj and Jaunt, there simply isn't a market for a "community" fork although many institutions operate their own internal Clojure forks.
For me, ox-lang/ox is next. It's a clean break. It's easier to work on without getting frustrated at the Clojure core or its various cultural baggage. It fits in my head and is a nice release at the end of the day.
I'd be pleased to hand Jaunt off to other maintainership, and would appreciate feedback on whether it's valuable to the Clojure community to leave this as a cultural artifact / warning to the wise or whether I should just shut it down.