Author here. The move to TypeScript was due to multiple reasons, one of them as you mentioned. In these early years, there were very few people in the Clojure community which had an interest in these topics (general visualization/geometry related), and which wasn't just about art btw. Still, I managed to teach a dozen or so workshops from 2011-2017 and form a small community. In hindsight, Clojure/ClojureScript took off much more around 2018/19, 1-2 years after I left... c'est la vie
From a technical POV, the main reasons I started looking at other languages (Go, C11, TypeScript) back in 2015/16 were: Better performance and less effort required for working with low-level primitives & APIs. I also got more interested again in embedded development (wrote a long blog post about it[1]). The final decision was when I started using thi.ng for a large 5 year computational design tool/project at Nike...
Many of the language features introduced with ES6 (esp. generators, iterables, spread operator, Map/Set, Promises), suddenly made Clojure/ClojureScript feel much more clunky and I felt I can have a lot more fine grained control and performance with much less ceremony/effort, once I implemented (and usually also vastly extended!) some of the key Clojure features/datatypes myself... Working with modern Web APIs (WebGL, WebAudio, WASM, async/await etc.) all became so much easier...
The literate programming (LP) approach I used initially (between 2011-2016) was using the "standard" Emacs OrgMode Babel setup which I found an incredible amplifier for my work[2][3]. Emacs was widely used among the Clojure community back then, but LP itself as an approach _was_ unusual, still is, and scared people off...
[1] https://medium.com/@thi.ng/the-jacob-s-ladder-of-coding-4b12... [2] https://www.reddit.com/r/emacs/comments/9w8i2g/comment/ec7xv... [3] https://www.reddit.com/r/Clojure/comments/9deyxe/comment/e69...
Hopefully people see this comment b/c mine was a bad/incorrect summary :)
I real liked the orgmode workflow b/c the code was self documenting in a sense. I had a very similar workflow for many years (though I've since stopped) But I do remember that in the leiningen days when I was first learning Clojure, the idea of tangling and attaching my own fork was just too intimidating and confusing. With the deps.edn workflow it'd have been less of a hassle now
Thank you for all your work. I still used geom basically every week (generating graphics for my PhD)
Your blog post is great. I think your point about the silo'ing and lack of cross pollination of idea between langs/frameworks is interesting, but also a product of just time-investment. I used to code C++ and the C++ gurus were always very miopic b/c they simply had no time for anything else.
To the last idea, I feel the ease of creating and having performance available is always in tension. I have a friend who works in Touchdesigner and I'm always left a bit embarrassed that no written programming language seems to hit the same level of productivity. Going down the stack can be fruitful, but I think there are still more levels of abstraction that need to be explored. At a high level.. even if you're writing immutable functional code.. it just all still feels too coupled to me. These days, I'm personally think the next step is something like Pathom. Where your declare decoupled relationships between inputs and outputs and have a engine derive your computation.
Just to add to the above: It's not a comprehensive answer, but this always was a polyglot project. There're parts written in (and for):
- OpenCL interop (e.g. https://thi.ng/raymarchcl, https://thi.ng/simplecl)
- GLSL (e.g. https://thi.ng/shader-ast)
- C11 (e.g. https://github.com/thi-ng/c-thing, https://thi.ng/synstack)
- Zig (https://github.com/thi-ng/zig-thing)
- WASM (https://thi.ng/wasm-api)
- Forth (https://thi.ng/charlie)
There are infrastructure packages to simplify creation of ad hoc DSLs, their transpilation or interpretation, but also interop with WASM (so far mostly geared towards & tested with Zig), for example:
- https://thi.ng/parse
- https://thi.ng/pointfree
- https://thi.ng/lispy
- https://thi.ng/sexpr
In general, thi.ng projects range from super high level computational design concepts to low-level primitives like memory allocators and memory/data layout management (e.g. https://thi.ng/tinyalloc, https://thi.ng/malloc, https://thi.ng/simd, https://thi.ng/soa) and a huge spectrum of other things in between...