Re: Is Elisp really that slow?

[Ergus]

Hi,

Sorry I lost the most recent messages because the mail engine disables
my account very often.

> 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.
Not only that, see below.
> (Maybe MS IDEs can do all of C#, VB(A), and
> MS Access now that I think about it...?)
Yes they can, VS code supports many of them, butt especially the most
popular.
> 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 is something even advanced compared to a real integration we need
like unify commands bindings, interfaces and functionalities names.

I go every time to the same topic here, but all the time I only receive
complains and strong answers with strong feelings from the older
users. We NEED to update the interface (unify the bindings for all the
languages, unify packages with similar functionalities, delete unused
functionalities.) It is not a should, it is a must. 

To mention just one example: It does not make sense that C-c C-c
comments the current lines in C-mode, but sends the current sexep to
terminal in other modes, or send the messages in others. So emacs
somehow behaves as a different tool/editor for 3 different modes, so the
"unified bindings/behavior" is not an advantage anymore.

Or that we provide several options (or packages) to add parents with 300
customizable variables but a very bad default behavior. The existence of
spacemacs ergoemacs and other similar customization is a user's scream
for better defaults (I am not telling to ennable all what spacemacs
does, but we have functionalities that the users will never discover if
they don't go in the ddeep parts of the manual).

Usually the old users (who deserve the legacy behaviors), are also the
most skilled ones, so it is easier for them to add some lines to their
config, than for new users that we don't want to scare the first day
with Lisp.

> > 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.
Sometimes new users also mix languages, but the worst supported ones are
the newer languages (Lua, Julia, Ruby, Python, C++ 11+, Rust) Which are
also what they need more often.

> > 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.

But also there is the fact that we are spending a lot of
effort/work/manpower in specific use cases and fancy functionalities
(web browsing, pdf reader, image shower) instead of looking and
prioritizing the general and basic editor functionalities (faster
movements commands, default bindings for comment/uncomment, select whole
line, infrastructure performance). So going to the specifics instead of
the generals.

AFAIR emacs started (and became popular) cloning the popular
functionalities in other editors and making them accessible with simple
macros. 

We just need to open sublime or athom or VS code and look all the
functionalities they provide for EDITING TEXT 2 clicks (or key binds)
far. That's the real reason of their success. Basic functionality out
of the box.

What happens now is that if a user wants a simple editor with
indentation support and syntax highlight for multiple languages, they go
for vim (it is there already, is small and has many commands for editing
text quickly, and the learning curve is similar than for emacs and much
faster/responsive). Else, if they want something advanced, then they go
for an ide or a simpler (more familiar) editor that they can start using
without reading or configuring anything, geany, athom, sublime, visual
studio code. But if the project is big with autotools or cmake they just
go for a bigger ide like kdevelor, qtcreator, eclipse, NetBeans with a
better autocompletion, debugger, compiler, packer.

Lets say for example: sublime is extensible with a simpler language
(than (lisp)) that many people use these days, it is pretty by default,
and supports many languages. It works good enough, the code is on
github, the issues, pull requests and collaboration in general is
without an arcane mailing list, and a familiar fork-joing approach. So
from the point of view of a 20 yo developers "why to us emacs?" (It is a
rhetoric context question, please don't reply to it in your answers)

So the good thing is that emacs can provide all this, but is doesn't to
have all that working it needs years (literally) of
configurations/packages. Is that what a user will chose having easier
alternatives?

> 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...

The problem is that (in my opinion) we lost the center of what emacs
should be and where are the practical-sustainable-maintainable limits a
long time ago (the difference between "we can" vs "we should").

The program grow an grow and grow and the
unused/old/substituted/unsuccess functionalities weren't deleted.

(We added the GUI over the TUI mixing everything and adding support for
every single detail we could imagine, multi os support forced to
implement everything generic.) And as a plus the Elisp language and
interpreter, two more things to maintain and update.

To maintain-support all that with (every time) less people, we have
abandoned (not improved) the editor-ide functionalities, and the world
continued moving in the mean time. (Also some needed changes have been
delayed and arrived veeeery late because "we shouldn't convert emacs in
the other editors" or similar opinions.

So, as usual in technology, other products filled the hole thinking in
the final user and not in the developers. So, in spite of our product is
better we don't find users for it because we don't know how to present
it to the new market.