On Fri, Jul 17, 2020 at 01:27:11PM +0300, Dmitry Gutov wrote:
> On 13.07.2020 10:58, tomas@tuxteam.de wrote:
> >Even the term "API", "application programming interface" conveys
> >the culture on the one side: here be the system programmers (better
> >paid, presumably), there be the application programmers. If one of
> >the latter*dares*  to touch system things, (s)he's fired [1].
> 
> This is is pretty dated view: the "system things" are rarely in the
> picture. But they are as fine to touch as any, as long as that fits
> the abstraction you are defining.

I was rather trying to highlight the contrast between (a) the library
designer(s) set the interface design and (b) the interface evolves
as a collective effort of designers and users. Reality will be a mix
of both, of course. The term API conveys a hierarchy -- clearly in
camp (a).

The "system programmer" thing comes from former times, yes.

> The difference between system programmers and application
> programmers, I think, is the latter have found that abstractions are
> a good thing for a lot of domains, and have come up with certain
> rules for using them.
> 
> I can certainly understand how a system programmer might dislike
> having to deal with extra abstractions, but, again, certain jobs
> simply call for using them.

I think we misunderstood each other. Abstractions are our daily
bread, of course. But the process of choosing which abstractions
are relevant and whether and where to punch holes in them is
open to debate.

Here we seem to have a conflict between your and Eli's views. I
sincerely hope you both don't take that to the personal level
and try to work out that conflict.

Cheers
-- tomás