gui

help you find all of the functions that operate on a `dict` type if you don't want to rely on conventions where you just seek out a dict.rkt file. For what it's worth, coming from lots of Java experience, as a Racket novice, I poked around the Racket internals and added Candlesticks to its `plot` library [0] and removed a call to a deprecated gdk function that was causing overhead when drawing text [1]. It never felt like an insurmountable task just because methods aren't defined within types. By finding problems with Lisp, you are finding problems with s-expressions, which, to me, are so plainly superior to XML and JSON for defining data that I wish more languages would at least consider adopting them for data definitions. [0] https://github.com/racket/plot/commit/7f38feaf6e28a1decec93d... [1] https://github.com/racket/gui/pull/95

Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning. I, as a Racket novice, have been able to add candlesticks [1] to the plot library without learning much about it. I have also debugged DrRacket (an IDE) to uncover that Racket GUI operations performed significantly worse if non-integer scaling was used [2]. At no point when I was going through Racket internal code did I ever feel it was write-only. In fact, it was quite convenient to modify Racket internal source code, rebuild, and test changes in a way that would be much more difficult in Java or C++. > You certainly can not do that, but if you choose to not do that, why pick Lisp? Built in rationals. The ergonomics of defining [XML / JSON / etc] data as S-expressions and doing things like pattern matching on that data. Great, coherent integration between GUIs, plots, statistics functions, and all the other bits of Racket's batteries inclusions. You still have access to all the other great features that other languages have borrowed from Lisp like REPL development, package managers (edit: maybe package managers were not a Lisp invention), good IDE tools, etc. It is nice to learn the meta-syntax of parentheses once and know that the code will always look like that. No need to consider if some feature is implemented as a syntactically different new keyword, annotation, function call, or whatever. It'll always be a (feature). > something you have to conciously work for with Lisp. Plenty of languages have style guides, linters, static analysis tools, etc. to make sure the code conforms to certain restrictions. Lisp feels no different in this regard. [1] https://docs.racket-lang.org/plot/renderer2d.html#%28def._%2... [2] https://github.com/racket/gui/commit/20e589c091998b0121505e2...