Hacker News new | ask | show | jobs
by rectang 4155 days 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.
1 comments
jerf 4155 days ago
"I understand that deprioritizing interop suits academics because new "colors" are more vivid when they don't have to mix with old ones,"

It's worse than that... some "colors" basically break if you allow admixture. For instance, immutable and lazy languages come crashing down around your ears if even so much as one thing unexpectedly mutates, because the compiler rewrote the order so strongly that even if you think you can second-guess the evaluation order, you're wrong. It's why "unsafePerformIO" in Haskell is even more dangerous than you might think it is as a novice... it isn't just that it violates the ideals of Haskell, it's really unsafe! It's not an idle comment, it's a serious warning. It is possible to use it correctly but it's very subtle.

"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."

This is why I qualified my post by assuming you were talking about more than these things, because they exist and aren't going anywhere. Fundamentally you can always send a message from a runtime and get a message back in return, but if there's any particular problem with that, it's that it's an oversolved problem rather than a not-solved-enough problem; too many choices! But that is not the fault or responsibility of any one language.

"The project I work on, Apache Clownfish (a "symbiotic object system")... 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'd point out that a quick glance at your project (which I specify so you can correct me if I'm wrong) makes it appear that I actually already called out all the languages that currently supports (C, Perl, Ruby) [1] as working in the same fundamental regime, before I knew about what you were talking about. It sounds like you're working on those accidental complexities, which may well bring great value to many people (and let me highlight that, I'm serious, this may well be an awesome project, let nothing I'm saying here be construed as a criticism of the project, its ideas, or its worthiness of being worked on!), but is currently working on C-gray to C-gray interop, which, alas, does little to counter the ideas I'm discussing here.

If you are interested in these ideas, you may find it worth your time to dig into Haskell/GHC a bit and just consider how you might even begin porting your ideas across. By no means would I suggest actually putting any time to code this in, but it might give you a different perspective to think about. If you are feeling less ambitious, even just looking at how you'd port it to Go, a language still mostly C-gray but with one colorful streak of asynch in it, could be an interesting compare & contrast.

[1]: https://github.com/apache/lucy-clownfish/tree/master/runtime

link