Re: [GLISS] - alternative viewpoint

[David Kastrup]

James <address@hidden> writes:

> Hello,
>
> On 15 September 2012 13:55, Werner LEMBERG <address@hidden> wrote:
>>
>>>> I'm strictly against case-insensivity.
>>>
>>> And I and others are for it.  Could you state your reasoning,
>>> please?  I've already stated mine.
>>
>> First, it is confusing.  Virtually all programming languages of today
>> (and lilypond's input code resembles that) are case-sensitive.
>
> So what? I am not a programmer. I am a user.

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).

>> Second, as David has already mentioned, the conversion to either
>> lowercase or uppercase is locale dependent.
>
> User's don't care, I don't care. I want to not have to remember
> whether it is \Mycommand, \myCommand or  \MyCommand or \mycommand or
> \MYCOMMAND - make them all work or make one of them work.

Uh, one of them _will_ work.

>> Third, the numbers of short user-definable abbreviations gets halved.
>> Something like
>>
>>   F = \markup { "Horn in F" }
>>
>> would no longer be possible because \f is already in use.
>
> So what? You are a developer, fix that. I do want to not have to
> remember what case I am supposed to be using.

Distinguishing \f and \F while ignoring case is going to be a rather
difficult operation.  While I generally try to accommodate a lot of
"make that work" requests, there are limits to what one can achieve when
fighting not just the current code base, but rather plain logic.

> Phil (user) says why something pretty basic is flawed, David
> (developer) jumps in with a valid technically accurate, but frankly
> meaningless description to a user (can we do it or not?), next we'll
> have a 'developer-not-user' pitch in with an opinion on changing
> containers and contexts and properties and other things
> 'users-don't-care-about' and then David (developer) will reply with
> another technically accurate answer, probably with some 'arcane' (to a
> user-not-developer) reasoning, the rest of the developer-not-users all
> chime in, and the original 'problem' is forgotten as they all digress
> their way down some chain of gobbledygook that most of those who
> started to follow end up glazing over and realising that this is now
> beyond them as the conversation ends with words like 'lexer' and
> 'parser' and 'post-fix', and wonder if their contribution has actually
> been listened to. We wait a few more emails, cannot see if our
> suggestion is even being thought about or has it been forgotten - user
> leaves conversation wondering why he/she bothered.

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.

If you take a look at the "Changes" section for LilyPond 2.16, you will
find a large number of entries in the syntax department that make things
more straightforward, more consistent, more powerful, and easier to
understand.  I have been working to that end, and rather hard.

If you take a look at the feedback I received, there are a lot of users
who express their belief and trust that I am on the right track by
providing me with the financial means to continue, and that frankly
means a lot to me beyond allowing me to eat.

If you take a look at the feedback from the developers and the developer
list, you'll see that 95% of all code reviews remain without comment,
and there is basically no interest at all, either for helping with the
results, or for putting them to actual use.

Now if there is a single person working on a large and important
project, and making remarkable progress, wouldn't the normal question be
"how can we give him constructive feedback with regard to work he has
already done or is planning to do"?

But that is not what happens.  Instead the focus is on identifying him
as a member of the caste that is making things difficult, and make
things difficult for him.

If you take a look at
<URL:http://lists.gnu.org/archive/html/lilypond-devel/2012-09/msg00596.html>,
you'll see a statement like

    Yes, of course a shared project would be much easier with a
    benevolent dictator.  However, other than a few specific instances
    (such as the stable/2.16 branch), I don't think that we *want*
    benevolent dictators.  A number of people want to discuss syntax
    possibilities.

    I am not at all certain that I agree with where you see us wanting
    to go.  I *am* certain that I, and many others, have ideas which
    do not agree with where you see us wanting to go.  Most of those
    other ideas are unworkable, but until we examine each idea, we
    won't know if it is actually workable or not.

Now that is, plain and simple, negative feedback.  Creating technically
coherent and accessible underpinnings to our existing system is the area
I have specialized in, and where I have acquired and practiced
extraordinary skills.  For better or worse, nobody else has been working
in this area at all, and for better or worse, no active programmer in
LilyPond has bothered acquiring the knowledge to actually help with the
work.

It is not like I decide things in dictatorial manner like Graham
suggests: every potentially disruptive change is put up for review.  On
those involving a somewhat open judgment call rather than an obvious
improvement, I tend to _beg_, _beg_, _beg_ for feedback before finally
giving up and committing to the best of my personal design choices.

Now in this context Graham states his disapproval with "benevolent
dictators", that he does not want them in general, and that "a number of
people want to discuss syntax possibilities".  Why does this number of
people never partake in reviews?  Why don't they provide constructive
criticism on ongoing work, and instead prefer destructive criticism on
work I have not even started with and/or sketched out?

Part of the reason is that they can't.  They don't have the knowledge or
skills to provide constructive criticism.  So how else are we going to
deal sensibly with the distrust in my work and design choices and the
wish for more control over the technical process?

For better or worse, users can't sensibly dictate technical design
choices.  When they are distrustful of how their non-technical work will
get considered in the technical design, the only reasonable thing they
can do about that is become programmers eventually.  And I very much
strive to make this easier.  Not just by simplifying the programming
model.  I have redacted a _whole_ lot of the Scheme programming tutorial
and probably rewritten half of it.

I _welcome_ people making progress in being able to participate with
LilyPond development.

But while nobody steps up and actually _participates_ with the work, and
skills, and knowledge, as long as I am the only one putting work in the
parser and its technical underpinnings, there is nothing that will help
you except trust me on my judgment.

Only programmers can sensibly check the technical decisions of
programmers.  We have a review infrastructure in place to make this
easy.  The degree to which this happens (or rather does not happen) is
nothing to get excited about, but it is there and working somewhat
effectively _when_ it is being used.

But the general catcalls against every change and non-change that might
happen in future are creating a negative work atmosphere, and the basic
insinuation that everything one does is viewed with suspicion and
considered a change to the worse does not help.

I get expressions of disapproval with my dictatorship over the parser
when it turns out that I am exercising dictatorship over a populace of
one, namely myself, and put every decision up to public review.

The most _disruptive_ change (where "disruptive" means not that things
changed how they worked internally, but where preexisting programs
stopped working) I did in the context of all that parser work for 2.16
was likely issue 2240, and if you take a look in the Changes file, that
change bought a _lot_ of features (including bringing consistent
behavior to q, a feature I don't like myself, but at least I managed to
stop it from being broken by design) and is reasonably easy to work
around when previously done programs no longer behave properly.  And it
is not like we did not discuss the advantages and disadvantages for
weeks.

So all the calls for more control over work that has not even started
and that nobody else but myself is doing and that nobody bothers
reviewing when it is actually being done and that nobody bothers saying
"that's great" afterwards is really a large, large, large demotivational
factor for working on LilyPond, and without the partly monetary
expression of trust from users and my own trust in my work and myself
being _sure_ about its value, there would be really very little active
motivation to continue.

And that does not even make sense.  So please, whether project leader,
programmer, or user: consider how you can create _incentives_ for
working on LilyPond rather than focusing on _disincentives_.  Negative
feedback does not carry the day for all that long.  It is helpful to a
degree, but when it remains the only form of feedback, at one point of
time it becomes more pleasant to do something else rather than trying to
strive for the optimum of no feedback at all when there is no positive
to be had.

-- 
David Kastrup