Re: Is Elisp really that slow?

[Emanuel Berg]

Eli Zaretskii wrote:

> Modern debugging front-ends show multiple
> windows every time the debuggee stops:
> a window with the source, another with local
> variables, yet another with callstack (a.k.a.
> "backtrace"), one more with program
> input/output, optionally threads and
> registers, etc. Displaying that on the
> console requires the user to type separate
> commands for each display, which is time
> consuming, and also pushes the other stuff
> off the visible portion of the console window
> (so you need to retype the same commands, or
> scroll the window with the mouse, to see that
> again). So using a debugger from a console is
> much less convenient, when you deal with
> a complex program, and users nowadays expect
> much more from an IDE.

OK, point taken. Users, newcomers, aren't
impressed by Emacs. The don't dig the console
and they use the mouse. And they want
everything integrated, all tho, which is
amusing, integration is limited to
a single language.

(Maybe MS IDEs can do all of C#, VB(A), and
MS Access now that I think about it...?)

> Actually, font-lock needs to be customized
> for each language, and there are commands
> that move by functions, blocks, and other
> lexical units, which also need to understand
> the language to some extent. IOW, someone
> must write the code to support each language
> with the infrastructure provided by Emacs; if
> we didn't write that, we cannot claim we
> support the language "because the tools are
> there".

OK, now it gets totally confused %) The
different language major modes are the absolute
_backbone_ of Emacs as a programmer editor,
indispensible! Obviously we want them for every
conceivable language to be as good as possible!
Setting up font-lock and indentation for
a programming language major mode (which even
I have done BTW) isn't what I thought we
were talking about rather much more advanced
stuff, the refactoring stuff (how ever that
works), integrating the debugger and build
process, and so on, and as for
language-specifics, qualitatively different
stuff, not just configuring and tweaking with
the same old interface!
<http://user.it.uu.se/~embe8573/fps/>

> This argument doesn't fly with users, because
> newcomers usually need just one language, but
> they need a good support for it. They will go
> away if we don't have it, and telling them we
> support a dozen others will not make them
> change their minds.
>
> To keep Emacs alive and kicking for the
> observable future, we need to be sure we will
> have enough developers and contributors.
> And since developers and contributors start
> as users, we want to attract new users. If we
> fail to attract them, we will quite literally
> lose our future.

OK, good point.

>> I never used those tools so I don't know
>> what I'm missing. Programming in Emacs I've
>> done in some 20ish languages with no
>> problems - not form Emacs, at least :)
>> 
>> Sure, I didn't do it with a deadline, a 40+h
>> a work week, a deadline, and a I don't know
>> how many digit salary. And this is probably
>> part of the difference.
>
> I think a more important factor is the size
> of the project you work on.

Well, obviously you worked on much bigger
projects than I, but I did a university project
(check out the URL in my signature). The report
- compiled LaTeX and Biblatex, which I wrote in
Emacs - is 153 pages. I used C++, Lisp, zsh,
gnuplot, groff, and pic(1), and wrote all of
that in Emacs. Even the Makefile and several
textfiles :)

So how large should a project be before Emacs
becomes insufficient? A Quake? If so, then no,
regretfully I wasn't part of the team...

-- 
underground experts united
http://user.it.uu.se/~embe8573