Levente Uzonyi <le...@...> writes: > Why didn't it happen to smalltalk? I guess because the language tries to > mimic natural languages. Btw I can't come up with a language that changed > it's core library function names to shorter ones.
The very same natural language argument can be used in favor of my point as well :) That is, if you *really* want to mimic the entire bandwidth of natural language, you should also mimic the tendency of natural languages to introduce abbreviations for common concepts. This is an *essential* part of any natural language. What should be said is that one should use whatever works best for himself. But a language that does not offer abbreviations to those that seek for them can IMHO not be called natural. The "huffman coding" presented in Akira's paper introduces shorter *aliases* for common methods. So you can pick and use what you want. So his paper is exactly about how they proceed when introducing short aliases in the evolution of the Ruby API. The full paper can be found here http://www.citeulike.org/article/6174874 > Object >> #p is not really useful. Logging to Transcript is a bad practice > anyway. Print-outs are not *per se* bad practice. They have their justification and should be part of anyones debugging tool set. So even if you dont agree with abbreviating print-out to #p, you should not ban them from you tool set! For example, nothing beats print-outs when you need to trace a feed of events. You would not want to put an #inspect inside a loop that is taken 10'000 times :) Speaking of loops, I changed #h to abbreviate #haltOnce rather than #halt. At least for my style of debugging, that proofed to be more useful. I won't comment on the rest, some prefer concise language, some like to keep it verbose. My point is that a language should offer short aliases for common terms, and I guess all of my examples are common enough to qualify for a shorter aliases based on that criterion--if you want to mimic the evolution of abbreviations in natural language. --AA _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
