3 ms·

Function calls between languages are typically expensive and difficult to implement. Each language generally has its own expectations about the layout of data i

Function calls between languages are typically expensive and difficult to implement. Each language generally has its own expectations about the layout of data in memory, which means that for language A to call a function written in language B, it needs to set up a block of memory in the layout expected by language B. This normally involves a lot of copying, which adds overhead to the function call. There also needs to be some code that does this copying, and this code needs to be implemented for every pair of languages. Alternatively, all the languages can agree on a common interface level (C, JVM, .NET, etc.), but in this case most languages won't get a function interface that feels native to the language.

flohofwoe 8y ago
Agreed, but I think those problems should be solved, the same way LLVM solved the N:M frontend:backend problem :) It's very likely that interacting with such a generic library interface doesn't feel native to the language, but I think it doesn't have to be a monstrosity like DOM or CORBA.
- PeterisP 8y ago
  IMHO these problems are fundamentally unsolvable, often because the data models are incompatible (the fundamental behavior and benefits of language A relies on their data structures having trait X; and the fundamental behavior and benefits of language B relies on their data structures not having trait X), so a library written in one language can't just accept nontrivial data from the other, it can't be allowed to operate directly on the other language's data in memory without at least copying it and often requires a performance-killing transformation of the whole data. You see that in all kinds of interfaces across language boundaries. Memory layouts, thread safety, (im)mutability, structure ownership or reference counting, handles to external/OS resources, etc, etc. Every language is an abstraction that relies on certain assumptions, and those particular assumptions are what makes the language good for it's niche. Different languages rely on different, often incompatible assumptions. It's possible to build a wrappers that ensure that the assumptions of the other language are met and interaction with native data structures is possible and convenient (e.g. like Numpy does for Python), but that wrapper needs to be different for different languages and assumptions, it can't be the same library, it needs to behave differently in other languages to meet their expectations.
  - mike_hearn 8y ago
    Truffle solves these problems. Accessing foreign data layouts results in the access patterns of the foreign language being inlined and compiled into the accessing language. In other words data adaptation is done just-in-time and at the read site, rather than by copying entire data structures ahead of time.
    - mpweiher 8y ago
      Well, for an interesting definition of "solves". As far as I can tell, it effectively introduce a new (implementation-)language, the Truffle language and then adds implementations of language front-ends that compile to this Truffle language. Which can be functionally adequate for some, maybe many use-cases, but is not the same as actual interoperability.
      - mike_hearn 8y ago
        I wouldn't describe it like that. There's no super-language. That's not how Truffle works at all. Rather, Truffle is a way to express language semantics through writing interpreters, such that interpreted ASTs are then compiled into native code blocks.
tabtab 8y ago
Php took the approach of implementing many of its libraries using existing C libraries. They may change the parameters and packaging, but they are only reinventing the interfaces, not the implementation. It's one of the reasons for Php's early success, despite being a somewhat clunky language. Therefore if anyone out there wants to invent Yet Another Language, try to piggyback on existing C libraries to speed up library creation.

flohofwoe 8y ago

Agreed, but I think those problems should be solved, the same way LLVM solved the N:M frontend:backend problem :) It's very likely that interacting with such a generic library interface doesn't feel native to the language, but I think it doesn't have to be a monstrosity like DOM or CORBA.

PeterisP 8y ago
IMHO these problems are fundamentally unsolvable, often because the data models are incompatible (the fundamental behavior and benefits of language A relies on their data structures having trait X; and the fundamental behavior and benefits of language B relies on their data structures not having trait X), so a library written in one language can't just accept nontrivial data from the other, it can't be allowed to operate directly on the other language's data in memory without at least copying it and often requires a performance-killing transformation of the whole data. You see that in all kinds of interfaces across language boundaries. Memory layouts, thread safety, (im)mutability, structure ownership or reference counting, handles to external/OS resources, etc, etc. Every language is an abstraction that relies on certain assumptions, and those particular assumptions are what makes the language good for it's niche. Different languages rely on different, often incompatible assumptions. It's possible to build a wrappers that ensure that the assumptions of the other language are met and interaction with native data structures is possible and convenient (e.g. like Numpy does for Python), but that wrapper needs to be different for different languages and assumptions, it can't be the same library, it needs to behave differently in other languages to meet their expectations.
- mike_hearn 8y ago
  Truffle solves these problems. Accessing foreign data layouts results in the access patterns of the foreign language being inlined and compiled into the accessing language. In other words data adaptation is done just-in-time and at the read site, rather than by copying entire data structures ahead of time.
  - mpweiher 8y ago
    Well, for an interesting definition of "solves". As far as I can tell, it effectively introduce a new (implementation-)language, the Truffle language and then adds implementations of language front-ends that compile to this Truffle language. Which can be functionally adequate for some, maybe many use-cases, but is not the same as actual interoperability.
    - mike_hearn 8y ago
      I wouldn't describe it like that. There's no super-language. That's not how Truffle works at all. Rather, Truffle is a way to express language semantics through writing interpreters, such that interpreted ASTs are then compiled into native code blocks.

tabtab 8y ago

Php took the approach of implementing many of its libraries using existing C libraries. They may change the parameters and packaging, but they are only reinventing the interfaces, not the implementation. It's one of the reasons for Php's early success, despite being a somewhat clunky language. Therefore if anyone out there wants to invent Yet Another Language, try to piggyback on existing C libraries to speed up library creation.