Live data from Hacker News

Thi.ng – open-source building blocks for computational design and art

thi.ng

31–39 of 39 posts

Re: Thi.ng – open-source building blocks for computational design and art

#31
post #9

I see very nasty GPU bugs on this page. never witnessed it before. My laptop is macbook m3. I managed to record them https://youtu.be/9EpfeUbkPT8

FWIW this website is almost 6 years old and this is the first time I'm seeing this issue. The cubes are just simple 3D CSS animations/transitions, so not quite sure what would be causing this...

Re: Thi.ng – open-source building blocks for computational design and art

#32

[flagged]

#1 It's just stinky me responsible. No AI's been used (btw. the site is from 2020), neither on the website nor for any of the projects...

#2 This is potentially a Safari bug with interactive SVGs on iOS. JS usage on this site is minimal.

Re: Thi.ng – open-source building blocks for computational design and art

#33
post #23

Is that monorepo heat map visualisation also reproducible for other repos? It kicks ass

Not at the moment, but I was originally planning to put out the tooling for generating these visualizations. All created from local Git repos and some additional JSON metadata, completely dogfooding various thi.ng packages/projects...

Re: Thi.ng – open-source building blocks for computational design and art

#34

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?

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

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

Re: Thi.ng – open-source building blocks for computational design and art

#35

This has been around for a long time and I've always been so surprised it has had seemingly so little traction outside of the author's own projects. The love and care and thoughtfulness of every library has always been so great to explore.

I love karsten and have been following his work for a long long time. Used/Use his old toxiclibs library extensively both in processing and java. Have ported parts of it to golang for personal use. I want to say he also had some librarys for openframeworks/c++ and I probably used those as well (it was perhaps someone elses rough port of toxic to c++). Originally I bounced off this because of clojure, it just wasn't w…

Thanks, Brett! <3 :)

Re: Thi.ng – open-source building blocks for computational design and art

#36
post #12

Earlier quoted context omitted.

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 s…

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…

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

Re: Thi.ng – open-source building blocks for computational design and art

#37

Earlier quoted context omitted.

I love karsten and have been following his work for a long long time. Used/Use his old toxiclibs library extensively both in processing and java. Have ported parts of it to golang for personal use. I want to say he also had some librarys for openframeworks/c++ and I probably used those as well (it was perhaps someone elses rough port of toxic to c++). Originally I bounced off this because of clojure, it just wasn't w…

Thanks, Brett! <3 :)

I just cleared my desktop to look at one of your c-scapes! Simply amazing libraries!

Re: Thi.ng – open-source building blocks for computational design and art

#38
post #12

Earlier quoted context omitted.

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 s…

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…

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.

Post reply on HN