7 ms·

> I've never met a FFI I didn't come to loathe I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer p

> I've never met a FFI I didn't come to loathe I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).

jjoonathan 13y ago
I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half-baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired. I'm not sure there is any way around the impedance mismatches between languages. They're all slightly different for a reason. Perhaps clean C APIs are the best we can hope for.
- digikata 13y ago
  I keep hoping that some accessibility upgrade comes to the linker akin to how LLVM made compiler infrastructure more accessible, might make FFI bridging more automated. For example, if GDB can access and take apart C structs an automated way, why is FFI coding always seem to have programmers do a lot of mechanical interfacing work. Not that all the other JVM, CIL, etc aren't approaches that yield some improvements, but something that upgrades capability or accessibility at the level of the ABI linkage level is going to be a wider impact.
- pjmlp 13y ago
  > I'm not sure there is any way around the impedance mismatches between languages. CLR has an approach for that by defining what is known as CLS, Common Language Subsystem. Likewise they have a similar approach on WinRT, known as Type Providers. However they also have their impedance mismatches, as you are only allowed to use types that are usable by all languages that target such runtimes. The benefit is that they still allow for an higher level of code abstractions than pure C functions.
sitkack 13y ago
COM was actually not a bad model. Sadly the closest thing is HTTP and JSON right now.
- pjmlp 13y ago
  s/was/is/ COM is the basis for most Windows APIs since XP, and the basis for the new WinRT runtime. Lets see how it might look like with Windows 9.
pjmlp 13y ago
You mean like OS/400 TMI, .NET, JVM?
Toenex 13y ago
Yep me too. People are too quick to dismiss the cross language issues which can in my experience can slowly erode the benefit. Typically you use an FFI to access particular functionality offered in libraries/classes only offered in another language. In my experience it is only a temporary solution, a does-it-work test. After that you need to recode. Having said that, in my experience Lua(JIT) does this pretty well with C libraries but Lua was designed as the scripting companion to C from day one. The JVM offers a better place to tackle these issues. Scala and Java cross calling is often more than adequate. Perhaps a Julia compiler for the JVM could be a step in the right direction.

jjoonathan 13y ago

I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half-baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired. I'm not sure there is any way around the impedance mismatches between languages. They're all slightly different for a reason. Perhaps clean C APIs are the best we can hope for.

digikata 13y ago
I keep hoping that some accessibility upgrade comes to the linker akin to how LLVM made compiler infrastructure more accessible, might make FFI bridging more automated. For example, if GDB can access and take apart C structs an automated way, why is FFI coding always seem to have programmers do a lot of mechanical interfacing work. Not that all the other JVM, CIL, etc aren't approaches that yield some improvements, but something that upgrades capability or accessibility at the level of the ABI linkage level is going to be a wider impact.
pjmlp 13y ago
> I'm not sure there is any way around the impedance mismatches between languages. CLR has an approach for that by defining what is known as CLS, Common Language Subsystem. Likewise they have a similar approach on WinRT, known as Type Providers. However they also have their impedance mismatches, as you are only allowed to use types that are usable by all languages that target such runtimes. The benefit is that they still allow for an higher level of code abstractions than pure C functions.

sitkack 13y ago

COM was actually not a bad model. Sadly the closest thing is HTTP and JSON right now.

pjmlp 13y ago
s/was/is/ COM is the basis for most Windows APIs since XP, and the basis for the new WinRT runtime. Lets see how it might look like with Windows 9.

pjmlp 13y ago

You mean like OS/400 TMI, .NET, JVM?

Toenex 13y ago

Yep me too. People are too quick to dismiss the cross language issues which can in my experience can slowly erode the benefit. Typically you use an FFI to access particular functionality offered in libraries/classes only offered in another language. In my experience it is only a temporary solution, a does-it-work test. After that you need to recode. Having said that, in my experience Lua(JIT) does this pretty well with C libraries but Lua was designed as the scripting companion to C from day one. The JVM offers a better place to tackle these issues. Scala and Java cross calling is often more than adequate. Perhaps a Julia compiler for the JVM could be a step in the right direction.