> Why not just show functions that are easy to use and harder to use, and let callers decide what works best for them.
Won't you be stuck exposing those APIs for the lifetime of the product or risk breaking backwards compatibility?
What if you could make the code significantly faster by changing the parameters you pass in to an internal function? What if you discover a bug that you can only change by changing a method's signature? What if you just want to refactor? Doesn't exposing your internals prevent you from doing these things?
Won't you be stuck exposing those APIs for the lifetime of the product or risk breaking backwards compatibility?
A real revelation for me over the last year of using nodejs more and more, is that every component can use its own dependencies, at exactly the versions it requires. So, when you add to an API, bump minor. When you take away, bump major. Either way, you can bump patch for bug fixes, on any major-minor combo, whenever you want. So "stuck" isn't really possible any more.
You run the risk of it, sure. However, early mover advantage is quite large in all things. Including finding the right abstractions. To paraphrase a witty quote, how do you know the correct abstractions to make? By making the wrong ones.
Won't you be stuck exposing those APIs for the lifetime of the product or risk breaking backwards compatibility?
What if you could make the code significantly faster by changing the parameters you pass in to an internal function? What if you discover a bug that you can only change by changing a method's signature? What if you just want to refactor? Doesn't exposing your internals prevent you from doing these things?
(Note, haven't read the article yet).