31 ms·

I believe the new libs are now all in TS and not Clojure anymore. Does that mean TS is better suited for computational art? Or are there other reasons why thi

I believe the new libs are now all in TS and not Clojure anymore. Does that mean TS is better suited for computational art? Or are there other reasons why this lib was moved to TS?

simongray 3mo ago
> 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.
- toxmeister 3mo ago
  Just wrote more about it here: https://news.ycombinator.com/item?id=48468029 https://news.ycombinator.com/item?id=48468029
geokon 3mo ago
You can find his talk about it a bit on Twitter and in the Github issues. But as far as I remember it mostly boils down to the fact that thing/geom got very little traction and external contributions. He developed this huge ecosystem on his own to make digital art but it wasn't being really picked up by others. Digital art is typically quite collaborative with people giving workshops and stuff. The switch to TS was so that other's would join up and develop the library together. 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")
- WillAdams 3mo ago
  I really wish that there was an agreed-upon/universally-accepted Literate Programming system (or that for a given system, sufficiently varied tools for availing oneself of them as to foster acceptance), but pretty much every programmer's approach is unique, incompatible, and a hurdle for anyone else to use their code....
- toxmeister 3mo ago
  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-4b12477a26c1 https://medium.com/@thi.ng/the-jacob-s-ladder-of-coding-4b12... [2] https://www.reddit.com/r/emacs/comments/9w8i2g/comment/ec7xv5a/ https://www.reddit.com/r/emacs/comments/9w8i2g/comment/ec7xv... [3] https://www.reddit.com/r/Clojure/comments/9deyxe/comment/e6984at/ https://www.reddit.com/r/Clojure/comments/9deyxe/comment/e69...
  - toxmeister 3mo ago
    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/raymarchcl, https://thi.ng/simplecl https://thi.ng/simplecl) - GLSL (e.g. https://thi.ng/shader-ast https://thi.ng/shader-ast) - C11 (e.g. https://github.com/thi-ng/c-thing https://github.com/thi-ng/c-thing, https://thi.ng/synstack https://thi.ng/synstack) - Zig (https://github.com/thi-ng/zig-thing https://github.com/thi-ng/zig-thing) - WASM (https://thi.ng/wasm-api https://thi.ng/wasm-api) - Forth (https://thi.ng/charlie 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/parse - https://thi.ng/pointfree https://thi.ng/pointfree - https://thi.ng/lispy https://thi.ng/lispy - https://thi.ng/sexpr 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/tinyalloc, https://thi.ng/malloc https://thi.ng/malloc, https://thi.ng/simd https://thi.ng/simd, https://thi.ng/soa https://thi.ng/soa) and a huge spectrum of other things in between...

I believe the new libs are now all in TS and not Clojure anymore. Does that mean TS is better suited for computational art? Or are there other reasons why this lib was moved to TS?

simongray 3mo ago

> 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.

toxmeister 3mo ago
Just wrote more about it here: https://news.ycombinator.com/item?id=48468029 https://news.ycombinator.com/item?id=48468029

geokon 3mo ago

You can find his talk about it a bit on Twitter and in the Github issues. But as far as I remember it mostly boils down to the fact that thing/geom got very little traction and external contributions. He developed this huge ecosystem on his own to make digital art but it wasn't being really picked up by others. Digital art is typically quite collaborative with people giving workshops and stuff. The switch to TS was so that other's would join up and develop the library together. 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")

WillAdams 3mo ago
I really wish that there was an agreed-upon/universally-accepted Literate Programming system (or that for a given system, sufficiently varied tools for availing oneself of them as to foster acceptance), but pretty much every programmer's approach is unique, incompatible, and a hurdle for anyone else to use their code....
toxmeister 3mo ago
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-4b12477a26c1 https://medium.com/@thi.ng/the-jacob-s-ladder-of-coding-4b12... [2] https://www.reddit.com/r/emacs/comments/9w8i2g/comment/ec7xv5a/ https://www.reddit.com/r/emacs/comments/9w8i2g/comment/ec7xv... [3] https://www.reddit.com/r/Clojure/comments/9deyxe/comment/e6984at/ https://www.reddit.com/r/Clojure/comments/9deyxe/comment/e69...
- toxmeister 3mo ago
  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/raymarchcl, https://thi.ng/simplecl https://thi.ng/simplecl) - GLSL (e.g. https://thi.ng/shader-ast https://thi.ng/shader-ast) - C11 (e.g. https://github.com/thi-ng/c-thing https://github.com/thi-ng/c-thing, https://thi.ng/synstack https://thi.ng/synstack) - Zig (https://github.com/thi-ng/zig-thing https://github.com/thi-ng/zig-thing) - WASM (https://thi.ng/wasm-api https://thi.ng/wasm-api) - Forth (https://thi.ng/charlie 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/parse - https://thi.ng/pointfree https://thi.ng/pointfree - https://thi.ng/lispy https://thi.ng/lispy - https://thi.ng/sexpr 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/tinyalloc, https://thi.ng/malloc https://thi.ng/malloc, https://thi.ng/simd https://thi.ng/simd, https://thi.ng/soa https://thi.ng/soa) and a huge spectrum of other things in between...