Re: [GLISS] - alternative viewpoint

[David Kastrup]

David Kastrup <address@hidden> writes:

> Within your own scores, be consistent in your choices.  How this
> consistency looks, does not matter.  Within LilyPond, there is a large
> consistency which elements are uppercase, and which lowercase.  The one
> thing that actually gets annoying is CamelCase.  However, as a rule,
> camelcase starts with lowercase letters.  With recent changes in the
> lexer, it would be possible to replace the CamelCase words with dashed
> words.  That would allow for things like
>
> \slur-up \slur-down \voice-one \one-voice \voice-two and so on.  I am
> personally not a big fan of CamelCase.  You would, of course, get the
> same principal problem "I can't remember where and whether to put
> dashes" when making use of that option.
>
> Weeding out CamelCase would not, in itself, change the classes of things
> that we use uppercase for, lowercase for, and dashes for (there would be
> some overlap in classes since we _do_ have a few existing
> words-with-dashes and \commands-with-dashes, but distinguishing those
> classes is actually not important, unlike the pure lower/uppercase
> distinction we actually use for Grob and Context names).

Just quoting this as yet another example where I offer some concrete
suggestions in a GLISS thread with nobody bothering to even reply.

> I don't think that this characterization is doing justice to the
> developers since it basically assumes that their main incentive is
> making fun of users.
>
> Part of the reason working on LilyPond is less rewarding than it could
> be is this atmosphere of distrust, and the urge to rein in developers
> who apparently have nothing better to do than damage LilyPond.

"distrust" is maybe too strong a word.  "non-involvement" may be closer
to the truth.  Regarding the GLISS discussions and proposals in that
context becoming official project policy, participation of programmers
is actively discouraged.  Goals are being set without bothering to look
at how the existing and developing code base and its underlying design
will support them.  For me, one of the pillars of userfriendliness is
coherence of design.  When a user is able to predict how to do
something.  If programmers are not supposed to participate in the design
process, and non-programmers will not be participating in executing this
design, we get to the situation where those who have the means of
implementing a design will do this ad-hoc, stealthily, and without
communication or coordination.

"Stealthily" may seem like too strong a word, but quite a few of the
actual usability/language features are proposed and finally implemented
in the way we see in
<URL:http://code.google.com/p/lilypond/issues/detail?id=2717>.  There is
minimal feedback by few persons (this particular issue has already
gotten more feedback than usual in its first iterations and will
presumably pass into LilyPond silently once nobody can think of
something to particularly dislike).

If you take a look at our "Changes" file from 2.16 and take a look at
how many of those changes were the result from following through with
active and planned policy decisions rather than spontaneously done work,
it does not appear that our purported planning is connected much to what
actually gets done, and users could exercise more influence if they
actually commented on issues in the tracker accompanying actual work in
progress rather than participating in a hypothetical discussion detached
from the realities of both our code base and worker base.

One issue/review that recently profited a lot from interaction of
developers and users was
<URL:http://code.google.com/p/lilypond/issues/detail?id=2823> where
people cooperated in collecting and completing information, leading to a
much better informed approach to actual work.  If you take a look at
_who_ collected the various bits of information, however, you'll see the
usual suspects again: seasoned programmers, just that some of them acted
in the capacity of users in the context of this issue.

We definitely can make use of a _lot_ more of this kind of user
involvement and exchange of knowledge, interest, and inspiration, but I
don't see that the syntax discussions and decisions detached from the
actual development are facilitating this.

-- 
David Kastrup