Re: openlilylib pull request

[Jean Abou Samra]

Le 09/05/2022 à 01:59, David Kastrup a écrit :
> Simon Albrecht <simon.albrecht@mail.de> writes:
>
> > On 08/05/2022 20:37, Jean Abou Samra wrote:
> > > The case study of how OLL fell out of maintenance is one of the
> > > things leading me to think that a model where snippets providing
> > > significant functionality and becoming somewhat popular get
> > > upstreamed into the LilyPond core is a better fit for LilyPond
> > > than them letting them be provided through external packages.
> >
> > In many cases, that may be true. In other cases, it really makes sense
> > to allow for a more flexible space of user code available to the
> > community.
> >
> > The TeX ecosystem may have some issues with maintaining packages and
> > especially with interoperability, but it provides an unbelievable
> > wealth of high-quality additions to the core software that could never
> > be provided otherwise. Due to the relative lack of adoption and the
> > small size of the community LilyPond can’t seem to take some threshold
> > toward creating a similarly stable ecosystem (so far?).
> The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to
> LilyPond and LSR snippets), of the monolithic Context (driven by a
> not-much-more-than-one-man company), and of the modular LaTeX.  The only
> system that has exploded in number and functionality of extensions and
> styles is LaTeX.
>
> That suggests that the development potential is not as much dependent on
> the underlying technology but of readily available interfaces for
> integrating both functionality as well as document styles into a fixed
> framework.



I am not sure I would say that. Even though LaTeX is already
more workable than plain TeX, it quickly gets pretty limited
in features on its own, and programming it is very much not
fun at all if not atrocious. So you need packages to accomplish
about any standard task. The very quality of core LilyPond may
be the reason why packaging layers around it have failed to really
take off and LSR remains far more commonly used than openLilyLib.

Not to mention that many amazing LilyPond snippets are expressed
in less than 50 lines of Scheme code, which is just as convenient
to inline in your file than to include. I don't think the same
holds with TeX.

We need to reflect on what packaging systems bring to other
projects and what in that is or is not relevant to the LilyPond
community. In other words, we should create a packaging system
that fits a purpose. I don't believe that a packaging layer will
enable us to steal some of LaTeX's success by its only existence.

Another aspect is that TeX is frozen, and working with it
is working with a prehistoric and pitiful piece of software
by today's standards. But it's impossible to change due to
backwards compatibility (I think), so you get more and more
new competitors, each with its own incompatibilities: XeTeX,
LuaTeX, ConTeXt. Having most features baked into LilyPond's
core means we can make it evolve rather fast compared to the
size of the project. convert-ly also helps there.


Jean