[erlang-questions] Erlang vs Clojure
Ciprian Dorin Craciun
Sat Nov 24 20:30:08 CET 2007
On Nov 12, 2007 7:35 PM, Torbjorn Tornkvist <> wrote:
> Ciprian Dorin Craciun wrote:
> > On Nov 23, 2007 6:19 PM, Torbjorn Tornkvist <> wrote:
> >> Ciprian Dorin Craciun wrote:
> >>> I would see the benefit of a Lisp-syntax-based Erlang version --
> >>> but compiled to beam... Just see the recent posts on macros and other
> >>> Lisp functionalities.
> >> Why not implement a Scheme to Erlang-Core compiler then?
> >> Just focus on the sequential parts and let concurrency
> >> hide inside modules written in Erlang. I did some
> >> experiments like this with a Haskell syntax:
> >> http://blog.tornkvist.org/blog.yaws?id=1190846785574003
> >> Cheers, Tobbe
> >>> Ciprian.
> >>> P.S.: When I say Lisp I mean the whole Lisp family, but I would
> >>> incline to Scheme.
> >>> On Nov 23, 2007 12:48 AM, Robin Bhattacharyya <> wrote:
> >>>> This is a quick qualitative comparison of Erlang and Clojure:
> >>>> http://groups.google.com/group/clojure/browse_thread/thread/2a2b24ffef5d1631
> >>>> Does anyone see the benefit of a Lispy version of Erlang on the JVM?
> >>>> Robin
> > This would be the basic idea... But for now I lack the time to do
> > it... (And I would also have to study the bytecode specification.)
> No you don't have to look into the bytecode!
> Erlang Core is nothing more/less than an enriched
> lambda calculus. This means that it should be pretty easy to
> translate a Scheme syntax into Erlang Core (see the paper by
> Richard Carlsson that describes the Erlang Core).
> > Just a some minor complaints (so they can be ignored :) I would
> > gladly use Erlang for most projects I am working on -- which usually
> > reside on server side -- if:
> > -- I would have a nice macro system that blends into the normal
> > syntax -- for example in Common Lisp 'or' is implemented as a macro,
> > but you don't notice it...
> > -- I would have proper support for strings, for example an object
> > that resembles binary but which is specially built for string
> > processing.
> > -- I would have proper / mature / stable / feature-full libraries
> > for all kind of activities (database access, XML processing, etc.)
> > But as I have seen from this group Erlang still has problems in
> > this areas...
> I don't think Erlang has got (big) 'problems' in these areas.
> We have (and are) doing amazing stuff in Erlang since a long time now.
> And frankly, I don't care if the world don't realize the power of
> Erlang. I'm just happy as long as I can use it as my 'secret weapon'...
> Cheers, Tobbe
Please don't understand me wrong. I am not overlooking the power
of Erlang, and also I am not minimizing the importance of all the
systems built in Erlang. I am just pointing some areas where some
improvements would make a difference -- at least for me.
I am perfectly aware that Erlang was not built with these targets,
but as it is evolving it could also look in this direction. Because if
Erlang wants to be an important player in the Web 2.0 / 3.0 movement
-- at least on the server side -- it will need serious / native
support for string (+ regex) and XML handling.
More information about the erlang-questions