Hi all,
Interfaces (API) are often poor, varied and insufficiently usable.
They're not iterated enough on. Maybe even simply, most programmers don't really want to be designing and documenting interfaces.
Nevertheless large components with stable interface have also proven to be a key to extract hardware performance and deliver it to general purpose applications. (See Butler Lampson's Software Components, Only The Giants Survive) Not having stable APIs for all kinds of services like font-rendering, I/O etc.. instead of per-vendor or per-library APIs also leads to a lot of software rot or unnecessary maintenance.
What if instead of opensourcing implementations, we had focused instead on opensourcing APIs. On documenting, criticizing, and iterating on them, with the expectation that multiple implementations (opensource or not) would arise?
These would naturally be distributed under lenient licenses. Copyleft and proprietary implementations could co-exist, naturally.
Differentiating on implementation while keeping API stables would allow quality improvements to arise on the implementation side while minimizing the amount of software churn for users of such implementations.
Additionally, we would benefit from libraries competing on the quality (or platform support) of their implementation, w/o creating unnecessary lock-in.
Successful examples: (successful as in widely adopted reusable interfaces, I'm not vouching for their quality)
- SQL
- x86 ISA
- POSIX
- OpenGL
Often, committees have been used to create standards out of existing designs. If we had a better collaboration process for working together on APIs, we could probably surpass that work. And committees are anyway not fit for designing.
A sketch for a solution could be a website w/ a repository of APIs (git), a bit like the repositories used to vote for language changes on rust/swift. The website could provide guidelines for both designing and reviewing APIs. For instance, usage code is absolutely essential to design a good API.
Some unanswered questions and doubts:
- How to avoid this being another boost or posix or whatever?
- How to gain traction and be able to write/criticize the usage code w/o at least a toy implementation?
Precedents
- djb did something similar in the past, see the entries marked "C interface" at url=http://cr.yp.to/software.html
I've for instance used his array interface in my own code.
- McIlroy made a similar proposal in 1968 during the NATO software engineering conference. Mass Produced Software Components
- Stepanov reiterated it in Industrializing Software Development
Both rely on top-down approaches. I would propose to find a bottom-up approach instead.
(original post on github)
Interfaces (API) are often poor, varied and insufficiently usable.
They're not iterated enough on. Maybe even simply, most programmers don't really want to be designing and documenting interfaces.
Nevertheless large components with stable interface have also proven to be a key to extract hardware performance and deliver it to general purpose applications. (See Butler Lampson's Software Components, Only The Giants Survive) Not having stable APIs for all kinds of services like font-rendering, I/O etc.. instead of per-vendor or per-library APIs also leads to a lot of software rot or unnecessary maintenance.
What if instead of opensourcing implementations, we had focused instead on opensourcing APIs. On documenting, criticizing, and iterating on them, with the expectation that multiple implementations (opensource or not) would arise?
These would naturally be distributed under lenient licenses. Copyleft and proprietary implementations could co-exist, naturally.
Differentiating on implementation while keeping API stables would allow quality improvements to arise on the implementation side while minimizing the amount of software churn for users of such implementations.
Additionally, we would benefit from libraries competing on the quality (or platform support) of their implementation, w/o creating unnecessary lock-in.
Successful examples: (successful as in widely adopted reusable interfaces, I'm not vouching for their quality)
- SQL
- x86 ISA
- POSIX
- OpenGL
Often, committees have been used to create standards out of existing designs. If we had a better collaboration process for working together on APIs, we could probably surpass that work. And committees are anyway not fit for designing.
A sketch for a solution could be a website w/ a repository of APIs (git), a bit like the repositories used to vote for language changes on rust/swift. The website could provide guidelines for both designing and reviewing APIs. For instance, usage code is absolutely essential to design a good API.
Some unanswered questions and doubts:
- How to avoid this being another boost or posix or whatever?
- How to gain traction and be able to write/criticize the usage code w/o at least a toy implementation?
Precedents
- djb did something similar in the past, see the entries marked "C interface" at url=http://cr.yp.to/software.html
I've for instance used his array interface in my own code.
- McIlroy made a similar proposal in 1968 during the NATO software engineering conference. Mass Produced Software Components
- Stepanov reiterated it in Industrializing Software Development
Both rely on top-down approaches. I would propose to find a bottom-up approach instead.
(original post on github)
Edited by Nicolas Léveillé
on