Re: Code formatter

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Fri, Nov 13, 2009 at 11:23:55AM -0700, Carl Sorensen wrote:
>> Jan believes that code formatting standards should be no more restrictive
>> than the GNU standards.
>
> By the way, if somebody has a compelling argument why we should
> differ from the GNU standards, I'm willing to go up against Jan.
> But before I do that, I need to be *convinced* that the
> alternative is right.
>
>> This same issue is relevant in the discussion about going to Lua.
>> Lua is not GNU software.  It does use the MIT license, which is GPL
>> compatible, according to the FSF.
>
> That's not an issue.  The issue is that rewriting lilypond would take
> thousands of hours of work, and nobody wants to do that work.

Yes.

> Besides, I really thought that the Lua-talk was a joke.

It was a quite serious hypothetical.  "If xxx were to be started from
scratch" is rarely an option.  If you want to, take it as "if only
Lilypond had been written using Lua".  Because there are quite a number
of compelling advantages, not least of all performance.

> Some people at my university want to rewrite lilypond in Haskell --
> again, they weren't serious about it.  The notion was just a "hey,
> wouldn't it be cool if...?" thing.

This hypothetical was not "wouldn't it be cool", but rather "wouldn't it
be nice".  The Haskell rewrite sounds like potentially squeezing the
source code size by a factor of 2, squeezing the developer pond by a
factor of 20.  The Lua rewrite would likely squeeze the source code by a
similar size and double the developer pool.

Because one simple language that can be efficiently used for
_everything_ sure beats two complex languages that can only be used in
tandem for doing everything, in particular when we are talking about
efficiency.  And that's before we even take a look _which_ languages we
are talking about.

> The core developers have a better estimate of the enormous amount of
> work it would take to rewrite lilypond in lua, java, or whatever was
> being proposed.  Also possibly rewriting it to avoid using various
> libraries... so maybe re-implementing fontforge, pango, etc etc etc.

Reimplementation libraries is not an option, I think.  Lua is pretty
good for integrating libraries, and quite a number of external bindings
exist.

But the bottom line of course remains: any porting requires developers.
Another option would be to pull in Lua as an _additional_ extension
language, then move existing code in pieces to Lua.  That's the approach
that the Context/LuaTeX development team has taken.  The process has a
large "evolutionary rather than planned" taste to it.  But it shows
intermediate results that keep the motivation going.

Again: I am not proposing to actually do this.  It was just a "wouldn't
it be nice".  Not cool, nice.  Because diving into the current system is
to a large degree fighting with the implementation rather than the
implemented system.

For anybody who thinks that I am fantasizing because of some arbitrary
language preferences, I recommend reading through the "Programming in
Lua" manual for which slightly older versions are completely online.

Very worthwhile, for programmers used to _any_ language.

> If anybody has a CONCRETE proposal on how to make things easier
> for non-Linux developers... along with the manpower required to
> IMPLEMENT those proposals... I'm more than willing to listen.  If
> their proposal includes a relatively minor amount of work from the
> core developers, I'm willing to do it.  If the proposal boils down
> to "hey, how about you guys rewrite it in visual basic, while I
> continue to complain about bugs and the lack of a wiki"... then
> they won't get anywhere.

Sure.

-- 
David Kastrup