Re: Emacs rewrite in a maintainable language

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Sun, 11 Oct 2015 22:13:53 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> However, it is not absolutely necessary to have a global understanding
> >> of the module that it is being translated to the new language. Depending
> >> on the target language, a shallow knowledge can be sufficient.
> >
> > Only where the current code is self-contained, i.e. does not make any
> > serious use of system APIs and is not heavily used by other parts of
> > Emacs.
> >
> > If these conditions are false, then a fairly complete understanding is
> > in fact necessary, otherwise we will have gobs of subtle bugs on our
> > hands.
> 
> If the target language is ABI-compatible with C and hence has no
> problems calling system APIs, there is no problem with translating a
> function to that language and make it available to the
> still-untranslated functions. The calling functions would remain
> untouched until they get their turn to be translated.

I don't know what you mean by "ABI compatible".  If you mean C++, then
it's a single language (and not the best choice, IMO, as it is not
much better for Emacs than C, given its decline and problems of
finding people who know it).  As soon as you start talking about Java
or Python (fully compatible with C, btw), the issues I mentioned start
piling: you cannot transform the code without understanding what it
does.

> > Also, depending on the target language, simple 1:1 translation might
> > make no sense, because it could yield insufficient performance.  In
> > those cases, the translator will have to reverse-engineer the (largely
> > undocumented) requirements from the code, and then reimplement them
> > using more efficient primitives of the target language.  That also
> > requires a fairly good understanding of what the code does, and why.
> 
> Same as above for the performance and 1:1 translation.

Same as above for counter-arguments.

> > And these issues are just the tip of the iceberg.
> 
> I have experience doing this type of work (from C++) but the target
> language was custom-made for making the process as easy as possible
> while being advanced enough to warrant the effort. It was (is) a huge
> success.

I also have experience (converting a large project from Fortran to C).

> It would be not so easy with one of the stablished languages (Scheme,
> for instance, has all the problems you mentioned and some more.)

I think any language which is "better" (i.e. is known by more
programmers) will have the same problems.