| > Every API is itself a "little language" I came to this conclusion early in my career. It went something like this: A - "To do this, just create this object, fill in these properties, and call these methods." B - "Okay, I did that, but it crashed." A - "Yeah, it's because you set the properties in the wrong order. This property relies on this other property under the hood. Set them in this order." B - "Still crashes." A - "Yeah, you called the methods in the wrong order. This method relies on that method. Call them in this order and it works." My conclusion was that the lisp philosophy of building a lot of little sub language was equivalent to what people were doing with OO in C#/Java. Either way you have to learn the "right" way to put things together which is dictated by unseen forces behind the scene. Of course, I also concluded that most people work differently than I do. For most people, if the code "looks right" (ie recognizable syntax) then they're able to tell themselves a story that it's familiar and their intuition is able to pick up the slack for finding the right enough way to use most arbitrary APIs (just as long as they don't exceed some level of incomprehensibility). On the other hand, I have to understand the underlying logic or I use the API the wrong way pretty much every time. So for most people lots of APIs is actually a much better cognitive way for them to work whereas for me API soup and lisp macros are the same conundrum. |
IMO we need a language (or library?) that forces builders of an API to make incorrect behavior hard or impossible. Here's some scribbled out ideas: https://packetlost.dev/blog/lang-scribbles/