Algorithms should be free from rich types

[H. S. Teoh]

On Thu, Jun 29, 2023 at 05:54:28PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, June 29, 2023 8:44:05 AM MDT Atila Neves via Digitalmars-d wrote:
[...]
> > I have lost count of how many times my life has been made
> > difficult by the lack of `private`.
> >
> > I have also lost count of how many times my life has been made
> > easier by the fact that I ruthlessly declare everything `private`
> > unless it has good reason not to be.
> >
> > Ease of refactoring = good, ergo `private` = good and should be
> > the default.
> 
> Yeah. As with many things, I think that it primarily comes down to
> good API design (which can be hard).
[...]

True.  It comes down to good API design. Which, as you say, is very
hard, probably harder than most people realize.  It's easy to slap an ad
hoc API onto your library functions, but over time it will prove
inadequate for user needs and they will feel frustrated over why certain
things are locked behind private.

IME, it takes several iterations of actually using a particular API
before it becomes clear where the friction points are and what are
possible alternative designs that may work better for user code. (And
also, which parts of the API are perhaps needlessly complex and could
probably be simplified.) The problem is that if you have actual users
during this period of time, they will start writing code that depends on
the current API, which obligates you to support an inferior API even
after a better design emerges.


> Similarly, if you actually plan your API around generic types, then
> it's much easier for folks to make it work with their own types, but
> it's not always obvious when you should be doing that vs designing an
> API around more specific types
[...]

Yeah, there's definitely a danger of premature generalization. Before
you have experience designing a certain library, it's hard to predict
what's worth generalizing and what isn't.  But it's hard to gain
experience without people actually using your library, which then binds
you to the non-optimal initial API.  So it's a catch-22.

API design is hard.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??