lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheme syntax vs. other languages


From: David Kastrup
Subject: Re: Scheme syntax vs. other languages
Date: Sun, 10 Jun 2012 00:03:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Jonathan Wilkes <address@hidden> writes:

> This doesn't go at all toward one solution or the other, but it does
> strongly point to this being a dev issue and not a user issue.

It depends on whether you consider the distinction between "dev" and
"user" to be branded on people's foreheads.  Then you can state things
like "to extend, you should be able to recompile", but even with the
most caste-conscious division between devs and users, this does not work
as a community concept: because then the devs will not be able to help
individual users with code snippets, when the latter can't compile them.

In LilyPond, the Scheme reader and interpreter is just a # away.  The
line between LilyPond users and people extending LilyPond with Scheme is
much more fuzzy and gradual than the line between those extending
LilyPond with Scheme and those doing it with C++.

Most of the proposals about juggling extension languages are focusing on
the C++/Scheme border.  That's not the important one for the community
aspect.  At least not its details, but rather how far away from the user
you can push it by extending the reach of Scheme.  The important border
is that between LilyPond and Scheme.  Here is where empowerment of the
user happens.  Or not.

If poeple have some "that looks straightforward enough" experience and
manage to make small adaptions, they are on a good road.  "You are
missing a semicolon" is something that can't happen with Scheme.  As
long as you can keep your parens matched, there are not many syntactical
surprises regarding copy&paste of Scheme code.  There is not much in the
line of block structure, declarations, interface definitions, headers
and so on.  "Oh, this needs to be executed as part of a function" is
rarely a consideration.

People use more Scheme than they probably realize, and getting Scheme
help by "devs" tends to work mostly unspectacularly.  That's really not
something one can take for granted in general concerning extension
languages.  That does not mean that it can't be improved.  But it is
easy to underestimate how much work it would take to arrive at net gains
from a language/architecture switch.  I don't think that the situation
is in a state that starting from scratch would make a lot of sense.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]