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