Erlang Development Environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Erlang Development Environment

Hakan Stenholm
>>Fellow Erlangers,
>>
>>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
>indentation.
>
>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
visible.
* 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.
>
>        Robert



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Erlang Development Environment

tobbe

> 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):

I agree. I just want to clarify that the reason for xerl
was to let (SUN) textedit "hackers" to use something
that at least could do automatic indentation. For example,
before xerl, we had students at some courses that wrote
Erlang programs where each line started in column 1 or
even worse, wrote the whole program in one (wrapped) line... :-)

Cheers /Tobbe
(Ps. xerl used pxw which was a layer on top of the Athena widget set)


Loading...