Lynn RootDec 11, 2024
hey new friends, help a girl out - what would y'all want to see in a part 2 of the "Design of Everyday APIs" talk? anything more to dig in on, or missed topics, or inspired ideas? https://www.roguelynn.com/talks/everyday-apis/
The Design of Everyday APIs

What makes a good API for a library? Or more importantly, what makes it bad? Implementing an API is an art. It’s the connection between the user and the library itself. How can we optimize that connection to make the experience more pleasing? What makes a user reach for one library over another? What goes into an ergonomic API? This talk will first discuss what makes an API good: documentation, simplicity, consistency, completeness, and flexibility.

roguelynn
Show threadGlyph
@roguelynn evolution through time. when something changes, how will I know? How long can I expect things _not_ to change? What's the idiom for naming to account for change? e.g.:
- does every API eventually grow six new parameters and an "_Ex" prefix?
- Is there a new module? Do the new modules provide façades over all the old ones, or is the API eventually expected to span 'xyz.v1' to 'xyz.v6'?
- Does every class and method start with a '1' on the end so that '2' isn't inconsistent?
Dec 12, 2024 at 6:54amWeb
Show threadLynn RootDec 12, 2024
@glyph uff, good idea but dang, what kind of APIs are you using 😳
Show threadGlyphDec 12, 2024
@roguelynn "ones that have been around for more than 10 years" :)
Show threadGlyphDec 12, 2024
@roguelynn this is also something to think about as part of the evolution conversation. For some kinds of libraries — those implementing a proven mathematical abstraction for example — you can put effort into choosing good names and be pretty confident that by the time someone needs new abstractions they will need a whole new library. For others, like if you are abstracting over a highly volatile lower level like web browsers or GPUs, plan to be wrong and wrong often
Show threadChris is.Dec 13, 2024
@glyph @roguelynn Expanding on that... what are the options for change when you *can't* change the formally specified things? How do you design for flexibility when your customers demand rigidity?