Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

On Thu, Sep 20, 2012 at 11:56 AM, David Kastrup <address@hidden> wrote:
> 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 apologize.  My reply is:

1) i agree that changing CamelCase to dashes won't solve the problem.

2)

> 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,

you mean that we could change different naming styles that GrobNames,
property-names and Engraver_names have?  So that all of them would be,
for example, in CamelCase?  I think doing so might be a good idea - i
remember it was very confusing for me when i was a beginner.

> unlike the pure lower/uppercase
> distinction we actually use for Grob and Context names).

I'm not sure i understand - you are referring to the fact that
lowercase strings are note names, while upper case denotes Grobs and
Contexts?  Or that grobs and contexts differ in case somewhere?

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

Sure, we shouldn't set goals without looking at how the existing and
developing code base and its underlying design will support them.
However, apart from GLISS' general goal ("let's improve the syntax") i
don't remember any specific goal that was actually set, nor any
decision finally made.  Maybe i overlooked something - can you point
me to some goal that was set already?  All i see is a lot of pondering
about ideas, in a "what about doing x?" manner.

> For me, one of the pillars of userfriendliness is
> coherence of design.  When a user is able to predict how to do
> something.

+1

> If programmers are not supposed to participate in the design
> process,

Are you referring to Graham's suggestion that you should not bother
about current GLISS discussions?  Or something else?

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

indeed, that is bad.

> "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 changingfirst iterations and will
> presumably pass into LilyPond silently once nobody can think of
> something to particularly dislike).

i apologize for not participating in that discussion.

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

ok, this is a valid observation: most of our changes are not a result
of any plan.
Another observation is that we don't have many plans at all.  Maybe if
we had some, the work would be done according to them.
And if we want to have plans, we need discussions first.  Of course
these discussions cannot be detached from the realities of both our
code base and worker base.  Nevertheless, i prefer this workflow:
1. some random discussions
2. discussions get focused on some areas/issues
3. a general vision of what is needed appears
4. some details are discussed to ensure that different areas will play
together well
5. a big plan emerges
6. things are done according to the plan

to this one:
1. someone looks at something that is wrong now
2. he discusses with others how to fix it in a way that fits current codebase
3. he fixes it
4. goto 1

In other words, i prefer to spend a lot of time talking and have a big
picture of what needs to be done, rather than not spending time on
talking and not knowing everything that needs to be done.
I just want a map with the whole route shown *before* i start the
engine of my car.

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

I'm not yet sure what to do about this.
Also, i don't have a feeling that current language discussions are
really totally detached from current development.

cheers,
Janek