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:
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?
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.
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?
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.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada