On Nov 10, 5:48 am, "Robert Lally" <[EMAIL PROTECTED]> wrote: > One of the many things that I really like about Clojure is that it abandoned > Lisp tradition where it was pragmatic to do so. One of the prime examples > for me was the use of first and rest rather than car and cdr.
To me that made sense for a different reason: because CAR and CDR are _only_ for lists, whereas FIRST and REST apply to all kinds of sequences. (The abbreviations CAR and CDR refer to the low-level implementation of singly-linked lists in an old Lisp system.) So in my mind, FIRST and REST serve a different mnemonic function than in your mind ;-) In part this is because there is a lot of Lisp tradition and so certain words like CDR and ASSOC have connotations, just like English words have connotations based on how people used them throughout history. > With this in mind it surprises me ( and disappoints a little ) that there > are still abbreviated function names in many places - aget, aset, assoc, > conj, coll?, comp, and so on. Is there any need for this in the 21st > century? The more text you can fit on your screen, the larger and more complex the programming constructs you can manipulate. I noticed this when observing a blind person coding and debugging: her debugging technique was to * narrow down the bug to a small window of code (about 10 lines), * use the screen reader to read the text over and over until she had memorized the window of code, * debug the code in her head, * and then apply the patch and test. The more code you can fit in your mental (or visual) window, the easier it is to debug. Also, programmer productivity metrics suggest that the fewer the lines of code per useful task accomplished, the more productive the programmer is. Of course this can be taken to an extreme; APL is the classic example, but even APL was very productive for people who could wrap their head around the notation and the collection-based way of thinking. (A lot of finance people found APL very productive, for example.) Another point of comparison is Einstein tensor notation. Omitting the summation signs confused the living daylights out of me at first. After a few minutes, though, I understood why. Einstein liked to work fast and loose with math and use his instincts and insight. Traditional summation notation distracted him from the variables themselves and it took longer to write. It was like boilerplate code and so Einstein created a syntactic convention that eliminated it. > The trade off between meaningful method names and number of > characters typed doesn't seem to be a good one from my perspective; > particularly as IDE support matures and you will only need to type 'asso' to > have the IDE expand the function name to 'associate' for you. Using full > words as function names leads to more readable code .. which can only be a > good thing. IDE support can go the other way too: you start typing letters and it pops up a window with the alternatives and a short docstring describing each. The IDE can even keep track of the functions you use the most, and only display docstrings for the less commonly used functions. Alternately, the IDE could use a user-specific customization table to translate between the original function names and names that are more helpful for the specific programmer. mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---