Algorithms should be free from rich types

[Atila Neves]

On Friday, 30 June 2023 at 02:21:42 UTC, H. S. Teoh wrote:
> On Thu, Jun 29, 2023 at 05:54:28PM -0600, Jonathan M Davis via 
> Digitalmars-d wrote:
>> [...]
> [...]
>> [...]
> [...]
>
> 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.
>
>
>> [...]
> [...]
>
> 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

API design is indeed hard. Which makes it all the more imperative 
to not accidentally design one with implementation details that 
users downstream start depending on. That is: API design needs to 
be a conscious opt-in decision and not "I guess I didn't think 
about the consequences of leaving the door to my flat open all 
the time and now there are people camping in my living room".