

Curry On Prague 2015: Academia and industry need to have a talk - heathermiller
http://curry-on.org

======
rectang
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.

~~~
jerf
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.

~~~
rectang

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

~~~
jerf
"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](https://github.com/apache/lucy-
clownfish/tree/master/runtime)

------
heathermiller
Turns out that Bjarne Stroustrup will also be talking about the evolution of
C++ alongside of Curry On [http://2015.ecoop.org/event/invited-speakers-
bjarne-stroustr...](http://2015.ecoop.org/event/invited-speakers-bjarne-
stroustrup)

~~~
hga
That could be really good.

Although I've come to loathe the language, his 1994 book on the topic is
fantastically good and highly recommended: [http://www.amazon.com/The-Design-
Evolution-Bjarne-Stroustrup...](http://www.amazon.com/The-Design-Evolution-
Bjarne-Stroustrup/dp/0201543303)

------
janvite6
How many times does one get to see the creators of C++ and JS in the same
place?

~~~
mattgreenrocks
Last year's Lang.NEXT conference had Stroustrup, Pike, some ES6 devs, and Rust
devs (among many others). I really enjoyed it.

Hoping it happens again; seems like it's every two years.

------
Argorak
This is the perfect place for my "schönfinkeln?"-Shirt :).

------
heathermiller
Someone changed the title of the post to something that doesn't describe the
event at all. It's about bringing industry and academia together.

~~~
sctb
We just changed the subtitle to a different one from the submitted page. We're
open to suggestions for a better one.

~~~
heathermiller
The original title (which is most accurate) is: Curry On: Mainstream PL and
academic PL should talk more often

This also works (and illustrates that it's an event): Curry On: Mainstream PL
and academic PL should talk more often. Here is a venue.

The overarching point is that this is all about designers of mainstream
languages (and industry) and academic languages (academia) coming together.

------
jorjordandan
Why does every tech conference site have to mention drinking beers? I like
beer as much as the next guy, which is kind of the problem. It sorta seems
like conferences feel like they gotta bro it up.

~~~
NotOscarWilde
I think it could also be related to Czech Republic being the #1 country in
terms of beer consumption per capita [1]. It's definitely a national drink
there.

[1]:
[https://en.wikipedia.org/wiki/List_of_countries_by_beer_cons...](https://en.wikipedia.org/wiki/List_of_countries_by_beer_consumption_per_capita)

~~~
jkot
To be fair there are many tourists coming to Prague just to drink. And we
usually drink low-alcohol beer, 10 degree beer has ~3% alcohol content. And
finally hard alcohol is less popular.

Actual alcohol consumption is not that high. But yes, in pub water is often
more expensive than beer.

