[PD] style guide idea: [send foo] versus [; foo(

[Jonathan Wilkes]

--- On Fri, 3/20/09, Hans-Christoph Steiner <hans at eds.org> wrote:

> From: Hans-Christoph Steiner <hans at eds.org>
> Subject: Re: [PD] style guide idea: [send foo] versus [; foo(
> To: "dmotd" <dmotd at gmx.net>
> Cc: pd-list at iem.at
> Date: Friday, March 20, 2009, 5:25 PM
> I am not proposing to limit the use of dollar args in
> message boxes for dynamic sends, that is a very useful
> feature. The example you give here, though, is an example of
> a shortcut for typing, there is no other benefit that I can
> see.
> 
> And at the risk of sounding pedantic, I am going to quote
> one of my favorite ideas relating to code: "Programs
> should be written for people to read, and only incidentally
> for machines to execute".  Typing shortcuts like this
> message box below almost never save time when you look at
> the whole picture.  Code is read far more times than it is
> written, so really we should be optimizing for reading
> rather than writing.

Could you give an example that is more readable than the message box below?

-Jonathan

> 
> In Pd, [trigger] is the central mechanism for specifying
> execution order.  Therefore, in the interest of readability,
> [trigger] should be used as much as possible.
> 
> Clearer documentation of the messages boxes would also be a
> great thing.  But you almost anything without ever using a
> semi-colon in a message box, they are mostly used as a
> typing shortcut, and many people are confused by them, so I
> think we should really be limiting them to things like
> dynamic sends, since that is hard to do in other ways.
> 
> .hc
> 
> On Mar 20, 2009, at 1:32 AM, dmotd wrote:
> 
> > hmm.. generally this could be a good idea, but message
> sending is most useful
> > when initialising a number of receives ie:
> > 
> > [loadbang]
> >  |
> > |; init-1 6          /
> > |; init-2 symbol foo |
> > |; init-3 -2         \
> > 
> > which is far more elegant than the the trigger/send
> replacement, especially
> > with more fields..
> > 
> > i think its important for students to recognise that
> this feature of messaging
> > has a role to play, rather than trying to veil its
> use. in my experience
> > people will tend to use [send foo] more often when
> they start pd, then begin
> > abbreviating to [s foo] before they appreciate the msg
> shorthand [; foo[. but
> > you are right it is a little confusing for new users..
> > 
> > perhaps this just needs clearer documenting? 'what
> does a semi-colon at the
> > start of a message mean?' in the FAQ?
> > 
> > dmotd
> > 
> > On Friday 20 March 2009 10:38:06 Hans-Christoph
> Steiner wrote:
> >> Here's something that I'd like to propose
> for the style guide, based
> >> on my teaching experience:
> >> 
> >> - use [send foo]  instead of [; foo( for all sends
> that aren't
> >> dynamically set
> >> 
> >> A lot of people find the [; foo( syntax confusing,
> and since it is
> >> commonly used, it often gets in the way of newbies
> understanding the
> >> patch.  While the [; foo( syntax is definitely
> useful for dynamic
> >> sends, I don't think there is an advantage to
> using for the regular
> >> sends.  So for example:
> >> 
> >> [dsp 1(
> >> 
> >> [send pd]
> >> 
> >> instead of
> >> 
> >> |;                /
> >> |pd dsp 1 \
> >> 
> >> This change highlights the dataflow aspect of the
> messages over the
> >> text-style programming with syntax of the message
> box.  At the very
> >> least, I think that the help patches should use
> this style, and I have
> >> started to use this style in my regular
> programming and it feels quite
> >> natural once you are used to it.  I find it easier
> to read.
> >> 
> >> (as for [s foo] versus [send foo] that's an
> issue I want to avoid in
> >> this discussion).
> >> 
> >> .hc
> >> 
> >> 
> >>
> ---------------------------------------------------------------------------
> >> -
> >> 
> >> The arc of history bends towards justice.     -
> Dr. Martin Luther
> >> King, Jr.
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Pd-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> > 
> > 
> > 
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> Programs should be written for people to read, and only
> incidentally for machines to execute.
>  - from Structure and Interpretation of Computer Programs
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list