Thi.ng – open-source building blocks for computational design and art
thi.ng
thi.ng
Looks like a collection of many useful general-purpose dependency-free modules written in TypeScript.
fun fact: you can reach each package from a https://thi.ng/PACKAGE short URL, e.g. https://thi.ng/color.
I started using the thi.ng collection a couple of years ago when I had more time for creative code sketching (https://guidoschmidt.cc/sketchbook, father of two now, with full time work + family its hard for me to find time and motivation at the moment. Hopefully will get back to it more in the future), still only scratched the surface yet.
https://www.creativeapplications.net/people/karsten-schmidt/ has a great history of Karsten's work. Also worth checking out his mastodon profile: https://mastodon.thi.ng/@toxi
Of the thi.ng library I've only looked at a few modules so far but I really like the clean organization, functional style, and how each module is independently useful. The whole thing has good taste, a quality that's hard to explain but "you know it when you see it." I'm looking forward to playing with it, like a new box of Lego blocks, haha.
Originally I bounced off this because of clojure, it just wasn't worth the time to learn. Now it's typescript.. another language I'm just not interested in learning. I'm happy to port whatever bits of the library I want to use to a language I prefer when I need it.
But this is a absolutely remarkable set of libraries covering all kinds of nooks and cranies. It's worth putting on everyones list.
I managed to record them https://youtu.be/9EpfeUbkPT8
That's an interesting take at ECS, seems to do lots of optimizations under the hood too.
I'm surprised to not have heard of those libraries until now.
All the pieces are very decoupled and in pure Clojure (unlike a lot of the heavier scicloj stuff that's being use nowadays)
Does that mean TS is better suited for computational art?
Or are there other reasons why this lib was moved to TS?
I'm pretty sure reach was the motivation. The author basically wrote his own TypeScript libraries duplicating a bunch of Clojure stuff, so the code is quite Clojure-like still.
Note that part of the problem was that the library was written in a highly unusual literate style. So you had to clone the repo, then use Emac's Orgmode to tangle it to get the Clojure source code. This created a lot of friction for people to contribute.
Also before deps.edn (Clojure built-in dependency management) was added to the language you had to use leiningen which didn't make using a locally cloned fork as easy as it is now (now you just point to the library file directory and it "just works")
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...
- 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:
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...
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.