lilypond-user
[Top][All Lists]
Advanced

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

Re: Scheme syntax vs. other languages


From: Jonathan Wilkes
Subject: Re: Scheme syntax vs. other languages
Date: Sat, 9 Jun 2012 14:23:58 -0700 (PDT)


> Message: 4
> Date: Fri, 08 Jun 2012 18:13:40 +0800
> From: James Harkins <address@hidden>
> To: address@hidden
> Subject: Re: Scheme syntax vs. other languages
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=US-ASCII
> 
>>  > D is obviously the wrong fit for an lp extension language, but scheme
>>  > has a couple of strikes against it right from the start.
>> 
>>  Sure, it requires getting into.  Not that D doesn't.  The rules of
>>  Scheme syntax can be learnt in one afternoon.  The syntax may not
>>  exactly resemble mathematical notation or plain language, but it is
>>  simple and regular.  If we were out for natural language, our extension
>>  language for LilyPond would be COBOL.
>> 
>>  Scheme has a low lexical and syntactical impact, and the price for that
>>  is a uniform syntax, and a uniform syntax has few structuring visual
>>  elements.  One payback for that is that you can do syntax
>>  transformations in a predictable and reliable way.
> 
> I'm certainly in no position to argue for another extension language for LP 
> -- just saying up front that isn't the purpose of this e-mail. Just throwing 
> an opinion into the pot.
> 
> In my SuperCollider work, more and more I prefer a coding style that favors 
> legibility over concision. Many people use SC for live coding, where 
> concision 
> is more important -- you have to be able to type the code FAST in front of an 
> audience. As a result, SC is full of syntax sugar, some of it quite lovely, 
> some 
> of it obscure. You can create a new array with 10 random numbers concisely 
> like 
> this -- { rrand(1, 10) } ! 10 -- but lately I prefer to write the more 
> "canonical" syntax Array.fill(10, { rrand(1, 10) }). Someone 
> unfamiliar with SC can make a reasonable guess what Array.fill does, but ! is 
> opaque.
> 
> I find scheme to be impossible to read without an editor that highlights 
> matching brackets. I can start to make sense out of it once the editor shows 
> me 
> which () belong together. That's an obstacle -- it pushes learning lisp into 
> the category of Things I Really Ought to Do Someday If for No Reason Other 
> Than 
> Building Character. I may yet do that for LP and/or Emacs, but it's 
> intimidating -- and if it's intimidating for me, I expect it's more so 
> for other LP users.


There's a distinction to be made between Lilypond's core philosophy and those 
of 

the sound tweaking environments of SC, PD, ChucK, etc.  Lilypond is supposed to 

tweak so that the user doesn't have to.  If a user in Pd or SC continually 
posts to the 

list asking for solutions because they don't understand core programming 
concepts

they will (hopefully gently) be pushed toward documentation 

that educates them on how to _program_ what they want based on a better 
understanding 

of the language.  Granted Lilypond users must understand core markup to make a 

score, but if they are pushed toward learning Scheme _programming_ concepts in 

order to get a good looking score it's a breach of the core philosophy.  
(Unless of 

course what they want to notate is so obscure or difficult that tweaks are 
inevitable, 

but even then Lilypond devs are really good at providing proofs of concept for 
weird 

things like systems that go in a circle and other crazy stuff.)  That holds no 
matter what 

the extension language is.

The affected group here is the above-average users who want to become Lilypond 
mavens.  
I don't know how to measure the trade-off between changing the language in the 
hopes of 
easier future extension development and sticking with what's already there.  
Personally I 
find Scheme really hard to understand, and I understand some C, Perl, Tcl, and 
a few others.  
But I don't think my opinion matters because I shouldn't _need_ to do much of 
anything with an 
extension language directly.  I'm going to take advantage of whatever is here 
on the list, the 
snippets, and in the docs and stick to doing what Lilypond claims I should be 
doing-- entering 
the content of my piece in markup.  I think I'm like most users, and it should 
be taken into 
account that if the extension language does change, or gets improved to become 
more 
expressive, we're not going to care until those changes eventually make the 
common tasks 
of entering musical content easier.

This doesn't go at all toward one solution or the other, but it does strongly 
point to this being
a dev issue and not a user issue.

-Jonathan



reply via email to

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