Prev: New Lisp indenter for Kate
Next: 2 Articles on Continuations
From: David Kastrup on 13 Sep 2009 11:34
Evan I <tali713(a)nospam.yahoo.evar.com> writes:

> Dave Searles <searles(a)hoombah.nurt.bt.uk> writes:
>
>
>> An alternative, but much more work: port the whole thing to Java and
>> use Swing's JFileChooser for the file dialog, JOptionPane, etc. as
>> appropriate, and set system native look and feel in the startup
>> code. Only the C code has to be ported, though, not however much is
>> in elisp, since the port to Java needn't alter the elisp interpreter,
>> nor the UI fixes. Though you might want to alter the elisp
>> interpreter anyway, eventually -- you can get rid of its garbage
>> collector and have it just use Java's for an efficiency boost.
>
> Java for an efficiency boost. Yes that is a wonderful idea, move a
> super fast(by todays standard) integrated developement environment and
> text oriented OS and stick it on a java virtual machine to gain
> efficiency.
>
> Brilliant.

Not per se stupid: there is the matter of controllable complexity. For
example, recoding some program from assembler into a higher level
language might give you vast speed advantages, since the level of
complexity the human mind can hope to control in a high level language
may well be greater than in assembly language, and thus the choice of
algorithms and data structures better matched to the problem. O(n lg n)
will win out over O(n^2) pretty soon: assembly language just improves a
constant factor.

However, Emacs Lisp is rather well matched for editing tasks. Somewhat
amusingly, you'll mostly get quadratic behavior just when manipulating
its most natural data structure, the list.

But if you basically move just the Lisp engine, as proposed, indeed
switching to Jave will make things worse.

--
David Kastrup
 | 
Pages: 1
Prev: New Lisp indenter for Kate
Next: 2 Articles on Continuations