On 09/17/2014 04:17 AM, Phillip Lord wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> First, of course we can keep on evolving Elisp on its own.  This has
>> worked OK for the last 30 years, so it's not such a terrible choice.
>> The main problems I see with that:
>> - Elisp is slow and as CPUs aren't getting faster, its slowness makes itself
>>   noticed more often.
> 
> I've been going through some 10 year old elisp of mine recently. The
> thing that surprises me is how many times I mention performance in it. I
> rarely worry about this these days. Elisp performance as is seems rarely
> an issue.
> 
> Where I would say that there is an issue is that too much of Emacs is
> written in C. Having a faster elisp would allow moving more into lisp
> and thus having more of Emacs extensible dynamically.
> 
>> - Lack of some features, most notably FFI and concurrency.
>> - Lack of manpower.
> 
> I'd add a fourth. People who want to extend Emacs for their own purposes
> have to learn it. Having JS extensibility would be an enourmous win.

...until the next fad comes along, at which point JS becomes a
liability. Popular environments come and go. JS is hip now; Lua, Python,
Ruby, and lots of other languages see interest rise and fall according
to fashion, taste, and the Hacker News ranking algorithm. Who knows
which languages will be popular in a few years?

Emacs Lisp has been here and has kept almost complete source
compatibility for decades and has been completely immune to these fads.
Let's maintain this tradition.