Hacker News Reader

Comment by smorgusofborg | Hacker News Reader

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one.

You are free to expose an API where strings are not null terminated, etc. Anyone in any language is going to have to work their data into the API you provide so if it is alternatively complicated to make an intermediary language happy that's not really helping.

View on HN

This brings up a vague idea I have had. Redis is sort of a data structure server that can be used across languages. Could we not have an opensource data structure and algorithm library? Where languages, instead of implementing their core types and algorithms in their own library, instead add them (or reuse existing) ones to this library. Then your language becomes just a mapping of your languages semantics over these existing structures & functions.

Unfortunately this doesn't work for managed or interpreted languages with their own runtimes, where you want the types to run on their VM.

An example would be JIT-compiled C# data structures, no way to implement those on top of a shared library since specific instantiations have to be produced and compiled at runtime.

Such a data structure and algorithm library as a springboard would be still be incredibly useful, but then you wonder why it's not called "the C standard library" :)

I wonder though, I know a lot of tricks for performance are used, such as in python API, judicious use of inlining, putting some common functions in headers files etc. Depending on how far down the rabbit hole you want to go, could this library not also include code generation functionality for JIT's? Or even at compile time, is there anything stopping a library from generating code that could be included in your VM runtime as just an opaque function that can be called?

At that point you're effectively creating your own VM, and then you may ask why doesn't someone simply use the JVM or the CLR. Once you reach that degree of complexity, there are simply too many tradeoffs.

I certainly won't stop you from trying to develop such a thing, could be a nice way to get languages bootstrapped faster. Just keep in mind JIT compilation is forbidden in iOS, so e.g. C# needs an entirely different compilation strategy for that platform.

You can, but then you cannot automatically generate a wrapper that can convert language B strings to language A strings disguised as an opaque type C, because there is no way for the wrapper generator to know it is a string type, unless you wrote the wrapper generator yourself for your API specifically.

Reply on news.ycombinator.com