5 ms·

I feel that the C ABI is local maximum, with a massive associated opportunity cost. Imagine if all the operators that have been written, "bottom up", in one lan

I feel that the C ABI is local maximum, with a massive associated opportunity cost. Imagine if all the operators that have been written, "bottom up", in one language could be easily accessible from others. And the only way to leverage that today is to go through the crusty, unsafe API that no-one really wants to export to unless it's required in the spec of a project. Swift soon being able to call python is a massive step forward, but a lower level API that wouldn't require a runtime yet still was superior to C's feels like a massive win for the industry that's just waiting to happen.

goatlover 8y ago
You mean if Swift could call Rust instead?
marcosdumay 8y ago
Nothing stops a language runtime from creating a new ABI, and using it within the runtime.If it is much better than C and stable enough, people will adopt it. Compiler developers do not run away from that kind of project. I'd say the problem is that nobody created anything that is much better and stable enough. That second one is a large problem on non-C languages.
bandrami 8y ago
I think PG's ultimate point was about metaprogramming, which kind of turns your request on its head. Don't bother writing python bindings to the operators you wrote bottom up in lisp or forth: metaprogram in lisp or forth to give yourself the parts of python you find useful for the project.
jasode 8y ago
>, but a lower level API that wouldn't require a runtime yet still was superior to C's feels like a massive win for the industry that's just waiting to happen. A lower-level binary API was tried before in the 1990s by various players. Microsoft's effort was COM/COM+ to unify programming languages across binary boundaries.[1] Another initiative was CORBA.[2] Those technologies are still alive in various legacy forms but they haven't taken over the landscape like the proponents thought they would. (Although the whole MS .NET ecosystem introduced in 2002 is arguably a continuation of COM+ by a different name.) [1] https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model [2] https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
- adrianratnapala 8y ago
  I see what you mean that COM and Corba tried to unify programming across language boundaries. But they were not a low-level ABI type thing. They explicitly pushed a particular idea of what objects are and what they are for. In any case, judged by the standard of becoming a universal ABI, they were also designed to "fail" in the sense that MS wasn't going too sit around and standardise it across operating systems, while the CORBA was a (feeble) response from the Unix world that no one expected would take off on Windows.
nickpsecurity 8y ago
Ive been recommending that, too. The better languages should use C's datatypes, calling conventions, have a seemless FFI, and generate C (at least optionally). This way, they can build on C's ecosystem instead of getting trampled by it. The C code can also be gradually rewritten. On the LISP side, one might start with a combo of PreScheme with C compatibility, Rust-style memory management, and Racket-like DSL support. Maybe even embed it in DrRacket for tooling. Then, one can build up other Scheme-like features on top of it with an interpreted version. So, that's an example of how to get the benefits of both.

goatlover 8y ago

You mean if Swift could call Rust instead?

marcosdumay 8y ago

Nothing stops a language runtime from creating a new ABI, and using it within the runtime.If it is much better than C and stable enough, people will adopt it. Compiler developers do not run away from that kind of project. I'd say the problem is that nobody created anything that is much better and stable enough. That second one is a large problem on non-C languages.

bandrami 8y ago

I think PG's ultimate point was about metaprogramming, which kind of turns your request on its head. Don't bother writing python bindings to the operators you wrote bottom up in lisp or forth: metaprogram in lisp or forth to give yourself the parts of python you find useful for the project.

jasode 8y ago

>, but a lower level API that wouldn't require a runtime yet still was superior to C's feels like a massive win for the industry that's just waiting to happen. A lower-level binary API was tried before in the 1990s by various players. Microsoft's effort was COM/COM+ to unify programming languages across binary boundaries.[1] Another initiative was CORBA.[2] Those technologies are still alive in various legacy forms but they haven't taken over the landscape like the proponents thought they would. (Although the whole MS .NET ecosystem introduced in 2002 is arguably a continuation of COM+ by a different name.) [1] https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model [2] https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

adrianratnapala 8y ago
I see what you mean that COM and Corba tried to unify programming across language boundaries. But they were not a low-level ABI type thing. They explicitly pushed a particular idea of what objects are and what they are for. In any case, judged by the standard of becoming a universal ABI, they were also designed to "fail" in the sense that MS wasn't going too sit around and standardise it across operating systems, while the CORBA was a (feeble) response from the Unix world that no one expected would take off on Windows.

nickpsecurity 8y ago

Ive been recommending that, too. The better languages should use C's datatypes, calling conventions, have a seemless FFI, and generate C (at least optionally). This way, they can build on C's ecosystem instead of getting trampled by it. The C code can also be gradually rewritten. On the LISP side, one might start with a combo of PreScheme with C compatibility, Rust-style memory management, and Racket-like DSL support. Maybe even embed it in DrRacket for tooling. Then, one can build up other Scheme-like features on top of it with an interpreted version. So, that's an example of how to get the benefits of both.