Re: Quit [now definitely O/T]

[David Kastrup]

Continued on developer list.

Jan Nieuwenhuizen <address@hidden> writes:

> As a new contributor/developer, by using a different, and a particular
> unfriendly platform for free software development, you are faced with
> tackling several difficult problems at once.
>
> This is only meant as an observation and an apology.  Had you be 
> using a common GNU/Linux platform, installing all dependencies can
> be done in a single command that runs in under a minute on my box.

It's basically a startup investment.  Personally, I have the impression
that the current structure of C++ plus Scheme may not be the best setup
since Scheme, as the principal script language, does not have the
expressive power to work with Lilypond's internal data structures.
Taking a comparative look at C/Elisp as used in Emacs, the actual
programming is done in Elisp, with C delivering primitives and all
access to the Elisp data structures.  _If_ Emacs has the principal
capabilities for some task, you can code the whole task in Elisp.  This
does not appear to be doable with Lilypond's Scheme.  At least not to
the degree where it is the preferred way of thinking about new tasks.

At least I don't see how one can whip up new translators or context
types just writing Scheme code.

For a start from scratch, Lua would be a nice choice: message-passing
coroutines (very nice for translators keeping context!), procedural
syntax, very portable, fast.  And you can learn everything worth knowing
about it in few days.

I can actually understand and work with the Lua coroutines.  In
contrast, I am not sure that trying to solve tasks with Scheme
continuations in Lilypond will not crash down everything around you.
Pretty much all usable Scheme data _structures_, (cons cell, array),
have a non-local existence, and just the named handle to them is
actually part of the dynamic context.  So while continuations may have
well-defined semantics on the dynamic context, this does not buy you
useful semantics for the structured data you would want to manipulate in
this context.

Anyway, water down the drawbridge.

Would it be feasible to create new listeners/performers/contexts purely
in Scheme, by having generic enough C++ listener/performer/context
factories that one can fit in everything worth having by using Scheme?

Scheme might not be the nicest language for programming, but being able
to solve everything important in some application in _one_ language
without need of recompiling (or heap management) or language interfacing
would be a good step towards recruiting new programmers and solving
tasks, partly in form of libraries or packages which can be just used
on-demand rather than needing to be compiled in.

-- 
David Kastrup