toxmeister

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

Thanks, Brett! <3 :)

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

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

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

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

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

Thanks - some of the reasons for giving up on LP using org-mode are here (mainly external factors):

- https://www.reddit.com/r/emacs/comments/9w8i2g/orgmode_liter... - https://www.reddit.com/r/Clojure/comments/9deyxe/thinggeom_a...

The main feedback re: LP style was the additional layer of indirection and unfamiliarity with the idea of code blocks within an .org file. Also obviously the dependency on Emacs for a decent editing experience of these files didn't help either, even though I always thought for Clojure this was less of an issue (at least back then). With more popular IDEs available by now, I'd say it'd be even harder to convince people to contribute in that style...

The only practical advice re: community building I can provide is trying to be there for new users, providing answers/guidance/examples/infrastructure, a space to exchange ideas (i.e. our Discord). That's especially important if other things like extensive documentation/tutorials are still missing. Doing this isn't always easy and there're periods when I'll have to disconnect, but I'm super grateful that we now are starting to have more people helping out on that front, even though the community is still rather small...

Thanks for the notespace link, will it check out asap...

Creative computing is just a subset of computational design though and wouldn't have sufficed... also see my answer here: https://news.ycombinator.com/item?id=25263818

Thanks, Thomas! The #1 issue is that a singular entry point simply doesn't exist, largely because of the sheer number of different projects, platforms and use cases involved. The interactive tag cloud was supposed to be the main starting point mechanism, allowing users to explore projects by topic. Yet, somehow this doesn't seem to register with people (at all)... Also, all the timelines have tooltips, are clickable and take you to their respective project pages.

Comparisons with tools like Processing/OF aren't right or fair either, because they focus on a much smaller feature range and then rely on external plugins to expand scope. thi.ng projects have a bias (in terms of percentage of sub-projects) towards data structures, geometry and graphics, but, at large, ALSO cover the "full stack" (arrrgh!!) via tools for: baremetal programming (e.g. on Cortex M4/7 ARM devices), functional & reactive programming, data processing (transducers, datastructures, querying), there're several DSLs & general DSL tooling for creating new ones (parser generators, interpreters, transpilers, VMs), audio/DSP (signal generators, oscillators, filters), file format support (importers, exporters) to UI (for web, desktop, in multiple languages)... Also don't forget most of these libraries are independent. So I'm genuinely, genuinely wondering how one would distill this into a traditional landing page setup? Also, how this is comparable to say P5? It isn't, not even close!

What this discussion has brought out and confirmed again (to me, at least) is the commodification of ideas and the explicit expectation of ideas packaged into easily consumed products. Products, which can be consumed and need to provide a quick sale, regardless of conceptual depth (or breadth in this case)... it's a little sad to see! By that logic I'd need to create 250 websites... and there also somewhat are already: Most projects have their own URL (e.g. http://thi.ng/transducers, http://thi.ng/morphogen etc.)

I'm really not trying to be defensive (even if it might come across as such, merely trying to provide more subtlety & context to some of the comments). I'm thankful & there's a lot of food for thought how to approach the next phase of development, but I'm honestly surprised by some of the comments (esp. from this crowd)

I didn't mean to imply that your comments are invalid, they're fair enough. Though, this is NOT a sales website, it's a springboard/archive of a body of work, spanning 15-20 years (eventually)...

My sense from some of your above argumentation and issues re: word choices, is that there's somewhat of an implicit expectation of the uniform format of SV-stylee startup landing pages and JS libraries: snappy big letter bullet list of selling points, 5-line code examples and a big fat get started button...

People with such expectations really haven't been the audience so far and likely never will be. Can I/we do a better job to demonstrate use cases and help guiding people discovering relevant projects for their use cases? Yes, definitely, but bandwidth issue, function over time. Though, it's very likely the following will remain an unmovable truth (as explained on the thi.ng/umbrella readme):

> This project is NOT a framework, provides no turn-key, one-size-fits-all approach and instead encourages a mix & match philosophy for various key aspects of application design.

There're many (likely experienced) developers who do very much appreciate such an approach, just as there will be developers for which this means a no-go zone. I think this is fine.

(...and again, I sincerely thank you for your feedback - food for thought!)

This is great feedback! I've got a lot plans for those areas, but the main roadblock is personal bandwidth. This has primarily been a spare time project for the past 4-5 years...

There're ~100 examples for thi.ng/umbrella alone, all commented, all linked from the readme's of each package used. Additionally, I've spent a lot of time this year adding more readmes, docstrings (again with examples), create diagrams etc. I completely get your comments/position, but I'm also really wondering if any of this work is just wasted effort if no one actually reads/looks at that stuff... and that then makes it even harder for me to prioritize.

FWIW I will also start streaming again in December, focusing on smaller projects/examples than previously. Maybe that format will work better for newcomers.

Obviously, there's no desire from my end to be overly cryptic about what you can do with these projects, but whereas P5, OF etc at their core all have a fairly narrow scope (DSLs for OpenGL API and some data wrangling sugar) and only gain their incredible flexibility through various addons and sheer community size, thi.ng simply has no core and that is the hardest thing to "sell" to people, even though IMHO it's also one of it's most unique aspects...

thi.ng is an ecosystem (as others have put it), not following the standard main pillar/silo + plugin architectures...

Happy to entertain equally succinct counter proposals :)

Ok, I think the issue is that people really just don't read anymore :)

First paragraph, second sentence:

"Not a framework, nor bound to any specific use case, environment or even language, it's a vast and mature set of complementing code libraries, which has organically grown to approx. 250 sub-projects"

As for the topic search: The search box says "search by topic" (fuzzy search) - the tags in the tag cloud are all clickable. Is that really not obvious (even though it's also mentioned in the text)? Click on "typescript" to only show typescript projects etc.

As for the example projects. This is also explained in the text. This work is ongoing. There're another 150 or so projects to be added (just my own). For community submissions there is & will be: http://awesome.thi.ng/ (currently just linking to the submission form)

There're about 140 TS libraries vs. 70-80 Clojure/ClojureScript projects (around only half of which are libraries).

I partially stopped with the Clojure work because of lack of community/support, perf & workflow issues and changing interests (e.g. got back into C/Forth/STM32). Before that, I've tried for 4-5 years to encourage more people adopting CLJ/CLJS and to provide tools for graphics, data viz, digital fabrication etc. to make the language more appealing/useful for these folks. In hindsight it seems I gave up a year too early... Still, I find the TS monorepo workflow much more suitable for myself (and for the project), since large scale refactoring without types often has been a complete nightmare in Clojure (also using Literate Programming/org-mode made it even harder in these case). Plus, trying to write performant cross-environment code (for realtime graphics) in CLJC has been a quite painful/hairy experience. Still, as I said before, I do have very fond memories of the 6-7 years spent with the language & community. It's been partially commercial suicide (at the time), but an huge and important learning experience and I'm happy that (in the end) quite a few people found (and still do find) those tools useful...

Thanks & noted! Btw. the scrolling stops if you hover with your mouse over it/touch the area (similar to IG stories)

Maybe I mentioned Compdes a bit too often... /shrug

From this comment and others it seems maybe not many people are familiar with the meaning of the term: Design through/by computational means, incl. procedural, generative, evolutionary approaches...

Having said this, these libraries are closer to general purpose computing, but there's somewhat of a bias in terms of topics and data structures towards geometry, graphics, data transformations, visualization etc.

That one is interesting indeed. I'm a bit curious about you taking issues with "manifold" and "polyglot" here:

- manifold - something taking many forms - polyglot - https://en.wikipedia.org/wiki/Polyglot_(computing)

I'm pretty sensitive to marketing BS/buzzwords myself, but unlike the usual "blazing fast" and similar hypephrases, the above two words actually are 100% correct use of the terms (IMHO)

See my other reply above re:scope and projects written in: TypeScript, Clojure/script, C, OpenCL, GLSL, VEX, Java, Forth - if this is not polyglot, then what is?

Thanks for the feedback - very much confirms some of my own issues, but it's also clear that I still have to find a better solution to emphasize some key points of differentiation:

1. thi.ng is definitely not a framework - it is a collection of 260 largely independent libraries & projects built around them 2. Because of #1, there cannot be a single "start here". I was hoping that the interactive tag cloud would make this obvious and also fulfil that "start here" role: Users choose a tag/topic of interest and get a list of relevant projects, each with a readme (and often a list of examples)

To give an example of the problem: Say you're interested in building UIs. There're currently ~20 different projects related to that (of which only a few are related to each other, the rest independent), some are DOM based, some use canvas, others are for OpenGL, Java, Clojure, even others are for baremetal ARM devices. Where's the "start here"? An even larger number of packages are dealing with/providing data structures? What funnel should/could these have?

140 of the ~260 projects are part of the thi.ng/umbrella monorepo and written in TypeScript. These are somewhat more cohesive (in terms of style, approach & infrastructure), but still definitely not a framework. Then, there's also the issue that "monorepo" has multiple interpretations too by now:

1. a large (more or less) single-purpose project consisting of multiple packages/sub-projects 2. a google-style monolithic repository providing a common source of truth for thousands of projects (not all related)

thi.ng/umbrella is somewhere between #1 & #2. thi.ng at large is definitely a #2...

I'd really be interested in hearing how others would approach this from an UX POV, since it is seemingly different to the vast majority of open source offerings, especially in that wider field of "creative computing" (which itself IMHO is a too limiting term for thi.ng - there's a much stronger focus on topics outside what's covered by P5, OF, Cinder, OPENRNDR etc.)

The overhead is not fixed and the 3KB are only for the default config and based on the max number of blocks one might have in flight (256 by default).

Hey, author here - this post/thread completely hit my by surprise, so apols for late reply:

1) ta_free() is only O(n) if block compaction is enabled, else it's O(1), i.e. a simple cons of the freed block addr to the free list (https://github.com/thi-ng/tinyalloc/blob/master/tinyalloc.c#...)

2) there's no hardcoded alignment (it's configurable via TA_ALIGN macro) and I'm confused about your other comment about not aligning the right address in general. that's a wrong observation and i think you misunderstood the diagram in the readme.

3) it's clearly stated in the readme that this is largely meant for memory constrained situations (or where not large numbers of blocks, realloc or multithreading is needed/available) and so it's not meant to be a replacement for dlmalloc / jemalloc caliber allocators etc. i needed something small & lightweight and it did it's job very well in several production projects on the ARM STM32 platform (where I have upto around 8MB managed). I also found it very useful for some ongoing JS/WASM interop projects (i.e. there's JS version here: https://github.com/thi-ng/umbrella/blob/master/packages/mall...)

Re: "This incident happened -before- the EU upload filter law had passed"

AFAIK this actually is only a directive and not a law just yet. As a directive it will be down to the individual governments to decide how it will be implemented. The final vote will be in Jan 2019.

Thanks & I wasn't (aware of it). hdom doesn't use `.innerHTML` anywhere, though. So I'd dare to say less dangerous... though not saying it's out of danger!

That's the thing, though, I deeply beg to differ on that and I really think your view and statement that using HTML syntax is so much better is just very subjective. Both of our projects create and manipulate the DOM. Which syntax to use for that purpose is IMHO irrelevant as long as it produces correct results. To me HTML syntax is nothing more than a necessary evil (Btw. I've worked w/ HTML since '95), and something I'm more than glad to have almost eradicated from my professional life, nor is it something I want to still actively embrace. Judging by the popularity of XML I'm not alone... thousands of Clojure/ClojureScript users using hiccup syntax on a daily basis also do not want to go back to literal HTML after using hiccup for more than a day.

Isn't also a large appeal of working with components to compose UIs in a more abstracted manner, with different semantics? The hiccup format doesn't use anything alien to web developers and is (objectively!) less noisy in terms of punctuation to express the same concepts. And array manipulation in JS is (again objectively!) easier than manipulating the same kind of data in some <template> DOM. Hdom's syntax is arguably also less tainted by HTML, and that makes sense and was desired, precisely because it is NOT only aimed at the browser DOM, which is just one target (the default). Since the syntax is just `[tag, attribs, ...body]` it's sufficiently general to work equally well for many other use cases not aimed a browser DOM, e.g.

- Server-side rendering

- Static site generation

- WebGL UIs, shader definitions, entire scenes

- Tagged data interchange format between different apps (on top of JSON)

- 3D printing (use as interim format before generating final G-code)

- ...

Lastly, from your new examples given, in my mind, it seems your project is simply aimed at not just somewhat different use cases (albeit there are of course large overlaps), but also a somewhat different audience. Note, I'm not saying that hdom is worse or better than lit-html, it's simply based on a (quite) different philosophy. So please don't compare apples with pears!

Thanks for the clarifications & apologies if I misunderstood some parts earlier. Will definitely check out your project more closely...

From a quick glance at the docs, though it seems to me there're a lot of other differences in approach (apart from the syntactic differences), especially WRT state. I will have to study these further before being able to comment properly...

Just one more note about XML vs. JS syntax to describe elements. As I said earlier, am sure there's ton of people who prefer the familiar way, but objectively, do you really find hdom's approach less readable? Honest question!

    // lit-html
    list = html`<ul>${items.map((i) => html`<li>${i}</li>`)}</ul>`

    // hdom
    list = ["ul", items.map((i) => ["li", i])]

very well said indeed! +1

@danpeddle already pointed out the important part, but just as an addendum...

It all depends what one wants to do with a browser, doesn't it? For some of my projects the browser is merely a sandbox for delivering design tools and I really don't care about the HTML aspects of it at all.

For other projects, I only care about HTML generation and use hdom's sister library to generate static HTML from the same components:

https://github.com/thi-ng/umbrella/tree/master/packages/hicc...

If a user has JS disabled in the browser, fine. If not, then the browser app can hydrate the static HTML and add interactive features and cause cancer :)

The commit table has a 100ms throttle on key press, but I think might have a bug, need to inquire more... :)

There's also a stress test here which updates several hundred nodes each frame:

https://github.com/thi-ng/umbrella/tree/master/packages/hdom...

E.g. each cell shown requires 3 DOM updates per frame, so in the 256 cells config it updates 768 DOM nodes. On my MBP2016 this config runs at ~35 fps, 192 cells (576 real DOM updates) at 59-60fps

Oh hello & wow... now if only I knew who you are... :)

Those tweets really weren't meant to discourage people from using CLJ(S) at all!! I was merely trying to explain why, personally, I think TS is better suited for my own use cases (and those of my job)... I'm not building "standard" websites and for the tools I'm dealing with, CPU performance is more important than for most other web apps. I sometimes just felt constrained by some of the features & indirections people usually come to Clojure/Script for in the first place. For example, when generating or processing large amounts of geometry I really don't want or even need immutable data structures by default and so I wanted to have the freedom of being able to break out from this more easily. In some cases I too wanted to have more of a 1:1 correspondence between the code I write and what it ends up as in JS, something the combo of CLJS + GCC made hard(er). ES6 syntax offers many niceties (e.g. array and object destructuring, iterators, async fns) and without those I'd probably be still using CLJS more.

I don't want to sound snarky (and please don't see it as such), but did you read the readme? I'm not familiar with Mercury, but looking at the code examples, some obvious differences are:

- hdom does NOT care about state, where it comes from or how you manage it

- hdom uses vanilla arrays(*) instead of `h()` function wrappers, which not just create more legible (IMHO) style, but also open components up for more options in terms of construction/composition and also transformation.

I think that last aspect is seldom talked about in all those discussions and comparisons w/ React & co. Entire 3rd party frameworks are invented & maintained just to provide augmentation, configuration & injection features for React style components, issues which can be much easier solved if your components are in a less abstract & more native data format already. ES6 provides a ton of nice features to construct and transform arrays without any additional support structures. hdom also supports & fully embraces ES6 iterators and the more modern ways of transforming data they support.

There's a blog post about this forthcoming, so apols for not going into more detail here now...