hi
in the osx package (0.38-RC4) from hans, there is
[prepend] in extra folder [prepend in extra/cyclone folder
if i load cyclone library at startup, the cyclone prepend is not available
is it possible to define only one prepend object (the cyclone's one --- i prefer), or not?
best regards to all
nicolas
On Nov 24, 2005, at 4:55 PM, nico wrote:
hi
in the osx package (0.38-RC4) from hans, there is
[prepend] in extra folder [prepend in extra/cyclone folder
if i load cyclone library at startup, the cyclone prepend is not
availableis it possible to define only one prepend object (the cyclone's one
--- i prefer), or not?best regards to all
You can call it directly: [cyclone/prepend] That will always give you
cyclone's prepend. The one in extra is actually cyclone's prepend, but
for some reason, it doesn't show up with the inlet the way its
currently compiled.
.hc
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it."
- Thomas
Jefferson
hi Hans,
Hans-Christoph Steiner wrote: ...
You can call it directly: [cyclone/prepend] That will always give you
does your installer support aliases? If so, would you consider adding an alias "ln -s cyclone cc"? If not, would you consider "mv cyclone cc"? Patch space is precious, and 5 chars is a lot.
cyclone's prepend. The one in extra is actually cyclone's prepend, but
for some reason, it doesn't show up with the inlet the way its
currently compiled.
Currently, the only purpose of prepend's existence is to serve casual Pd users with a strong Max background. Prepend in Max has only one inlet (message "set" is used instead). In order to get the second inlet, one has to create a cyclone's prepend w/o arguments (which would be an invalid object in Max).
Krzysztof
On Nov 25, 2005, at 5:22 PM, Krzysztof Czaja wrote:
hi Hans,
Hans-Christoph Steiner wrote: ...
You can call it directly: [cyclone/prepend] That will always give you
does your installer support aliases? If so, would you consider adding an alias "ln -s cyclone cc"? If not, would you consider "mv cyclone cc"? Patch space is precious, and 5 chars is a lot.
If you need to save patch space, you can load it as a lib. Or if there
was a declare/using/import object that would be even better. But I
believe that abbreviations in code cause a lot more trouble than they
save. Something along these lines:
"Instead of imagining that our main task is to instruct a computer what
to do, let us concentrate rather on explaining to human beings what we
want a computer to do."
-Donald Knuth
I, for one, do not have an endless memory for abbreviations. I think I
share that trait with the majority of population. Consider yourselves
fortunate if you do have such a memory, but please humor the rest of
us.
cyclone's prepend. The one in extra is actually cyclone's prepend,
but for some reason, it doesn't show up with the inlet the way its
currently compiled.Currently, the only purpose of prepend's existence is to serve casual Pd users with a strong Max background. Prepend in Max has only one inlet (message "set" is used instead). In order to get the second inlet, one has to create a cyclone's prepend w/o arguments (which would be an invalid object in Max).
The one currently included in extra is probably an old version of the
cyclone one. It should probably be removed altogether in the future
releases so that people can easily select their preferred prepend.
.hc
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The one currently included in extra is probably an old version of the
cyclone one. It should probably be removed altogether in the future
releases so that people can easily select their preferred prepend.
In the future and on many machines already in the present people will use the builtin [list prepend], sometimes coupled with [list trim], which both were introduced with pd-0.39. The maxish-[prepend] will be an abstraction with just [list prepend]--[list trim] inside. (One of the reasons why I recommend everone to switch to 0.39 ASAP!)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hans-Christoph Steiner wrote: ...
believe that abbreviations in code cause a lot more trouble than they
save. Something along these lines:"Instead of imagining that our main task is to instruct a computer what
to do, let us concentrate rather on explaining to human beings what we
want a computer to do." -Donald Knuth
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. Its main purpose is to instruct a computer where it is supposed to look for an object's definition. For a reader of a patch "cyclone/" means no more than "nonstandard/".
I, for one, do not have an endless memory for abbreviations. I think I
share that trait with the majority of population. Consider yourselves
fortunate if you do have such a memory, but please humor the rest of us.
why the irony? I proposed cc as an option, after all. But ok, I can live without it, although it is only one little, simple to remember, hard-to-misspell abbreviation with a slight pun in it.
Krzysztof
On Nov 26, 2005, at 2:59 PM, Krzysztof Czaja wrote:
Hans-Christoph Steiner wrote: ...
believe that abbreviations in code cause a lot more trouble than they
save. Something along these lines: "Instead of imagining that our main task is to instruct a computer
what to do, let us concentrate rather on explaining to human beings
what we want a computer to do." -Donald Knuthwhich 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. Its main purpose is to instruct a computer where it is supposed to look for an object's definition. For a reader of a patch "cyclone/" means no more than "nonstandard/".
Well, everyone makes mistakes, even Donald Knuth ;). 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.
I, for one, do not have an endless memory for abbreviations. I think
I share that trait with the majority of population. Consider
yourselves fortunate if you do have such a memory, but please humor
the rest of us.why the irony? I proposed cc as an option, after all. But ok, I can live without it, although it is only one little, simple to remember, hard-to-misspell abbreviation with a slight pun in it.
Actually, I wasn't being ironic at all, but totally literal. Many
coders do have an amazing ability to remember a seemingly limitless
number of abbreviations. From my experience, these coders tend to like
C. 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.
I think that Pd also has this kind of potential. Its almost physical
nature makes it feel familiar to many people. And if the namespace
could be clean, simple, and easy to read, then it would be a much more
accessible language. Yes, it would take up more space, but I think it
would also lead to less bugs. And really, if you want very compact
code, you can load the libs, and then you don't need any prefix, not
even "cc".
.hc
There is no way to peace, peace is the way.
-A.J. Muste
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
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
On Sun, 27 Nov 2005, Hans-Christoph Steiner wrote:
subclass:instanceVariableNames:classVariableNames:poolDictionaries:
Its usually done like this to make things clearer: Object subclass: #MessagePublisher instanceVariableNames: '' classVariableNames: '' poolDictionaries: ''
Well, in Smalltalk, it's required to insert an argument after each column. And then, spacing things out doesn't make things clearer, they make them more spaced out, period. The message selector is still a 67-character symbol. It's worse than German words! (well, *most* German words, I mean)
while in Ruby it's done by sending this message to the Class class: new
That's a pretty weak argument if you pull it a little snippet of code totally out of context.
Ok, I'll give away the context now. The context is that this is one of the most important message selectors in the Smalltalk language. It's not just a little snippet of code, it's one that appears in nearly every Smalltalk source file.
And yes, that's about the worst case in the Smalltalk language. But it's not unfair, because it's also a very common case, so common that every Smalltalk programmer sees it on his/her first day.
How about a page of code side by side?
If you want to compare Ruby and Smalltalk, you may pick a page of each for the sake of your argument.
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?
As I said, each word is already an abbreviation of its definition.
Now, comparing lengths of words to each other: people invent long words for occasional concepts, and short words for very recurrent concepts. For example, the word "ich" is a lot shorter than the word "Generalstaatsverordnetenversammlungen", and that's not a coïncidence. You aren't going to make people verbosify their daily speech using the argument that "ich" is an abbreviation and so it is an evil word.
Normal daily speech is a natural occurrence of Huffman compression.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 27 Nov 2005, Hans-Christoph Steiner wrote:
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.
Right. But then you have to explain to me how writing longer words on more lines really help on the debuggability. It seems to me that debuggability is about keeping the code modularised so that not too many things are in the same context at the same time, so that programmers are less confused, so that they create less bugs in the first place, or find bugs more quickly.
The time it takes to write code is trivial compared to the time spent debugging and maintaining it.
It depends. There's more to writing code than just writing it.
Do you count the amount of time that the code matures in the mind before being dumped into the computer?
What about writing less bugs in the first place?
What counts as maintenance depends on when the original project is considered as having ended. Software engineering is the only kind of engineering in which completely new developments are considered as "maintenance". ;-)
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.
And you can bet it doesn't achieve its goal by requiring longer identifiers!!!
XP and PP practitioners don't swear by particularly long identifiers and spacious formatting (even if they often tend in that direction). Instead they swear by concepts like OnceAndOnlyOnce (DontRepeatYourself) and TestDrivenDevelopment and PairProgramming and making very small methods and RefactoringMercilessly and developing incrementally.
I've even heard them saying that code should not be commented: the opposite of Knuth's CWEB!. I think this is not incompatible with your citation of Knuth, just that it requires a completely different interpretation of that quote, as in, the code has to be its own documentation, instead of interleaving English with some programming language.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 27 Nov 2005, Hans-Christoph Steiner wrote:
Sounds like you need a better editor, or mouse wheel support.
Do you have bidirectional scrollwheel support in PureData? After all, we're having this discussion on pd-list, and we're using Smalltalk and Ruby for analogy with PureData. I bet your mouse doesn't have two scrollwheels. My laptop's touchpad has double-scrollwheel support, but that doesn't mean that any app supports it. I say that because PureData is more two-dimensional than ordinary code, and so may easily need two scrollbars if the patch is scattered enough.
If space was at such a premium,
It depends for whom. For those paid by the KLOC (kilo-line-of-code), it's important to use as many lines as possibly justifiable.
But for me, space is at a premium. It's not a matter of taking less space on diskettes or core memory or punchcards: it's a matter of visually outlining the rhythmic patterns in the code. We talk about PureData being a visual language, but I'm already making C a visual language, and I don't mean MSVC either.
then why do even C coders space out their code like this:
Because they have no clue about outlining alternating patterns of redundancy and variation, like, why it should be done and such.
I might rewrite your example like this:
#define SET_INPUT_KEYCODE(dev,code,val)
({unsigned __old; switch (dev->keycodesize) {
case 1 :{ u8 *k=(u8 *)dev->keycode; __old=k[code]; k[code]=val; break;}
case 2 :{u16 *k=(u16*)dev->keycode; __old=k[code]; k[code]=val; break;}
default:{u32 *k=(u32*)dev->keycode; __old=k[code]; k[code]=val; break;}
__old; })
because it emphasizes the repetition by aligning it into perfect columns, which is directly recognisable by the eye before even any conscious reading.
You can read each line horizontally if you're in a Philip Glass mood, but if you're just trying to understand, then you can read three lines in parallel and read the variation columns vertically.
My brain is SIMD.
It's just basic psychological engineering.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 25 Nov 2005, Hans-Christoph Steiner wrote:
If you need to save patch space, you can load it as a lib. Or if there was a declare/using/import object that would be even better. But I believe that abbreviations in code cause a lot more trouble than they save.
I think it's mostly a matter of choosing appropriate abbreviations.
Because "MAX" is a much more known name than "cyclone", it will be (on
average) more obvious that [max/counter] is meant to be a MAX-compatible
counter. The only problem I see with that particular case is that [max]
already stands for maximum.
"Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." -Donald Knuth
Yes, but then this prompts a few questions, such as, to which humans are we explaining it? and then, can we underestimate the necessity that something be convenient to write, if we overemphasize the reading?
I, for one, do not have an endless memory for abbreviations. I think I share that trait with the majority of population.
Each word is an abbreviation for something else. People learn new words every day.
However I agree that "cc" would be a fairly opaque abbreviation for "cyclone" especially as "cyclone" doesn't break down into two words with initials C.C. (even if you break it down into "sigh clone" ;-)
BTW I wholeheartedly agree with that saying from Donald, and I want to say that I consider it as an introduction rather than a conclusion -- it opens a whole new set of questions: how do we explain to other human beings what we want a computer to do? how is programming like teaching and how is it different too? and so on...
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
Hans-Christoph Steiner -
Krzysztof Czaja -
Mathieu Bouchard -
nico