4 ms·

I'm not sure I understand. Are you saying that compilers/analyzers should be written in the same language in which the IDE is written? If not, then how are you

by adwn 5y ago

I'm not sure I understand. Are you saying that compilers/analyzers should be written in the same language in which the IDE is written? If not, then how are you going to benefit from an "in-process type safe API" and those shared data structures you mentioned? This would mean that you'd have to write a compiler not just for each host language/source language combination, but for every IDE/source language combination, because Atom would have different internal data structures than VS Code.

imtringued 5y ago
Just defer to the classical non solution of writing everything in C. The kernel was written in C, now everything else must be as well. You don't have a say in that, apparently.
mike_hearn 5y ago
No, but they should probably share the same runtime, have some level of interop and be garbage collected because that makes crossing the barrier between language backend and IDE frontend so much more efficient and productive. Historically for IntelliJ that meant writing everything in Java. Nowadays plugins are written in many different languages. You could write plugins in Ruby or Python if you wanted to. They run on the JVM. You could even use C++ and get the same benefits because GraalVM can run C++ on the JVM itself, i.e. it will apply GC to the C++ parts so you don't have to worry about ownership across the interface. But that'd be an advanced move and I don't think anyone has tried that; for such big gaps in language they tend to fall back on the more conservative multi-process model again. Stuff like Sulong is too new to have made such an impact. Atom would have different internal data structures than VS Code. LSP doesn't solve that. It either forces everyone to implement the LSP model and data structures, or you have a mismatch and translation anyway.

4 ms·

I'm not sure I understand. Are you saying that compilers/analyzers should be written in the same language in which the IDE is written? If not, then how are you

by adwn 5y ago

imtringued 5y ago
Just defer to the classical non solution of writing everything in C. The kernel was written in C, now everything else must be as well. You don't have a say in that, apparently.
mike_hearn 5y ago
No, but they should probably share the same runtime, have some level of interop and be garbage collected because that makes crossing the barrier between language backend and IDE frontend so much more efficient and productive. Historically for IntelliJ that meant writing everything in Java. Nowadays plugins are written in many different languages. You could write plugins in Ruby or Python if you wanted to. They run on the JVM. You could even use C++ and get the same benefits because GraalVM can run C++ on the JVM itself, i.e. it will apply GC to the C++ parts so you don't have to worry about ownership across the interface. But that'd be an advanced move and I don't think anyone has tried that; for such big gaps in language they tend to fall back on the more conservative multi-process model again. Stuff like Sulong is too new to have made such an impact. Atom would have different internal data structures than VS Code. LSP doesn't solve that. It either forces everyone to implement the LSP model and data structures, or you have a mismatch and translation anyway.