Erlang Development Environment
Tue Mar 6 19:57:13 CET 2001
>>I've read a number of suggestions for a better Erlang Development
>>Environment than emacs.. It certainly seems we are falling behind some other
>>languages in terms of support environment. (OCaml, Clean, Python etc).
I don't mind a nicer enviroment, but I feel that a thight integration between
dev. enviroment and the erlang language/VM is a bad idea for several reasons:
* it should be possible to use erlang with a shell and a texteditor of your
choice for portablity reasons.
* gui interfaces can be slower (to perfrom certain tasks) than command line
* I like the emacs(to edit) + shell(run and compile) + netscape(read doc)
combination becouse it works just same for allmost any language: erlang, java, C
Note: it's a lot of (redundant ?) work to make a system that does what emacs +
shell + netscape do well - I suppouse one could do some kind of framework that
simply uses these applications (perhaps another texteditor though ?).
>There used to be a simple but perfectly usable development environment
>called xerl (I think). It consisted of an editor window and a coupled
>shell window with some helpful buttons. The editor was textedit-like,
>but had a reasonable knowledge of Erlang syntax so it could help with
>While not as powerful as the emacs environment it was perfect for users
>who were shy of emacs or running on Windows.
I tried to use xerl (not for very long though, emacs + shell was a much nicer
combo) when I worked o my master thesis about three years ago and I found xerl
to rather horrible (mostly GUI vise):
* editor and shell in one window -> reduced vertical space (side by side would
use the screen area more efficently) -> bad code overview due to fewer lines
* menus implemented by buttons, mouse button must be pressed down for the menue
to remain visible, it was easy to accidently select a menu item yielding all
kind of fun unexpected effects :)
* very non-standard gui look and behaviour
* no real benefits compared to useing emacs and a shell
Note: this is mostly a complaint about the xerl implementation NOT the basic
idea of xerl.
>Best of all it was written in Erlang so it could have been extended
>into a full environment with close coupling to the debugger and other
>graphical system display tools.
>I don't know why it was dropped. It was pre-gs so it would have had to
>been ported. Maybe the code still exists somewhere
It's still availible in the comercial R5 OTP version (run erl -x)
>and could be used
>as a starting point for a new environment.
>I porbably think, without having given too much thought on the subject,
>that Gtk is the way to go. If you were doing a "product" for money
>then I would buy some portable environment.
More information about the erlang-questions