Algorithms should be free from rich types

[Ali Çehreli]

My mind is not fully clear on this topic yet but some related things 
have been brewing in me for years.

First, an aside: You may remember my minor complaint about 'private' 
during a DConf presentation years ago. Today, I feel even stronger that 
disallowing access to parts of software "just because" of good design is 
a mistake. I've seen multiple examples of this in professional life 
where a developer uses 'private' only because it is "of course" better 
to do so. (The Turkish word "işgüzar" and the German word 
"verschlimmbessern" describe the situation pretty well for me but the 
English language lacks such a word.)

To give an example from D's ecosystem, the D runtime's garbage collector 
statistics object used to be 'private'. (I think there is an interface 
for it now.) What an inconvenience it was to copy/paste that type's 
definition from the runtime to user code, get the compiled symbol of the 
object from the library, and pointer cast it to be able to access the 
members! A 'static assert' attempts to protect the project from changes 
to that type...

The idea of 'private' should be to just give the developer freedom to 
change the implementation in the future. It should not impede use cases 
that people come up with. That can be achieved practically with an 
underscore: Make everything 'public' and name your implementation 
details with an underscore. People who need them will surely know they 
are implementation details that can change in the future but they will 
be happy: They will get things done.

Ok, that rant is over.

The main topic here is about the harm caused by rich types surrounding 
algorithms. Let's say I am interested in using an open source algorithm 
that works with a memory area. (Not related to D.) We all know that a 
memory area can be described by a fat pointer like D's slices. So, that 
is what the algorithm should take.

Unfortunately, the poor little algorithm is not free to be used: It is 
written to work with a custom type of that library; let's call it 
MySlice, which is produced by MyMemoryMappedFile, which is produced by 
MyFile, which is initialized only by types like MyFilePath. (I may have 
gotten the relationships wrong there.)

But my data is already in a memory area that I own! How can I call that 
algorithm? Should I write it to a file first and then use those rich 
types to access the algorithm? That should not be necessary...

Of course I understand the benefits of all those types but the core 
algorithm should be as free as possible. So, this is simply wrong. I 
think us, software developers, have been on the wrong path. Our task 
should primarily be about getting things done first.

I could work with those types if they had virtual interfaces. But no. 
They are un-subtypable C++ 'class'es.

I think it could also work if the algorithm was templatized; but again, 
no...

Hey! Thank you! I feel better already. :)

Ali