(Prolog + LISP + Erlang) with integration issues versus C++

Richard A. O'Keefe ok@REDACTED
Fri Aug 26 07:42:25 CEST 2005

	> The key objection is that Backup software appliance needs performance
	> and Erlang+Prolog+clisp is not a good idea.
	What kind of performance? I would assume disk and network not CPU!
I teach an information retrieval paper, in which students write their
own simple IR engine.  This year, I *begged* students to use C rather
than Java.  I even presented figures showing that simple I/O ran much
slower in Java than C.  (I shan't report them here, because you wouldn't
believe me, they were so bad.)  Most of the students went ahead and used
Java anyway, and predictably got programs that took hours to do what mine
did in a minute and a half.

The problem is not that Java is byte-coded and C native-compiled.
This was done with the Java code native compiled.
The problem is simply that Java I/O goes through so many layers of
wrappers that reading a single character takes an *amazing* number of
method calls.

This affects Lisp and Prolog to some extent.  Prolog I/O _can_ be made quite
fast, but still not as fast as C.  Lisp I/O these days may well go through
CLOS, with the usual penalties.

But Java *can* be used for high-performance I/O, thanks to the (new)
'nio' packages.  Basically, Sun added a bunch of stuff so that Java could
"steer" I/O with the hard work bypassing all those extra layers.

The same idea works for Lisp, Prolog, and Erlang:  if there are operations
like copying bytes from one file/socket to another which are performance
critical, move those and only those down to the C level and call them 

Consider another mixed-language example, the multi-media/programming
environment Squeak.  (Squeak is an Open Source Smalltalk system based
on the original ST-80 code.)  Squeak is written in Smalltalk, with parts
of that Smalltalk code automatically translated to C.  (That is, the same
code can be run in the Smalltalk debugger or via the C compiler as native
code.)  Squeak includes live 3D animation, MPEG playing, sound generation,
text-to-speech, and does I/O well enough for some people to use it as their
web server.  It has a "plugin" architecture (in both senses: there is a
Squeak plugin available from www.squeakland.org which lets you view Squeak
active media in Netscape, and there are things you can plug into Squeak)
to access C stuff.

Is this maintainable?  The darned thing is maintained SO much that I can't
keep up!  Is there a performance problem?  Nope, while Squeak is byte-code
only (there is a JIT, but every time it looks as though it's about to be
delivered in a few months, something changes...) all the heavy lifting is
done in C with Squeak steering it.

Don't forget, gprolog isn't the only Prolog in town.
SWI Prolog has sockets and concurrency (PLUS the second best free SGML
parser plus RDF support PLUS CHR-style constraint processing).
It's probably slower, 
There's also Ciao, which has all sorts of amazing stuff.

One test for the consultant:

    get the consultant to write a simple forward-chaining production
    rule interpreter in each of Prolog, Lisp, Erlang, and C++.

    If he can do this, his opinion on these languages is worth having.

Second test, assuming (with high confidence) that the first test is failed:

    If his opinion about the maintenance costs of the languages is not
    based on his own experience, whose experience IS it based on?

More information about the erlang-questions mailing list