3 ms·
This seems a long-standing problem. Even with very early Python, it was possible to have objects providing an API of C pointers, to be dynamically combined wit
by mncharity 8y ago
This seems a long-standing problem.
Even with very early Python, it was possible to have objects providing an API of C pointers, to be dynamically combined with other such objects, to create runtime assemblages of C code, with only C's dynamically-linked function call overhead between the parts. And with cached runtime invocation of gcc and dynamic loading, it was possible for objects to provide C macro apis, and combine them into runtime-specialized fully-optimized code.
But the approach didn't catch on. The community built C monoliths. Often multiple semi-abandoned monoliths with heavy feature overlap, but never code sharing. And then Windows slowly became important, with its lack of compiler access.
So the problem seemed a social one, rather than technical. Far fewer people using python, and not enough of them cared about such things to achieve critical mass. And so the approach never matured or gained momentum. Was never embraced as "pythonic". In an alternate timeline, we did such very neat stuff with it. :/
- mncharity 8y agoERRATA: The assemblages created from objects carrying C pointers had only C function pointer call overhead (of course). It was different scheme, playing linker games, that had GOT overhead. And "multiple semi-abandoned monoliths with heavy feature overlap, but never code sharing" missed a key characteristic - the monoliths were all very partial solutions. So a common dynamic was "I need feature X, as in monolith A, and feature Y, as in monolith B, so... I'll create a new monolithic library C, with those features, but missing others from A and B that I don't care about". Leaving the next person in the same unhappy place, and scattering the little effort available into even smaller communities.