[PD] about [prepend] on osx

[Hans-Christoph Steiner]

On Nov 27, 2005, at 4:59 PM, Mathieu Bouchard wrote:

> On Sat, 26 Nov 2005, Hans-Christoph Steiner wrote:
>> On Nov 26, 2005, at 2:59 PM, Krzysztof Czaja wrote:
>>> which is why instructions for a computer should be kept short. In
>>> Knuth's WEB there is @d, not @define, @i, not @include, etc.  
>>> Likewise,
>>> library prefix should not clutter the content.
>> Well, everyone makes mistakes, even Donald Knuth ;)
>
> Yes, and even those who write on pd-dev make mistakes sometimes !
>
>> Basically all recently designed languages encourage long descriptive
>> names with fewer symbols and more words (SmallTalk, ObjC, Java,  
>> Python,
>> Ruby, etc.).  I would like Pd to be in this camp too.
>
> The five you name are all derivatives of Smalltalk to some extent. Of  
> the
> ones you name, the most concise language is Ruby. This is why Ruby is  
> my
> favourite among those. BTW, creating a new class in Smalltalk is done  
> by
> sending this message to an instance of the Class class:
>
>   subclass:instanceVariableNames:classVariableNames:poolDictionaries:

Its usually done like this to make things clearer:

Object subclass: #MessagePublisher
     instanceVariableNames: ''
     classVariableNames: ''
     poolDictionaries: ''

> while in Ruby it's done by sending this message to the Class class:
>
>   new
>
> which one is more verbose?
>
> which one is easier to remember?
>
> which one is better for the writer?
>
> which one is better for the reader?

That's a pretty weak argument if you pull it a little snippet of code  
totally out of context.  How about a page of code side by side?


> Names that say a lot don't necessarily mean a lot, especially when  
> there
> is a lot of copies of the same long name. And then, that redundancy  
> gets
> in the way because it diverts attention away from what makes a given  
> piece
> of code unique. As Krzysztof says, the content should not be cluttered.

Writing gibberish just to fill out space would be stupid in any  
language.  And it seems that redundancy works quite well in written  
language, look at all these big words repeated again and again, it  
could be much shorter if I just abbreviated everything.  But would it  
be more readable?

>>  Many other people cannot remember very many details like all of the
>> symbols, abbreviations, etc. in C.  When I discovered SmallTalk, it  
>> was
>> an epiphany.  I could just read the code like sentences.  So I try to
>> apply that style to all my coding.
>
> But could you write the code like sentences too? How often did you  
> have to
> consult the class-browser in order to remember a name? How much time  
> were
> you spending writing code? How much time were you spending reading  
> code,
> and of that time, which fraction of it were you spending on handling  
> the
> scrollbar?

Fine questions, but when talking about time spent writing a program, I  
think they are too fine grained to see the big picture.  Ultimately,  
the question is not about how much time you spend scrolling, but how  
much time you spend till you have completed and debugged code.  The  
time it takes to write code is trivial compared to the time spent  
debugging and maintaining it.  That's why you have such practices as  
extreme programming, which actually slows down the process of getting  
the code written, but overall is much more efficient.

>> Yes, it would take up more space, but I think it would also lead to  
>> less
>> bugs.
>
> Code that takes more space is more difficult to grasp, because you  
> often
> have to scroll around, which takes more time because the eye is much
> quicker than the hand, and with equal time, it's easier to fix bugs if  
> all
> the code fits in one page.

> After all, even worse than having to remember abbreviations, is having  
> to
> remember how a big proc (or big patch) is made.

Sounds like you need a better editor, or mouse wheel support.  If space  
was at such a premium, then why do even C coders space out their code  
like this:

#define SET_INPUT_KEYCODE(dev, scancode, val)			\
		({	unsigned __old;				\
		switch (dev->keycodesize) {			\
			case 1: {				\
				u8 *k = (u8 *)dev->keycode;	\
				__old = k[scancode];		\
				k[scancode] = val;		\
				break;				\
			}					\
			case 2: {				\
				u16 *k = (u16 *)dev->keycode;	\
				__old = k[scancode];		\
				k[scancode] = val;		\
				break;				\
			}					\
			default: {				\
				u32 *k = (u32 *)dev->keycode;	\
				__old = k[scancode];		\
				k[scancode] = val;		\
				break;				\
			}					\
		}						\
		__old; })

.hc

>
> ____________________________________________________________________
> Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
> Freelance Digital Arts Engineer, Montréal QC Canada
>

________________________________________________________________________ 
____

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.
Now that he can realize them, he must either change them, or perish.
		                                                -William Carlos  
Williams