[jimbob45]

As far as I know, Racket docs are entirely human-generated. The functions aren’t tied concretely together to types by anything. In C#, types and their member functions are automatically tied and inspectable in code. That’s what I feel is missing. Also, I don’t want to take away from the phenomenal Racket docs. They’re a real treat to work with.

[evdubs]

If you're referring to C# (and Java) being the Kingdom of Nouns where a type like ArrayList is defined and contains its methods, sure, Lisp is not exactly like that, but I feel like conventions give you a similar experience. For example, functions related to hash tables all have `hash` in their name and are either constructors or they take a `hash` argument. They are contained in their own file (hash.rkt).

Also, doesn't inheritance interfere a bit with your "functions aren't tied concretely together to types" observation? You can examine a source file for ArrayList, but if it extends List, you may not see everything you expect to see, and would just defer to the docs to help you out (or click through more source files).

I assume Racket contracts can handle your concern about relating functions and types. An IDE or static analysis tool can 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

[tancop]

> I assume Racket contracts can handle your concern about relating functions and types

contracts are not real types enforced by the compiler/runtime. that means you need to keep them in sync manually and you dont get performance benefits from typed vm instructions. you also lose a big safety net that makes sure you always call a function that can handle the values you pass in. the whole industry has been moving towards ml style strong types for the last 10 years and its for a good reason