Re: improving LilyPond useability

[David Kastrup]

renato <address@hidden> writes:

> Hi, I feel like you misinterpreted what I'm saying. All the things you
> say are good of course: sensible syntax, good "getting started"
> documentation, templates, not exhausting the user. I'm not saying you
> should purposefully make lilypond obscure, just saying that you should
> not encourage people not reading the docs, i.e. hiding complexity.

I come not to hide complexity but to abolish it.

> I feel that many WYSYWIG editors try to make complex things easy, and
> that's usually impossible by definition,

No, it isn't.  The definition of "complex" is

>From The Collaborative International Dictionary of English v.0.48 [gcide]:

  Complex \Com"plex\ (k[o^]m"pl[e^]ks), a. [L. complexus, p. p. of
     complecti to entwine around, comprise; com- + plectere to
     twist, akin to plicare to fold. See {Plait}, n.]
     1. Composed of two or more parts; composite; not simple; as,
        a complex being; a complex idea.
        [1913 Webster]
  
              Ideas thus made up of several simple ones put
              together, I call complex; such as beauty, gratitude,
              a man, an army, the universe.         --Locke.
        [1913 Webster]
  
     2. Involving many parts; complicated; intricate.
        [1913 Webster]
  
              When the actual motions of the heavens are
              calculated in the best possible way, the process is
              difficult and complex.                --Whewell.
        [1913 Webster]
  
     {Complex fraction}. See {Fraction}.
  
     {Complex number} (Math.), in the theory of numbers, an
        expression of the form a + b[root]-1, when a and b are
        ordinary integers.
  
     Syn: See {Intricate}.
          [1913 Webster]


The main thing to note here is "involving many parts".  The art to
mastering complexity is then to have the complexity of a solution
cleanly decompose into simpler parts, with a large preference to have
this decomposition occur along the same lines that would be used to
break the complexity of the _problem_ into parts.

"Here is some feature/trick which you can use for tackling an actually
dissimilar problem" may save your ass sometimes, but if you save too
many asses, feeding and accommodation may become problematic.

Programmers are a bit like mathematicians at heart: if a problem has a
demonstrable solution, it is no longer interesting and they move on.

Which is bad: a proof of concept is not a substitute for a concept.

> so you end up sacrificing flexibility for the sake of making a good
> impression on users. I would like if lilypond never went down that
> path.

Oh, LilyPond is a dragon anyway.  But there is a difference between a
lazy spiteful steed that will only work given no alternatives, and one
that is one with its rider and eager to soar the skies in a union of
minds.

Yes, there will always be a "beware of the dragon" warning to heed.  But
in the end, the thing we are aiming for is "enjoy the power of the
dragon and become one with it".

> But that's just my opinion, I'm not a developer nor a professional
> (not even amateur) musical typesetter, so I'll just shup up now :=)

Your opinion is, of course, not wrong as such.  But it can benefit from
some seasoning.

-- 
David Kastrup