3 ms·

I was thinking about something similar the other day when I was setting up a language server in my IDE for a non-mainstream programming language. What if there

I was thinking about something similar the other day when I was setting up a language server in my IDE for a non-mainstream programming language. What if there was a language we could develop APIs / libraries with that would automatically work with any other language / runtime? I guess I'm describing C interop, but that's too low level. C stands on it's own. I have no idea how to solve this but there would have to be some standard interface that the C interopt is developed against to provide additional context / metadata to allow more native interoperability. I don't know if I'm doing a good job explaining it. But, the idea is just like a language server. A server is implemented by a specific runtime and it can automatically interop with any client-library written in any other language, natively. This just sounds like wishful thinking.

AndrewDucker 6y ago
On Windows this is called COM. A non-Microsoft equivalent would be CORBA.
pogorniy 6y ago
Check https://github.com/oracle/graal https://github.com/oracle/graal. From readme: > GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Clojure, Kotlin, and LLVM-based languages such as C and C++. and yes, it can do interop between those languages
- amelius 6y ago
  Caveat: Graal is developed by a law firm who happens to have some software engineers on the payroll. Better not touch.
schwartzworld 6y ago
There is something like that, a Unix shell. You can use the shell environment to string together small programs written in different languages. I mostly work in nodejs, and instead of connecting my things through language level bindings, I just write simple wrappers to call a child process and handle stdout and stderr. It might not work for all situations, but it means I can build my bits and pieces out of whatever language I want.
- TeMPOraL 6y ago
  I think the implicit desire of the parent is for the environment to handle data conversions for you. Unix shell is an unstructured text environment. Data loses all semantic context the moment it's pushed to stdout, and thus every program that wants to interact with it needs to have its own, half-baked, buggy parser included. This is wasteful and a source of many maintenance and security problems.
  - schwartzworld 6y ago
    It's not that hard if you just use common data formats. I don't have to reimplement a json or CSV parser in every language.
    - TeMPOraL 6y ago
      No, but someone else does. Every language comes with its own collection[0] of half-baked, bug ridden libraries for parsing JSON and CSV. JSON and CSV are particularly poor data formats, in that JSON has an impedance mismatch if the language you're using isn't JavaScript[1], and CSV means whatever the tool generating it think it means - it doesn't have to be comma, separated, or just values. Also, if you adopt either, you lose the benefit of human-readability, which is half of the justification for the UNIX tooling to emit plaintext in the first place. So one could as well bite the bullet and treat machine readability and human readability as separate concerns, and use formats suitable for each individually. -- [0] - It's never just one library. [1] - Do JSON objects get mapped to structs, arrays or hash tables in your language? How do you distinguish between true, false and null?
  - agumonkey 6y ago
    In some lispmachine demo by .. I forgot his name (~~amir gupta?~~ kalman reti) he talks about that aspect. Unix serializes everything to strings, while lisp machines just pass pointers around. Obviously simpler and faster but maybe less easy to move across machines (I'm speculating). I've always been saddened by the neverending amount of grep/perl fu needed in unix to do the same thing over and over. Similar feeling when using powershell, a lot of benefits of having a uniform set of interfaces for any kind of object. That said it feels a little straighjacketing compared to crunching strings. https://www.youtube.com/results?search_query=lisp+machine+kalman https://www.youtube.com/results?search_query=lisp+machine+ka...
MaxBarraclough 6y ago
Perhaps none of this will be new to you, but here are my thoughts: It's challenging because of the mismatches that can arise between programming languages. We tend to use C as the lingua franca for communication between languages (i.e. foreign function interfacing, FFI), but it doesn't make the problem trivial. C++ has dynamic dispatch, whereas C doesn't. Java has garbage-collection, whereas C doesn't. Haskell has lazy evaluation. C# has async. Lots of things that can't be mapped across directly to C functions. FFI is by no means a neglected domain. Where it's possible to make it easy, it generally is easy. C++ written in a C style, can very easily interface with C. Same for Ada. The trouble is when there's mismatch from the more advanced features of C++/Ada that don't map that naturally to C. I don't think a 'language server' would really bring anything new to the table. Where that approach makes sense, we already have REST.

AndrewDucker 6y ago

On Windows this is called COM. A non-Microsoft equivalent would be CORBA.

pogorniy 6y ago

Check https://github.com/oracle/graal https://github.com/oracle/graal. From readme: > GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Clojure, Kotlin, and LLVM-based languages such as C and C++. and yes, it can do interop between those languages

amelius 6y ago
Caveat: Graal is developed by a law firm who happens to have some software engineers on the payroll. Better not touch.

schwartzworld 6y ago

There is something like that, a Unix shell. You can use the shell environment to string together small programs written in different languages. I mostly work in nodejs, and instead of connecting my things through language level bindings, I just write simple wrappers to call a child process and handle stdout and stderr. It might not work for all situations, but it means I can build my bits and pieces out of whatever language I want.

TeMPOraL 6y ago
I think the implicit desire of the parent is for the environment to handle data conversions for you. Unix shell is an unstructured text environment. Data loses all semantic context the moment it's pushed to stdout, and thus every program that wants to interact with it needs to have its own, half-baked, buggy parser included. This is wasteful and a source of many maintenance and security problems.
- schwartzworld 6y ago
  It's not that hard if you just use common data formats. I don't have to reimplement a json or CSV parser in every language.
  - TeMPOraL 6y ago
    No, but someone else does. Every language comes with its own collection[0] of half-baked, bug ridden libraries for parsing JSON and CSV. JSON and CSV are particularly poor data formats, in that JSON has an impedance mismatch if the language you're using isn't JavaScript[1], and CSV means whatever the tool generating it think it means - it doesn't have to be comma, separated, or just values. Also, if you adopt either, you lose the benefit of human-readability, which is half of the justification for the UNIX tooling to emit plaintext in the first place. So one could as well bite the bullet and treat machine readability and human readability as separate concerns, and use formats suitable for each individually. -- [0] - It's never just one library. [1] - Do JSON objects get mapped to structs, arrays or hash tables in your language? How do you distinguish between true, false and null?
- agumonkey 6y ago
  In some lispmachine demo by .. I forgot his name (~~amir gupta?~~ kalman reti) he talks about that aspect. Unix serializes everything to strings, while lisp machines just pass pointers around. Obviously simpler and faster but maybe less easy to move across machines (I'm speculating). I've always been saddened by the neverending amount of grep/perl fu needed in unix to do the same thing over and over. Similar feeling when using powershell, a lot of benefits of having a uniform set of interfaces for any kind of object. That said it feels a little straighjacketing compared to crunching strings. https://www.youtube.com/results?search_query=lisp+machine+kalman https://www.youtube.com/results?search_query=lisp+machine+ka...

MaxBarraclough 6y ago

Perhaps none of this will be new to you, but here are my thoughts: It's challenging because of the mismatches that can arise between programming languages. We tend to use C as the lingua franca for communication between languages (i.e. foreign function interfacing, FFI), but it doesn't make the problem trivial. C++ has dynamic dispatch, whereas C doesn't. Java has garbage-collection, whereas C doesn't. Haskell has lazy evaluation. C# has async. Lots of things that can't be mapped across directly to C functions. FFI is by no means a neglected domain. Where it's possible to make it easy, it generally is easy. C++ written in a C style, can very easily interface with C. Same for Ada. The trouble is when there's mismatch from the more advanced features of C++/Ada that don't map that naturally to C. I don't think a 'language server' would really bring anything new to the table. Where that approach makes sense, we already have REST.