Re: [GLISS] - alternative viewpoint

[James]

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.

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

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

>
> Fourth, Scheme is not case-insensitive.  Should everything starting
> with `#' be case-sensitive then?  Otherwise we couldn't fully access
> our own extension language.

So what?

I am not typing Scheme I am typing \mycommand. What is Scheme anyway?
Where do I find that in the Learning manual?

I came to use lilypond to write music scores not to learn or care
about programming.

Also:

On 15 September 2012 11:19, David Kastrup <address@hidden> wrote:
> "Phil Holmes" <address@hidden> writes:
>
>> ----- Original Message -----
>> From: "David Kastrup" <address@hidden>
>> To: <address@hidden>
>> Sent: Saturday, September 15, 2012 9:20 AM
>> Subject: Re: [GLISS] - alternative viewpoint
>>
>>
>>> "Phil Holmes" <address@hidden> writes:
>>>
>>>> And getting rid of case-sensitivity in a lot of this?
>>>

>>
>>
>> \new Staff works.  \New staff doesn't.  There's no reason for that -

[user-not-developer]; That's right!

>
> There is actually a reason for that.  Staff, as a context name, is a
> container for properties, and things like Slur, as a property name, are
> also principally containers for properties.

[user-not-developer]; huh?

[James] And there is the problem in a nutshell - not that that is
David's fault, but this is getting Kafka-esque (or Beckett depending
on your 'Absurdist' of choice).

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've refrained from really joining in with this whole debate because
of the way the discussions _always_ get twisted and turned about to
what can seem to a user-not-developer  a conversation that's seemingly
an I-know-more-than-you or
I-can-think-of-really-special-cases-better-than-the-next-person,
instead of actually wondering why the original suggestion was made in
the first place by the 'rest of us'.

Like Phil has said, he doesn't care whether a command is \foobar and
gets changed to \barfoo. Users are quite resilient they shrug and go
on about their lives as long as it is documented and they have some
way of getting their old scores to work with the new version of
whatever is decided - THAT is probably more important to users than
much else. Those that say 'but what about my custom function in my
scores will no longer work' - well that is acceptable to a user, it's
called a 'hack' in my world, that is why the LSR is not documentation.
Those are hacks. Clever hacks, but hacks nonetheless and they have no
business of holding back development (syntactical or otherwise), I've
had to put up with nonsensical commands, why can't developers change
their ways too?

David made a good explanation about 1% of users on the list vs the
rest who use the product so I know he understands, but I don't see any
point whatsoever in joining in (other than this once) because it just
turns into why something is 'bad' rather than a 'ok, I get that, it
won't work because of [simple explanation] but how about this
[alternate suggestion] but without the need for arcane descriptions
and not because why something won't suit some other developer's
work-flow or because many years ago they decided to use a load of
'scheme' functions that now won't work (and frankly were never
guaranteed to work for ever as syntax simplifies/changes/deprecates
(Guile or python are two my limited understanding can comprehend on
this list))

> There is a convention to
> uppercase them in order to distinguish them from other elements.  When
> writing things like
>
> \layout {
>   \context {
>     \Staff
>     \override ...
>   }
> }
>
> calling the identifier \Staff for copying an existing context definition
> is not syntactically different from calling any other kind of identifier
> including functions.  We use the uppercasing here in order to establish
> some kind of namespace.

That is utterly meaningless to a user.

>
> The one consequence that I find actually annoying about that is that we
> have the semi-equivalence of \score with \new Score, and that is indeed
> less than pretty.

and why did that happen?

>
>> we don't have two separate \new \New commands that do different
>> things, nor two contexts Staff and staff that are different.

Phil's point I think.

>
> But \Score and \score which are entirely different things (the latter is
> actually a reserved word, so they can't really be merged).

Again why did that happen and why cant that be changed - actually I
don't care - but maybe there is no reason for this and this could be
something that this discussion shows up for a valid

>
>> Worse is that \slurUp works but only with that precise casing.
>
> Given that it works on a grob called Slur, I agree that some of the
> consequences of our naming schemes are not necessarily fortunate.
> \upSlur would fit better into the schemes,

To a user it wouldn't be a change it would be stupid, the user doesn't
want to remember 'case' so why would swapping it around help?

> but I don't fancy its
> grammar.  In practice, \voiceOne and \voiceTwo are more often than not
> the saner choice (as they make for more consistent results usually since
> the user often forgets to include the more obscure *Up/*Down commands),
> or using ^ and _ on individual slurs (since it is rare that you actually
> want to direct only slurs but nothing else for longer passages).

Again, no one is addressing case here we're digressing (again) as far
as I am concerned.

>
>> TBH this specific one doesn't cause me worry, since I remember it, but
>> there are much more arcane casings that I have to refer to the manual
>> to find - so I can remember the command, but not the casing!  From a
>> user perspective, it would be much simpler if everything they write
>> was ToLower()-ed before further processing.
>
> With the current design, it is not as simple as that right now.

Ah hah! A simple explanation I understand.

> Of
> course, there is the standard argument (known from filesystem
> discussions) that lowercasing is not a well-defined operation since some
> people expect \lowercase{I} to be {i} and some expect it to be {ı} and
> \uppercase{i} to be either {I} or {İ}.

Again something I understand. Go me!

>
> As long as we allow arbitrary utf8 characters into identifiers, that is
> not an entirely hypothetic consideration.

Oh dear... lost again. Sorry.

If we cannot even have a sensible and simple discussion about upper
and lower case commands - no I don't care how non-trivial it is or not
 or the historical reasons why we used some special case for Score or
score - then frankly I cannot see anyone ever making a decision on
anything. If you want to lambast me about some historical reason or
how technically 'something or other' is when trying to differentiate
upper and lower case then fine, just don't justify with arguments like
'programmers don't do that' or 'we've always done it like this' -
users don't care.

That's why I don't enjoy these discussions and after this missive will
no longer participate in it, it isn't because I am thin-skinned
(believe me I am not), it's because - like I have said before - this
discussion perceptionally seems to be run by devs for devs and more
specifically for dev's own personal scores and workflows.

Trevor more than eloquently put forward that most of this stuff is not
what users want or care about a week ago.

Users are ready to accept change, it seems that many developers are
not or are too blinkered or half-empty to even want to understand why
something is discussed, instead its taken as a personal affront to
them or their code.

That gets us, as is patently obvious here, nowhere.

James