[jblow]

> An API that can be accessed from heterogeneous languages will involve IPC.

No. If your language cannot call into a dynamic library using a well-defined C ABI for your platform, then it is already failing to speak a standard protocol. Building all kinds of crazy, complicated, slow infrastructure in order to get it to successfully speak some other protocol, is a symptom of modern-day clueless programming.

> Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily)

Yes, this is of course a good idea. Why one presumes this requires a separate running process, I have no idea.

[anp]

> No. If your language cannot call into a dynamic library using a well-defined C ABI for your platform, then it is already failing to speak a standard protocol.

This also involves a marshalling cost at the ABI boundary, which may be lower overhead than parsing JSON, but is significantly more brittle. And it's less ergonomic for many plugin/editor authors. And it can't be spec'd with a schema that isn't just "read the headers."

[jackmott]

>This also involves a marshalling cost at the ABI boundary

Only for some languages, and that cost should be far far less than running a separate process, shipping json over pipes, and parsing the json

> And it's less ergonomic for many plugin/editor authors

I think that many modern programmers find this more ergonomic than a C ABI is part of what he is complaining about. Let's get comfortable with what is good, rather than make what we are comfortable with?

[dikaiosune]

Agreed, that pipes+json is much higher overhead, just noting that this proposed approach still isn't free.

> Let's get comfortable with what is good, rather than make what we are comfortable with?

I agree in the abstract! I just emphatically disagree with characterizing a C ABI as "what is good."

[jblow]

I don't understand what you are saying here.

Why is it "significantly more brittle"? It is a well-specified interface. It is less brittle than talking over a socket because the kinds of points of failure involved with sockets don't exist in this case.

> And it can't be spec'd with a schema that isn't just "read the headers."

What does that even mean? It's a protocol just like any protocol, except you get the added benefit that for many languages it can be typechecked. Why are you claiming it can't be specified or that someone has to "read the headers"? What headers?

[dikaiosune]

From your endorsement of "using the compiler's symbol tables" (paraphrasing) I took you to mean that you're proposing binding directly to GCC (or another tool) as a library, relying on it's internal data structures as this C API. Based on this comment, it sounds like you're now suggesting that this API should still be standardized and require translating from the compiler's internals into some standardized AST/symbol format anyways. I still think the latter is bonkers for several reasons (SIGABRT being one), but it's significantly less bonkers than what I had thought you were proposing initially.

[teacup50]

> I still think the latter is bonkers for several reasons (SIGABRT being one)...

The fact that we're typing this, and it works -- without the entire world falling apart because of crashes in complex library code -- demonstrates why this is not remotely bonkers.

[wtetzner]

Not only that, but it means if the library crashes, your editor process dies. That hardly seems better than sending some text over a socket. At least if the external process crashes, your editor can just restart it.

[jblow]

Several people have said this. Look ... a "crash" in a modern operating system is a recoverable exception.

[wtetzner]

How do you recover from segfault? How do you know what data might be corrupted?