Language Bindings for Erlang Again

Michel Urvoy michel.urvoy@REDACTED
Tue Jun 6 08:18:14 CEST 2006


2006/6/5, Thomas Lindgren <thomasl_erlang@REDACTED>:
>
>
> --- Michel Urvoy <michel.urvoy@REDACTED> wrote:
>
> > 2006/6/3, Thomas Lindgren
> > <thomasl_erlang@REDACTED>:
> > >
> > > Look harder.
> >
> > Right, I found one real commercial site, a bank:
> > http://www.kreditor.se/Jobb/jobb.html
>
> Just the Nortel SSL-VPN product has delivered
> thousands of commercial intranet sites, written in
> Erlang and Yaws.

I've no doubt about this. The point I had already noticed with Nortel
is that Erlang is mentioned nowhere.
The company that use or have used Erlang are very discret about the
language. Even with an open source project like process one /
ejabberd:
http://www.process-one.net/en/projects/ejabberd/

It feels like if people were not proud to claim they use Erlang.

>
> > > > And the choice of Erlang (+C) and nothing else
> > is
> > > > not very easy when
> > > > you have on the shelf a lot of code you will not
> > be
> > > > able to reuse.
> > >
> > > If that's what you believe, maybe you should read
> > the
> > > documentation a bit more closely.
> > >
> > Right again, there is the java node interface
> > (Jinterface), but my
> > purpose was more to reuse old Pascal or Fortran
> > code.
>
> You can find plenty of other interfacing code if you
> look, including Orber (CORBA), Comet (COM), erl
> interface, IC, ...

Well, I can understand people that want to develop their own
interface, but so many differents projects add more complexity and
confusion. It's up to Erlang conceptors to fix the canvas of the
bindings, so people have just to focus their work on the language
port.
In that way you can interface more languages and the result is more
clean and coherent.


>
> If you want to wrap Pascal or Fortran, then you can
> integrate at different points by communication via
> pipes, writing a C-node wrapper, or writing an Erlang
> driver.
I'm afraid I'm not able to do this yet.

>
> > > > Furthermore I should be able to use the hot
> > > > replacement code mechanism
> > > > on the two nodes to update the foreign code.
> > >
> > > Hot code loading for other languages is not an
> > Erlang
> > > issue.
> >
> > If you say so! But it could be. I've not seen in the
> > documentation it was not.
>
> How could it be? Most languages don't even have a
> semantics for hot code loading.

I  just ment the documentation was not clear about this point. It
better to say the things:
Hot code loading is limited to this use (to precise) with C bindings.

>
> > > Basically, it sounds like you are inventing
> > > problems
> > > where there aren't any. Why?
> >
> > I'm sorry Thomas, I've no answer for this point, but
> > your question is
> > a kind of answer to my Erlang paradox.
>
> In other words, you strongly feel that Erlang would be
> used (much?) more if there was even more support for
> wrapping arbitrary libraries than today? Or if Erlang
> somehow implemented hot code loading for arbitrary
> languages?

I strongly feel that Erlang is insulated.
Despite a certain activity in Academics (thesis, publications).

>
> Well, if you enjoy working on interfacing, why not
> join the recently started Dryverl project? As to
> general hot code loading, this seems still to be very
> much a research topic. Here are a couple of pointers:
>
> http://www.cs.umd.edu/projects/dsu/
> http://www.pmg.lcs.mit.edu/

I had a look to that post, last month.
The only point I wonder is why experiment Dryverl on a C binding, that
is already improved, instead of  another language that is not covered.

>
> Or why not have a look at how to improve/extend hot
> code loading in Erlang itself?

In a few years when I'll get retired.
Regards, Michel.

>
> Best,
> Thomas
>



More information about the erlang-questions mailing list