The idea is pretty much a sketch-n-sketch approach to footprint editing. https://ravichugh.github.io/sketch-n-sketch/index.html

Choosing Racket for this application was a no brainer as it demands data-code intermingling with an s-expression based format and redefining the language to suite the application. Racket also has excellent GUI library that allowed me to get a graphics pane and a text-editor GUI up very quickly.

The APIs that Racket libraries provide seem a bit like quantity over quality to me. I dread having to sift though the docs for the functions I actually need. On the one hand every function is thoroughly documented on the other the descriptions are often seeped in the jargon surrounding the language.

For instance, this may be a stupid beginner mistake, but I couldn't work out how to make `send` and `apply` work together. Coming from Haskell I assumed there would be straight forward way to compose these things. Instead I had to resort to use the `send/apply` function and there seem to be a lot of these special purpose functions all over the place that are trying to anticipate your usage rather than providing composable primitives.

1 - Library discovery is hard, as kabash said, it really feels like a quantity over quality situation.

2 - Most of the documentation seems to be either targeted to very beginners, or are reference materials. I would love a series of tutorial sitting between the "racket guide" and the "racket reference" doc. Something that explains 'why' to use some of the language constructs as opposed to simply saying how to use them.

3 - Typed racket and the contract system are simply amazing : I think they should get much more screen time than what there are getting now.

4 - The web stack could use some improvements

Every time I do, I come away wishing I could use it to replace R or Python for data science tasks such as data munging or statistics. I've even had a pipe dream for a while to create cross-compatible R implementation in Racket--"arket."