3 ms·

The feature I care about most is interoperability of components written in different programming languages, which doesn't seem to be a priority for either camp.

by rectang 12y ago

kaeluka 12y ago
ECOOP may be a good place to look. IIRC last year at ECOOP there was some work by or with Laurence Tratt.
- heathermiller 12y ago
  True. And on that note – Curry On is co-located with ECOOP, and Curry On registration also covers ECOOP. So you can attend both on just one ticket :)
jerf 12y ago
This conference is more likely to take you farther away from that goal than get closer. The foundational reason [1] that components are not interoperable is that they function in different guarantee regimes. A pure language can not simply "interoperate" with code that expects to mutate. Yes, the pure language can wrap around the mutation-based code, but it will forever have an impedance mismatch. You can't trivially interoperate with languages that have different async/sync "colors", per the recent discussion: https://news.ycombinator.com/item?id=8984648 https://news.ycombinator.com/item?id=8984648 . And the discussion is good, because everything else that people mention as other things they thought the post was getting at are also examples of places where the code can't just trivially interop. And I say this will likely take you farther away than closer because right now research tends to be focused on how to use colors more effectively, and how to use more colors in code rather than less. All this mitigates pretty strongly against cross-language interoperability. At least, against interoperability beyond what we have now, which I assume that you are not satisfied by. A lot of code today is "interoperable" because a lot of languages inherit the drab gray of C. For all the apparent differences between Python, Perl, Ruby, Lua, and C, in the end they are all languages of a very similar color. Python, Perl, Ruby, and Lua amount to programming in C where every line is a complicated function call instead of a simple C statement, but you're still fundamentally in C. This has provided an illusion that interoperability is either somehow "easy" or something that could be improved, but as we move away from C's drab gray, interoperability is going to get worse, not better. Perhaps someday if we settle on a particular rainbow, some form of code that can be sufficiently accurately labeled with its colors could be interoperable, but we're going to farther from that goal before we get closer. [1]: I say this is the "foundational reason" because it's the fundamental one that can't be fixed by "just trying harder". There are also incidental reasons that often depend on exactly where in the lifecycle of the language C-interop was considered (compare Lua with Python, for instance), and accidents of history that persist because there's no point fixing them because the fundamental problem will remain.
- skybrian 12y ago
  I think this will be solved (well, managed) by using unrestricted "colors" as glue languages at the top of the stack and restrictive colors for portable, embedded code that should be sandboxed. Pure functions shouldn't be hard to call or to cross-compile.
  - actsasbuffoon 12y ago
    I'm not sure about this. For instance, Scala has a very capable Java FFI, but using it can be problematic due to the different expectations of the languages. In Java, you represent a missing value with null, but well-typed Scala should never encounter a null. Java will also regularly raise exceptions, but Scala usually prefers wrapping values that may fail with Either. There's no clear way to automatically bridge the gap, which means falling back to Java is always going to be a necessary evil, rather than something that should be encouraged.
    - skybrian 12y ago
      Scala isn't really designed for embedding but something else might work. Perhaps a little language specifically designed for embedding. Some existing little languages include regexps and SQL, but perhaps there's room for portable pure functions. But you do have to decide how data gets passed in and out.
- rectang 12y ago
  > right now research tends to be focused on how to use > colors more effectively, and how to use more colors in > code rather than less. I understand that deprioritizing interop suits academics because new "colors" are more vivid when they don't have to mix with old ones, and also that commercial vendors have an interest in platform lock-in. But as a working programmer, I'm not satisfied by that. Microservices are an interesting development in this space, providing an architecture within which components with very different underlying semantics may cooperate -- it's not a new idea, but neither was AJAX. Other historically significant interoperability initiatives are CORBA, COM, SWIG and GObject. Then there are the virtual machines which run multiple programming languages (JVM, CLR, Parrot) -- but it is very hard for a VM to provide a superset of semantics in order to support every last "color" for every supported language. The project I work on, Apache Clownfish (a "symbiotic object system"), takes the opposite approach: instead of aspiring to provide a superset of semantic functionality, it provides a basic subset plus glue, and instead of aspiring to serve as a platform it is distributed as a library. Working through issues like how to design an object system which is compatible with diverse GC/allocation schemes is fun and mind-expanding, and I'm looking forward to publishing some white papers. But I wish there was more existing research. If the state of interop were to advance, maybe it wouldn't be so expensive to migrate to new programming languages and the industry could evolve faster.
pjc50 12y ago
The best place for that is probably the C#/F# infrastructure, strangely.
obastani 12y ago
Is this related to what you have in mind? http://adam.chlipala.net/papers/UrWebPOPL15/ http://adam.chlipala.net/papers/UrWebPOPL15/

The feature I care about most is interoperability of components written in different programming languages, which doesn't seem to be a priority for either camp.

by rectang 12y ago

The feature I care about most is interoperability of components written in different programming languages, which doesn't seem to be a priority for either camp.

kaeluka 12y ago

ECOOP may be a good place to look. IIRC last year at ECOOP there was some work by or with Laurence Tratt.

heathermiller 12y ago
True. And on that note – Curry On is co-located with ECOOP, and Curry On registration also covers ECOOP. So you can attend both on just one ticket :)

jerf 12y ago

This conference is more likely to take you farther away from that goal than get closer. The foundational reason [1] that components are not interoperable is that they function in different guarantee regimes. A pure language can not simply "interoperate" with code that expects to mutate. Yes, the pure language can wrap around the mutation-based code, but it will forever have an impedance mismatch. You can't trivially interoperate with languages that have different async/sync "colors", per the recent discussion: https://news.ycombinator.com/item?id=8984648 https://news.ycombinator.com/item?id=8984648 . And the discussion is good, because everything else that people mention as other things they thought the post was getting at are also examples of places where the code can't just trivially interop. And I say this will likely take you farther away than closer because right now research tends to be focused on how to use colors more effectively, and how to use more colors in code rather than less. All this mitigates pretty strongly against cross-language interoperability. At least, against interoperability beyond what we have now, which I assume that you are not satisfied by. A lot of code today is "interoperable" because a lot of languages inherit the drab gray of C. For all the apparent differences between Python, Perl, Ruby, Lua, and C, in the end they are all languages of a very similar color. Python, Perl, Ruby, and Lua amount to programming in C where every line is a complicated function call instead of a simple C statement, but you're still fundamentally in C. This has provided an illusion that interoperability is either somehow "easy" or something that could be improved, but as we move away from C's drab gray, interoperability is going to get worse, not better. Perhaps someday if we settle on a particular rainbow, some form of code that can be sufficiently accurately labeled with its colors could be interoperable, but we're going to farther from that goal before we get closer. [1]: I say this is the "foundational reason" because it's the fundamental one that can't be fixed by "just trying harder". There are also incidental reasons that often depend on exactly where in the lifecycle of the language C-interop was considered (compare Lua with Python, for instance), and accidents of history that persist because there's no point fixing them because the fundamental problem will remain.

skybrian 12y ago
I think this will be solved (well, managed) by using unrestricted "colors" as glue languages at the top of the stack and restrictive colors for portable, embedded code that should be sandboxed. Pure functions shouldn't be hard to call or to cross-compile.
- actsasbuffoon 12y ago
  I'm not sure about this. For instance, Scala has a very capable Java FFI, but using it can be problematic due to the different expectations of the languages. In Java, you represent a missing value with null, but well-typed Scala should never encounter a null. Java will also regularly raise exceptions, but Scala usually prefers wrapping values that may fail with Either. There's no clear way to automatically bridge the gap, which means falling back to Java is always going to be a necessary evil, rather than something that should be encouraged.
  - skybrian 12y ago
    Scala isn't really designed for embedding but something else might work. Perhaps a little language specifically designed for embedding. Some existing little languages include regexps and SQL, but perhaps there's room for portable pure functions. But you do have to decide how data gets passed in and out.
rectang 12y ago
> right now research tends to be focused on how to use > colors more effectively, and how to use more colors in > code rather than less. I understand that deprioritizing interop suits academics because new "colors" are more vivid when they don't have to mix with old ones, and also that commercial vendors have an interest in platform lock-in. But as a working programmer, I'm not satisfied by that. Microservices are an interesting development in this space, providing an architecture within which components with very different underlying semantics may cooperate -- it's not a new idea, but neither was AJAX. Other historically significant interoperability initiatives are CORBA, COM, SWIG and GObject. Then there are the virtual machines which run multiple programming languages (JVM, CLR, Parrot) -- but it is very hard for a VM to provide a superset of semantics in order to support every last "color" for every supported language. The project I work on, Apache Clownfish (a "symbiotic object system"), takes the opposite approach: instead of aspiring to provide a superset of semantic functionality, it provides a basic subset plus glue, and instead of aspiring to serve as a platform it is distributed as a library. Working through issues like how to design an object system which is compatible with diverse GC/allocation schemes is fun and mind-expanding, and I'm looking forward to publishing some white papers. But I wish there was more existing research. If the state of interop were to advance, maybe it wouldn't be so expensive to migrate to new programming languages and the industry could evolve faster.

pjc50 12y ago

The best place for that is probably the C#/F# infrastructure, strangely.

obastani 12y ago

Is this related to what you have in mind? http://adam.chlipala.net/papers/UrWebPOPL15/ http://adam.chlipala.net/papers/UrWebPOPL15/