|
scheme is great, but the dx of some implementations is not. i’m on guile scheme due to guix, and frankly, i’m hating it a quite bit. stack traces are esoteric and error messages entirely unhelpful, documentation masquerades as deep but is indeed inconsistent and prosaic, mixing styles of reference, explanation, and how-to willy-nilly, (compare with Dybvig’s The Scheme Programming Language, which is focused and consistent, and it takes no time to get your answers; there’s just no method to guile and guix manuals), i hate it big time, there’s big gaps in documentation (especially with Guix – there’s literally zero information about `define-record-type*` which is used everywhere in its codebase; admittedly, not scheme related, but still), the cli requires too much memorization, most modules are not named, but numbered, ie, instead of something like `(base list)`, you get `(srfi srfi-1)`, so you need to either memorize, or go through the info pages for each procedure you need to import, which means you also need to know the exact names for the procedures you need beforehand, there’s like 4 ways to define a record, each with a different feature set and incompatibilities, etc. these are the reasons i find it hard to use. to respond to the content of the article, the different neurotype idea is off, because scheme allows you very well to express sequences of operations; the ecosystem of APIs may not cater to this tho. although if it was rephrased into “scheme emphasizes symbolic manipulations, as opposed to operating a machine”, i would agree |
Probably the one bit that isn't strictly fracturing's fault is stacktraces -- scheme has TCO, which is nice for alot of things but it absolutely destroys dx as it relates to stacktraces. Other languages with TCO are similarly awful in that regard, including haskell (ghc has `HasCallStack` to try help it, but it's still awful to use).
[1] https://get.scheme.org/