Han-Wen Nienhuys <hanw...@gmail.com> writes:
> On Tue, Jun 5, 2012 at 3:57 AM, David Kastrup <d...@gnu.org> wrote:
>>>> I'm wondering, do you think that learning a new language such as scheme
>>>> would scare you away from hacking on LilyPond, if you discovered it?
>>>
>>> As long as you seek out new technologies, you'll always get new
>>> perspectives on programming.
>>>
>>> I, like most people, have only a limited amount of time. Learning a
>>> programming language well enough to write code that sticks to wall
>>> when you throw it, is a significant investment, and if there is a
>>> choice, I'd invest in something that will pay off beyond working on
>>> LilyPond. Scheme has very use in any context, so it's not very
>>> attractive.
>>
>> Emacs Lisp has very little use outside of Emacs. TeX has very little
>> use outside of TeX, and is total crap as a programming language (much
>> less consistent and predictable than, say, m4, let alone Scheme). Yet
>> Emacs has created a blossoming package ecosystem, and LaTeX has sprouted
>> an enormous package ecosystem, whereas plain TeX has remained a
>> disconnected toy field for tinkerers.
>
> It's interesting that you should note emacs and latex as successes.
> To me, emacs-lisp yet another idiosyncratic language that I can't be
> bothered to learn.
The point is that enough people could be bothered, and that the results
of people bothering have been able to accumulate into an ecosystem that
is reusable without requiring you to touch the inside of files.
> Also, my experience of latex is not as rosy-colored as yours. I've had
> to deal with plenty of packages that could only work if \makeatletter
> was inserted in the correct random place.
Which means exactly that you tried _reusing_ their code instead of
_using_ it in the intended way. That is, you treated LaTeX as a snippet
database rather than a function library. A successful software
ecosystem can serve _users_, not just scavengers.
LaTeX's modularization is something you can poke a stick through in
gazillions of ways, but the basic feature that you use
\documentclass[options...]{classname}
and
\usepackage[options...]{package}
to call upon functionality and mostly get it, in a way for which some
reasonably standardized documentation is available, is there.
Emacs Lisp is worse with a plethora of (require ...) or (load-file ...)
or whatever declarations, and with (define-custom ...) and friends. But
you'll find the necessary invocations at the top of the file. And you
don't need to touch the file and/or copy more than the invocation.
This is adhoc (and frankly crap) modular at an even less standardized
level than TeX/LaTeX, but the language compensates for that because it
is, while idiosyncratic, three levels of crap above TeX and actually
maintained for its purpose (TeX was only ever intended to provide enough
typesetting and programming functionality for the purpose of putting
"The Art of Computer Programming" through its second edition in good
style in spite of being typeset by computer).
> Anyway, this discussion is veering off from my original point, which
> was to not go overboard on Scheme, as there are fewer people that can
> write it.
The point is that your original point is not all that relevant for the
question of being able to build, support and grow a functionality and
user base with a chance of prospering without permanent upstream feed
and care.
Scheme is a much better starting point for that than what others have
been shown to be able to work with successfully. We just need to get
our act together instead of restarting with the favorite language of the
day and still without a plan.
LilyPond is not designed to be extended, and picking a different
extension language will not magically change that. Scheme/Guile is more
than good enough, and certainly quite better than C++ for that purpose.
But as long as we don't provide a working extension framework based on
the extension language, we don't get an extension ecosystem.
If LilyPond were done in a modular and extensible manner, something like
balloons would be implemented in one load-on-demand Scheme file defining
its music functions (user interface), its events, its grobs, and its
typesetting, where at least the typesetting could ultimately be
optionally be done in a separate C++ file loading standard LilyPond
headers and using a standard API, compiled to an on-demand loadable
shared object.
The C++ angle is by far the most troublesome, and it will "only" be good
for a constant factor usually. With a good set of primitives available
from Scheme, you can cut the advantage of using C++ for some level down
to a level where it is feasible to just don't use it for extensions.
I've been working on the parser a _lot_, and the main point was the
ability to move basic functionality _out_ from it and into music
functions. You likely don't see a point in that since you consider
C++/bison a nicer language than Scheme. But it is not user-serviceable.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
