lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheme pattern for retrieving data in objects


From: Luca Fascione
Subject: Re: Scheme pattern for retrieving data in objects
Date: Sat, 2 Apr 2022 15:55:47 +0200

I can see this happening, I thought a bit about it and it seems to me there
are several factors that are potentially at play here:

 - one is how much alignment there is between the API presented to (or
rather, *perceived* by) the user vs their mental model of what is going on
in the program: the more distant these two are, the harder a time the user
will have, and whatever can be made to reduce this gap will feel good to
them. Besides, I'd imagine for most people the library shipped with
lilypond is at least one step removed from their problem space and
vocabulary, and the intervening adaptation layer is likely to feel like a
burden to people. I guess I'm saying that it seems to me lilypond is a bit
like plain TeX and there are many folks that find a layer like LaTeX is
better aligned with their mental models and how they prefer to reason about
their content

 - I'm unclear how technical or interested in coding the lilypond userbase
is: it seems to me that all folks that come to lilypond because the sheets
look great are not necessarily inclined to learn how to program to achieve
their goals, they're after the goal, and the software engineering aspects
of this provide no joy to them. Again, you see something similar in
TeX/LaTeX users as well

 - I myself still find scheme weird: this seems to be largely because it's
just different from everything else I'm familiar with both from a "look"
perspective, but much more importantly from a semantics perspective. I am
aware that as a descendent of Lisp it predates a lot of the common
languages of today, and in a number of ways it's rather more elegant and
better conceived as a language, I am just stating that it's *different*. I
happen to be a very driven person, so I'll muscle through that to get to
the sheets and sheet-making process I want, but I don't know how many other
people have a taste for this or find it enjoyable, I'd imagine most folks
just find it annoying instead. And especially for folks that do this
outside of their work time, being impeded in one's goals for reasons that
bring along an advantage that one may not find material, is unlikely to
feel like a good state of things. Point being: scheme is very different,
and occasionally very subtly so, from languages like python, ruby,
javascript and all the everyday, garden variety stuff folks are likely to
see at work, I don't know how many people will find this as positive trait,
vs how many would find it an undesirable state of things

I totally see wha Han-Wen is saying and I agree that a lateral-shift kinda
thing is not going to be that useful in the long term. However I wrote this
to express why I don't think all these changes necessarily belong in that
category, I see clear cases where plenty of value is provided to users
instead.

Luca


On Sat, Apr 2, 2022 at 2:50 PM Werner LEMBERG <wl@gnu.org> wrote:

>
> >> Over the years, I've become extremely wary of syntactic sugar: it
> >> adds an extra barrier to usage/development because everyone not
> >> only has to learn Scheme, they also have to learn the (lilypond
> >> specific) idioms involved.
> >
> > I'm curious you say that, since my experience is precisely the
> > opposite: I've had far better results "selling" Lilypond to people
> > using syntactic sugar than basically anything else I can
> > identify. The people I’ve "converted" all want to be able to type
> > things like
> >
> >    \reverseMusic \foo
> >
> > rather than learning how to write the equivalent function in
> > Scheme. In other words, syntactic sugar keeps them from learning
> > Scheme as opposed to having to learn it.
> >
> > Am I missing something? Is my experience unique?
>
> No, your experience is not unique.  I think that developers and normal
> users (but probably not Scheme wizards) have rather diametral views on
> this topic.
>
>
>     Werner
>


-- 
Luca Fascione
Distinguished Engineer - Ray Tracing - NVIDIA


reply via email to

[Prev in Thread] Current Thread [Next in Thread]