> 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).
> 1. Does anyone really feel the need for something better/different?
I don't feel the need for anything drastically better. I strongly dislike
language implementations that depend on emacs, but I've been using Erlang
under Windows (with a very simple text editor) and don't have major
complaints. I can think of some smaller things:
1. A shell command for starting an external text editor. Or perhaps a way
of having a failed compile start up a text editor at a certain line of code.
This is easy to do, but it would be nice to have it implemented in a
2. A shell command for timing specific pieces of code. Something where you
can specify a function, parameters, and the number of times to execute that
function. In Lisp I'm always doing this:
(time (dotimes (i 1000000) (test 0 1 2)))
I don't know a simple equivalent in Erlang.
3. I know Erlang is used more under UNIX than Windows, but it would be cool
to see the process browser and other graphical apps written with Delphi (for
example) so they aren't so dog slow and ugly under Windows :)
4. Use color in the shell window. Have typed commands be a different color
See? All minor!
Hmmm...broadening this to "Suggestions for Erlang in general," (I know, I
know, off topic!) I have a relatively short list:
1. Be able to compile the Windows version under Windows, instead of the
wacky cross-compilation method currently used. Ugh.
2. Get stand-along Erlang working under Windows. I would *love* this!
3. There are two spots where I find I prefer Lisp to Erlang:
a. There's no simple, efficient way to have large, constant data structures.
When attempting to translate some code from Peter Norvig's excellent
_Paradigms of Artificial Intelligence Programming_ I ran into this a lot.
It would be nice to define a global, unmodifiable data structure that could
be used by different processes without the entire structure existing in each
process, and without copying overhead of ETS. I'm specifically thinking of
something like Lisp's defparameter facility. Sometimes there are ways
around this, and sometimes not.
b. Sometimes you just really need arrays that can be updated in O(N) time.
On a global scale, ETS can be used, but on a smaller scale, for some
algorithms, there's no speedy alternative. The process table, I guess.
Couldn't tuples theortically be reference counted, so they could be copy on
write? This is probably much messier than it sounds :)
James Hague wrote:
> 3. I know Erlang is used more under UNIX than Windows, but it would be cool
> to see the process browser and other graphical apps written with Delphi (for
> example) so they aren't so dog slow and ugly under Windows :)
I'd rather the root of this problem be solved; namely, that GS is slow
under Windows. Could the performance not be improved if it were
implemented directly with Windows API calls (avoiding Tk completely)?
> 2. Get stand-along Erlang working under Windows. I would *love* this!
> Please, please!
I second that emotion.
> a. There's no simple, efficient way to have large, constant data structures.
OK, but I'd rather not there be some "special method" in Erlang for
making large constant data structures, efficient. An optimizer of some
sort should see to that, behind the scenes.
My opinion on the general topic - not necessarily representative of the
typical Erlang programmer, admittedly - is that if some sort of
"visually-oriented development environment" is called for, then we might
as well shoot for the stars. Create a full-blown graphical syntax for
Erlang along the lines of Boerenkool or Lava. Allow for several
parallel views of the same source code. It could be viewed "by module",
"by process", "by node", "by dependency", or any other conceivable
hierarchical breakdown that is applicable to things in Erlang.
The hardcore will always use the shell anyway, might as well make it as
nice as possible for the GUI users; more than just a specialized text
I don't see why it couldn't be done in GS, either. Especially if there
was an implementation of GS closer to the operating system.
> 2. A shell command for timing specific pieces of code. Something where you
> can specify a function, parameters, and the number of times to execute that
> function. In Lisp I'm always doing this:
> (time (dotimes (i 1000000) (test 0 1 2)))
> I don't know a simple equivalent in Erlang.
timer:tc(io, fwrite, ["hello world\n"]).
222 means "222 microseconds of wall time elapsed during execution".