I miss the days when doing stuff like this felt like a fun puzzle to solve with existing tools rather than a frustrating exercise in resolving dependency graphs.
I think the key thing is that nothing about Decker or Lil was specifically designed or tweaked for this use case; Everything I needed to build the hershey module and make it reasonably efficient was already at my fingertips. I considered bundling up some of the patterns I describe in this article as a library, but I think it's much better to view them as transparent idioms to adapt to wherever they're needed, letting the abstraction live in your head instead of the source file.
As I wrote about two years ago in "The Benefits of Conforming", Lil's approach to handling mismatched dimensions for conforming arose from a need to plug the semantic gap left by K and Q, since Lil doesn't believe in runtime errors. While evaluating my options I made a series of pleasant idiomatic discoveries that ended up also being useful for "hershey". There is perhaps an argument that if I'd "preferred" the length of the right argument instead of the left some expressions would require fewer parentheses, but I suspect it's a wash either way.
The design of heading/mag/unit were influenced by my work with oK and iKe, particularly my annoyance at the clunkiness of writing things like {(cos x;sin x)}' or wrangling with atan2[;]. The Lil primitives help expressions "flow" together nicely, with few intermediate variables and minimal nesting. I think I spent more time agonizing over reasonably intuitive names for them than I did puzzling over semantics. I'm quite pleased with these primitives as some of Lil's hidden pearls, and I hope I can inspire other arraylangs to incorporate something similar.
I miss the days when doing stuff like this felt like a fun puzzle to solve with existing tools rather than a frustrating exercise in resolving dependency graphs.
would love to read also more on what other approaches you considered or played with before settling on the current api/algebra (which is really nice!)
maybe the point, stroke, path tower, enlist and scaling felt kinda self-evident from the beginning?
e.g. postscript has a more imperative (but also very interesting forth-y) approach
ty for the writeup, the wiggly effect is great
I think the key thing is that nothing about Decker or Lil was specifically designed or tweaked for this use case; Everything I needed to build the hershey module and make it reasonably efficient was already at my fingertips. I considered bundling up some of the patterns I describe in this article as a library, but I think it's much better to view them as transparent idioms to adapt to wherever they're needed, letting the abstraction live in your head instead of the source file.
As I wrote about two years ago in "The Benefits of Conforming", Lil's approach to handling mismatched dimensions for conforming arose from a need to plug the semantic gap left by K and Q, since Lil doesn't believe in runtime errors. While evaluating my options I made a series of pleasant idiomatic discoveries that ended up also being useful for "hershey". There is perhaps an argument that if I'd "preferred" the length of the right argument instead of the left some expressions would require fewer parentheses, but I suspect it's a wash either way.
The design of heading/mag/unit were influenced by my work with oK and iKe, particularly my annoyance at the clunkiness of writing things like {(cos x;sin x)}' or wrangling with atan2[;]. The Lil primitives help expressions "flow" together nicely, with few intermediate variables and minimal nesting. I think I spent more time agonizing over reasonably intuitive names for them than I did puzzling over semantics. I'm quite pleased with these primitives as some of Lil's hidden pearls, and I hope I can inspire other arraylangs to incorporate something similar.
ty! very interesting
There are tensorial ways to deform texts, it would be huge if you made an article on that
Looks like CSS.