Re: Is Elisp really that slow?

[Ergus <spacibba@aol.com>]

> > So... I am scared now to be sincere here...
> > but yes. That's better (and more logical)
> > than confusing and scare the users.
> 
> Again this talk about scaring the users.
> Are computer people so darn afraid and fragile
> these days? Without boasting, let me boast that
> when I started Emacs the very first time,
> I wasn't the least scared, in fact I thought it
> was awesome, including the Lisp part, and
> I have used it ever since.
> 
Times has changes, developers too, alternative software grows like
mushrooms. What we used to do exceptionally better than the rest, now is
provided more or less by many other applications. The user experience is
different now and the needs too. Projects are bigger and more complex,
they mix languages constantly (just thin in Javascript+PHP+ASP+SQL+CSS),
languages are more complex... The choice to use a tool is based on how
more productive and easy to use it is, not in how powerful it is after
3000 lines of configuration and reading 5000 pages manual and learning
another programming  language.

Also there is a baseline already that the 99% of the users are use do
things differently (copy, paste, mouse wheel behavior, rectangular
selection, save, search, undo-redo) and the users don't want (and it
actually does not make too much sense) switch to M-w C-y and so on if
they already know a method that works for their browser, their games and
their chats.

So yes, they feel scared when they type emacs and they don't know how to
exit, or how to copy, paste, or search text with C-f, or save with
C-s... Suppose that even after that they persist and after 2 hours
reading a manual and a tutorial they try to comment a line in Python
mode with C-c C-c because they saw that it works for a c program in
stack overflow, or try to copy text from the minibuffer the same way they
do in the main buffer.

The user needs to see advantage over other systems/applications to feel
attracted enough to spend the initial time that emacs requires and deall
with the uncommon issues. In 1992 there were less alternatives around
and most of them were uglier, notably more limited or most
expensive. But in 2019 there are cheaper, prettier and free
alternatives. They are not as powerful as emacs, but they are more
ergonomic and do the work and include small details to make the life
easier||simpler||faster out of the box.
> 
> > If everything is organized in advance it will
> > be, actually it may simplify and reduce a lot
> > of redundant code, reduce the manual (good
> > for developers and the users because will
> > need to read less to start working), avoid
> > conflicts in the mailing list (and
> > discussions like this). Help external
> > developers to provide better packages at leas
> > more organized and standard without conflicts
> > with the internal functionalities.
> 
> ??? All that will happen from changing a bunch
> of keybindings?

If all the section modes in the manuals could remove the repeated (non
specific) commands and bindings that now they have to specify because
everything is disordered from their sections, the modes don't have to
include the explicit binding from them, The users don't need to learn
different commands in every different mode and the packages developers
had a clear set of reserved bindings to avoid. Yes all this will in some
degree happen.

But as you can see, it is not "a bunch" of keybindings. Ans something I
am pretty sure will never happen.