Readable names
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. Sure, I can read code with car and cdr but it never really communicated that well; I always had to go through a translation step in my head. 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 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. I'm not suggesting that terseness is bad, merely that I don't believe the trade off is worth it in this case. I've shown Clojure to a number of people and the Lisp derived syntax coupled with abridged names makes it harder for people to comprehend, makes it less likely that on first encountering a piece of Clojure code that they'll be able to understand it, and so make it less likely that I'll get to write Clojure for a living ... which makes me sad. Just some thoughts. Rob Lally. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 10, 2008, at 8:48 AM, Robert Lally 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. Sure, I can read code with car and cdr but it never really > communicated that well; I always had to go through a translation > step in my head. It's important to note right away that car and cdr aren't abbreviations for anything more meaningful than car and cdr. > 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? I think so, but I understand this is somewhat subjective. It is useful to look at the 'competition' here (from random other languages): array-get -> [] associate -> put conjoin -> add compose -> . I don't see people coming from a language where array access is [] feeling good about the verbosity of array-get. put and add have imperative connotations that don't fit what assoc and conj do, so using them would only confuse people more. > 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. IDEs can be great, but having to rely on them is a real problem. People stumble over Lisps due to editors without adequate paren matching, and if my experience with Clojure users is a guide, people tend to try to stick with the editor they already know, leaving them waiting for specific language support. Adding completion to the 'things your editor must do before you can write Clojure effectively' sets a high bar. > Using full words as function names leads to more readable code .. > which can only be a good thing. They do only to a point, and then the code gets larger and harder to scan, lines spill etc. > I'm not suggesting that terseness is bad, merely that I don't > believe the trade off is worth it in this case. I've shown Clojure > to a number of people and the Lisp derived syntax coupled with > abridged names makes it harder for people to comprehend, makes it > less likely that on first encountering a piece of Clojure code that > they'll be able to understand it, and so make it less likely that > I'll get to write Clojure for a living ... which makes me sad. Well, people have to learn something new when they approach a new language. I'm not sure associate or conjoin would be more readily understood without some background on persistent immutable data structures. But at least it's not a lot of arbitrary syntax and associativity rules, and most of the short names are true abbreviations. Short names are one way Clojure can compete for brevity with languages that get their brevity from syntax. IMO, it's more approachable than Haskell, Erlang, Scala or any of the ML variants. array-get, associate, conjoin and compose etc are all still available. I wonder - would people use them if they were provided as aliases? I know I wouldn't. The vocabulary of seqs and collections is so small. While I appreciate the approachability argument, a language is ultimately for its practitioners. I imagine there are those that wish assoc/conj/apply et al were even shorter, or dedicated symbols... Since I don't hear this argument too often, I image Clojure is striking an acceptable balance. What does everyone else think? Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
I am in favor of the existing names. Things you use all the time (like the core of a language) should be concise, things that you use more rarely can have longer names. That said, it would be pretty straightforward to alias longer names-- you could open source a humane_names.clj and let people vote with their feet. Cheers, Stuart > 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. Sure, I can read code with car and cdr but it never really > communicated that well; I always had to go through a translation > step in my head. > > 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 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. > > I'm not suggesting that terseness is bad, merely that I don't > believe the trade off is worth it in this case. I've shown Clojure > to a number of people and the Lisp derived syntax coupled with > abridged names makes it harder for people to comprehend, makes it > less likely that on first encountering a piece of Clojure code that > they'll be able to understand it, and so make it less likely that > I'll get to write Clojure for a living ... which makes me sad. > > Just some thoughts. > > > Rob Lally. > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
+1 on existing names On Mon, 10 Nov 2008 09:50:12 -0500 Rich Hickey <[EMAIL PROTECTED]> wrote: > > > On Nov 10, 2008, at 8:48 AM, Robert Lally 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. Sure, I can read code with car and cdr but it never > > really communicated that well; I always had to go through a > > translation step in my head. > > It's important to note right away that car and cdr aren't > abbreviations for anything more meaningful than car and cdr. > > > 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? > > I think so, but I understand this is somewhat subjective. It is > useful to look at the 'competition' here (from random other > languages): > > array-get -> [] > associate -> put > conjoin -> add > compose -> . > > I don't see people coming from a language where array access is [] > feeling good about the verbosity of array-get. > > put and add have imperative connotations that don't fit what assoc > and conj do, so using them would only confuse people more. > > > 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. > > IDEs can be great, but having to rely on them is a real problem. > People stumble over Lisps due to editors without adequate paren > matching, and if my experience with Clojure users is a guide, people > tend to try to stick with the editor they already know, leaving them > waiting for specific language support. Adding completion to the > 'things your editor must do before you can write Clojure > effectively' sets a high bar. > > > Using full words as function names leads to more readable code .. > > which can only be a good thing. > > They do only to a point, and then the code gets larger and harder to > scan, lines spill etc. > > > I'm not suggesting that terseness is bad, merely that I don't > > believe the trade off is worth it in this case. I've shown Clojure > > to a number of people and the Lisp derived syntax coupled with > > abridged names makes it harder for people to comprehend, makes it > > less likely that on first encountering a piece of Clojure code > > that they'll be able to understand it, and so make it less likely > > that I'll get to write Clojure for a living ... which makes me sad. > > Well, people have to learn something new when they approach a new > language. I'm not sure associate or conjoin would be more readily > understood without some background on persistent immutable data > structures. But at least it's not a lot of arbitrary syntax and > associativity rules, and most of the short names are true > abbreviations. Short names are one way Clojure can compete for > brevity with languages that get their brevity from syntax. IMO, it's > more approachable than Haskell, Erlang, Scala or any of the ML > variants. > > array-get, associate, conjoin and compose etc are all still > available. I wonder - would people use them if they were provided as > aliases? I know I wouldn't. The vocabulary of seqs and collections > is so small. While I appreciate the approachability argument, a > language is ultimately for its practitioners. I imagine there are > those that wish assoc/conj/apply et al were even shorter, or > dedicated symbols... > > Since I don't hear this argument too often, I image Clojure is > striking an acceptable balance. What does everyone else think? > > Rich > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
This is an argument that will probably go on for a long, long time, and I wonder if it might have to do with the way that people think and program. Personally, I tend to throw together lots of small experiments in the process of developing, and being able to use short symbols for common operations is absolutely what I prefer. It is less annoying than having to type long-function-names-that-describe-what-they-do, but much more importantly, they can be read easier. Short names for common operations means fewer lines that have to be broken, and eventually I think your mind can pick up common patterns, like (conj lst foo) in one glance, rather than having to read a method name and think about what it is doing. The number of characters required to accomplish any operation should correspond inversely to its frequency of usage. Hence the syntax for #(...) anonymous functions, maps being functions of their keys, etc. I agree, it does add a bit to the learning curve, but I bet within two or three evenings of watching screencasts and writing mini programs you have conj, assoc and more soft-wired into your neural fibers. I was going to say, "hey, you can always just make your own macros, and it won't even have a speed penalty." But actually, that is a bad idea. In Common Lisp people made 9 million versions of everything, even common utility methods, which means lots of libraries and support code feel half done, half maintained and half annoying. Life was much easier in the Ruby community, where the ruby way, much defined by Matz but evolved by the community, seems more accepted and used throughout. Clojure is already building on possibly the worlds largest code-base, Java, but I hope a similar level of unity will be maintained in the pure clj ecosystem. -Jeff Robert Lally 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. Sure, I can read code with car and cdr but it never really > communicated that well; I always had to go through a translation step in > my head. > > 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 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. > > I'm not suggesting that terseness is bad, merely that I don't believe > the trade off is worth it in this case. I've shown Clojure to a number > of people and the Lisp derived syntax coupled with abridged names makes > it harder for people to comprehend, makes it less likely that on first > encountering a piece of Clojure code that they'll be able to understand > it, and so make it less likely that I'll get to write Clojure for a > living ... which makes me sad. > > Just some thoughts. > > > Rob Lally. > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
There is one thing I would like to point out. My editor of choice, (emacs) uses the length of the function name as a guide of where to indent the next line to in some situations. I find that in my code, I try to create functions that say what I want to say without pushing the body of my code too close to the 80 character limit. While some of the suggested replacements might only add a few letters to their names, those letters add up. Of course, the benefit of a lisp-based language is no one is stopping you from aliasing all of the core function names into your own names to suit your needs/tastes. You could translate everything to Klingon if you really wanted to. You would just have to deal with the fact that no one but you would be able to read your code without jumping through a series of hoops. Heghlu'meH QaQ jajvam On Mon, Nov 10, 2008 at 9:50 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > On Nov 10, 2008, at 8:48 AM, Robert Lally 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. Sure, I can read code with car and cdr but it never really >> communicated that well; I always had to go through a translation >> step in my head. > > It's important to note right away that car and cdr aren't > abbreviations for anything more meaningful than car and cdr. > >> 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? > > I think so, but I understand this is somewhat subjective. It is useful > to look at the 'competition' here (from random other languages): > > array-get -> [] > associate -> put > conjoin -> add > compose -> . > > I don't see people coming from a language where array access is [] > feeling good about the verbosity of array-get. > > put and add have imperative connotations that don't fit what assoc and > conj do, so using them would only confuse people more. > >> 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. > > IDEs can be great, but having to rely on them is a real problem. > People stumble over Lisps due to editors without adequate paren > matching, and if my experience with Clojure users is a guide, people > tend to try to stick with the editor they already know, leaving them > waiting for specific language support. Adding completion to the > 'things your editor must do before you can write Clojure effectively' > sets a high bar. > >> Using full words as function names leads to more readable code .. >> which can only be a good thing. > > They do only to a point, and then the code gets larger and harder to > scan, lines spill etc. > >> I'm not suggesting that terseness is bad, merely that I don't >> believe the trade off is worth it in this case. I've shown Clojure >> to a number of people and the Lisp derived syntax coupled with >> abridged names makes it harder for people to comprehend, makes it >> less likely that on first encountering a piece of Clojure code that >> they'll be able to understand it, and so make it less likely that >> I'll get to write Clojure for a living ... which makes me sad. > > Well, people have to learn something new when they approach a new > language. I'm not sure associate or conjoin would be more readily > understood without some background on persistent immutable data > structures. But at least it's not a lot of arbitrary syntax and > associativity rules, and most of the short names are true > abbreviations. Short names are one way Clojure can compete for brevity > with languages that get their brevity from syntax. IMO, it's more > approachable than Haskell, Erlang, Scala or any of the ML variants. > > array-get, associate, conjoin and compose etc are all still available. > I wonder - would people use them if they were provided as aliases? I > know I wouldn't. The vocabulary of seqs and collections is so small. > While I appreciate the approachability argument, a language is > ultimately for its practitioners. I imagine there are those that wish > assoc/conj/apply et al were even shorter, or dedicated symbols... > > Since I don't hear this argument too often, I image Clojure is > striking an acceptable balance. What does everyone else think? > > Rich > > > > > --~--~-~--~~~---~--~~ 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
Re: Readable names
On Monday 10 November 2008 07:30, Daniel Renfer wrote: > There is one thing I would like to point out. My editor of choice, > (emacs) uses the length of the function name as a guide of where to > indent the next line to in some situations. I find that in my code, I > try to create functions that say what I want to say without pushing > the body of my code too close to the 80 character limit. What on Earth is an 80-character limit? I invite you to join us in the 21st century where the Hollerith card is found only in museums, many fonts are available and wide-screen (non-CRT) displays are common and affordable. > While some of the suggested replacements might only add a few letters > to their names, those letters add up. There is more than one way to indent for pretty-printing, and alignment beyond the function name (on a subsequent line) is probably not a good choice, since it's invalidated by changing names. > ... Randall Schulz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
Oh dear. I'm sure I shouldn't be responding to this thread, yet here I am... On Mon, Nov 10, 2008 at 11:15 AM, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > What on Earth is an 80-character limit? There are two main choices: some limit vs. no limit. With no limit, everyone's got to have a window as wide as the widest line anyone might use, leaving tons of unused screen real-estate for "normal"-length lines; or you get ugly wrapping or annoying side-scrolling. With a limit, it just comes down to picking a number: 40? 80? 132? It turns out that 80 not only has a lovely historical tradition (*wink*) but it's a pretty good compromise between wrapping too often and leaving too much whitespace down the right-hand side of your window. So be kind and wrap your code so it looks nice at 80 chars, or I'll just have to do it for you. :-) Ok, I've said my piece. I'll try harder not respond next time. --Chouser --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Mon, Nov 10, 2008 at 11:15 AM, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > On Monday 10 November 2008 07:30, Daniel Renfer wrote: >> There is one thing I would like to point out. My editor of choice, >> (emacs) uses the length of the function name as a guide of where to >> indent the next line to in some situations. I find that in my code, I >> try to create functions that say what I want to say without pushing >> the body of my code too close to the 80 character limit. > > What on Earth is an 80-character limit? > > I invite you to join us in the 21st century where the Hollerith card is > found only in museums, many fonts are available and wide-screen > (non-CRT) displays are common and affordable. I suspect you don't print out a lot of code? Or are accustomed to using a loupe on your printed code-reviews? :-) Old habits die hard, and I'm enough of a dinosaur to feel edgy when my code expands far beyond that invisible 78-character wall. I've also had to emergency-edit enough code at the console to appreciate that 78-ish still isn't a bad soft limit. Og make fire, go find slide-rule and write code now, Graham --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
I appreciate the answers that everyone has given to my post, and I thought I'd send a single response before ceasing my bleating; I do realise that this discussion has the potential to devolve into multiple different religious wars, and I appreciate everyone's tolerance and forbearance so far. I think, that most people who have responded have done so from the perspective that they feel Clojure currently strikes a good balance between terseness and comprehensibility. Since there is currently no strong IDE offering, everyone who is writing Clojure is currently writing in a general purpose text editor, perhaps with some customisation to make the process more pleasant. Many of the people on the list have pre-existing preference for a text editor and the fact that they can work effectively in Clojure is a real win. A few thoughts before I vanish back into the crowd: - The approach that Clojure takes to state management in a multi-threaded environment is very promising. I don't know if it is 'the right answer' to the problems of concurrency and parallelism .. but if it is I'd like to see it succeed. Success in this case would have to be considered in terms of wide-scale adoption. I believe that Lisp and, later, Smalltalk were "the right answer" of their time, but both failed to capture the mind-share they deserved. - The current users of Clojure probably aren't representative of the development community as a whole. I'm not suggesting that they/we are better or worse than average. Just that early adopters are atypical, exemplified by the fact that they are early adopters. I'm sure that many of the developers currently contributing to this list could work effectively using any tools, and with any naming convention you cared to concoct. If Clojure is adopted widely, the programmers working with it will predominantly be using an IDE, running on Windows. They won't be using Vi or Emacs or TextMate ( fine editors all, and I love them all equally ). I believe that optimising for this group is key to success. - The languages that have grabbed major developer mind-share have each been more expressive than the last, but also more verbose in the choice of identifiers. C gave us printf, Java gave us System.out.println. In an IDE world verbosity actually helps you be more productive since you can disambiguate and investigate using code completion - if aget, aset and co were named array-set, array-get then I could type array- to see a list of all the array related functions. With the names as they stand typing a will give me quite a long list of mostly irrelevant functions. Of course this is all predicated upon the creation of IDE tooling that is still very far away, so it is in many ways an argument based on a future which may never happen. I can see the value in optimising for now rather than the future, but I fear being trapped in a local optima. Rob Lally. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 10, 5:55 pm, "Robert Lally" <[EMAIL PROTECTED]> wrote: > Of course this is all predicated upon the creation of IDE tooling that is > still very far away, so it is in many ways an argument based on a future > which may never happen. I can see the value in optimising for now rather > than the future, but I fear being trapped in a local optima. Even with an IDE, I think I'd prefer functions with terse names, over ones that are verbose. IDEs can make typing long symbols more bearable, but they can't reduce the amount of screen real estate long symbols take up. The greater the size of your source code, the less you can see on screen at any one time. I find this has a large impact on my general comprehension of the source code, even if I'm the only author. YMMV, of course, especially if you happen to have a better visual memory than I do :) - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 10, 9:55 am, "Robert Lally" <[EMAIL PROTECTED]> wrote: > - The current users of Clojure probably aren't representative of the > development community as a whole. I'm not suggesting that they/we are better > or worse than average. Just that early adopters are atypical, exemplified by > the fact that they are early adopters. I'm sure that many of the developers > currently contributing to this list could work effectively using any tools, > and with any naming convention you cared to concoct. If Clojure is adopted > widely, the programmers working with it will predominantly be using an IDE, > running on Windows. They won't be using Vi or Emacs or TextMate ( fine > editors all, and I love them all equally ). I believe that optimising for > this group is key to success. If a programming language improves even one person's productivity, then isn't it useful? C was very useful to the original Unix hackers because it gave them the machine abstraction they wanted. Lisp was useful for the original AI hackers because it let them compute with symbols and gave them the flexibility to handle complex problems. Lua is useful to people who want an embedded scripting language in their C programs, because it's very lightweight. Matlab is useful for people who want a natural syntax for solving linear algebra problems and an IDE tailored for that task. All of these languages can coexist and a good programmer will pick up the one best suited for the problems she has to solve. An "average" programmer will use whatever language most like the one he learned in school, or whatever language his boss tells him to use, or whatever language has a canned solution for his problem. That's OK and good programmers shouldn't look down on average programmers, but good programmers also aren't obligated to write programming languages for them. (Maybe average programmers should be the ones designing programming languages for themselves, just like the best math teachers are often those who struggled with math in school, so they know how to communicate with people who are struggling.) > - The languages that have grabbed major developer mind-share have each been > more expressive than the last, but also more verbose in the choice of > identifiers. C gave us printf, Java gave us System.out.println. To me Java was a loss in productivity since any programming task requires several lines of boilerplate code, even more than in C. 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 -~--~~~~--~~--~--~---
Re: Readable names
> Since I don't hear this argument too often, I image Clojure is > striking an acceptable balance. What does everyone else think? Totally agree. See for example the extreme brevity of names in arc (Paul Graham's hundred year language). Reading code in arc is very hard. Longer names, like java and C++ promote, are terrible: as Rick says, lines spill, code becomes overall longer and harder to keep in the head. The one aspect that Clojure could (I don't know how) improve, is in reducing the breadth of syntax. Currently, in the clojure namespace there are 549 words (functions, macros, etc): >>> (count (ns-map (find-ns 'clojure))) 549 That is a lot to memorize. It would help me, at least, if there were sub-blocks (like in the webpage: java interop, macros, sequences, vectors, maps, collections, agents, etc) and each had a list of keywords that could be queried easier. Perhaps one way to do that would be to have a higher-order doc function, that replied with keywords belonging to it. For example, a mock-up call for "Maps": >>> (doc Maps) Maps are this and that, and can be manipulated with: (hash-map keyvals*) (sorted-map keyvals*) (sorted-map-by comparator keyvals*) (assoc map key val) (dissoc map key) (get map key) (contains? map key) ... Just a suggestion. Albert -- Albert Cardona http://albert.rierol.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
> What does everyone else think? I strongly prefer short names for frequently used functions/macros. Short names often let you avoid to break a line of code, but they could be quite cryptic. If they're used often, their meaning will become obvious with time. It's not a problem if it's not immediate that, say, 'car gives you the first element of a list. I've used it so much that it has become a synonim for 'first. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 11, 1:17 am, Albert Cardona <[EMAIL PROTECTED]> wrote: > Perhaps one way to do that would be to have a higher-order doc function, > that replied with keywords belonging to it. For example, a mock-up call > for "Maps": > > >>> (doc Maps) > > Maps are this and that, and can be manipulated with: > (hash-map keyvals*) > (sorted-map keyvals*) > (sorted-map-by comparator keyvals*) > (assoc map key val) > (dissoc map key) > (get map key) > (contains? map key) Matlab (for example) solves this in its own hackish way by offering help categories. If you type "help" you get a list of categories with a brief description of each one (e.g., "ops" for operators, "lang" for programming language constructs, "elmat" for matrix manipulation). If you type "help " you get a list of functions belonging to that category. However, the Clojure website already presents the information in this way, and I don't much mind keeping a web browser open while I'm hacking ;-) Maybe the right way is to scrape the Clojure website and generate categories from that? 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 -~--~~~~--~~--~--~---
Re: Readable names
--- On Wed, 11/12/08, David <[EMAIL PROTECTED]> wrote: > You're right. We don't. Not only that. I can't think how aget > instead of [] (and all the similar verbosity, as it were) fits > into "Almost no syntax" and "Core advantage still code-as-data and > syntactic abstraction" of the "Lisp is a good thing" section of the > (current) Clojure rationale. The "almost no syntax" part is because (aget a 5) introduces no additional syntactical elements, whereas a[5] does. That doesn't mean it's better or worse, it just means there's less syntax. > [...] from my point of view a[5] is less "syntax" than (aget > a 5). I'm not saying my opinion won't change. We're just using different definitions of syntax. The Lispy idea of syntax is that everything looks like same: (fn-or-special-form args). a[5] breaks that regularity, value judgments aside. > There, I've said it. I. D. E.. Without it the whole > thing (Clojure, that is) is in danger of remaining (merely) > academic, joining a long line of other Lisps. Not even > Smalltalk(s), with somewhat "more of a syntax" yet still > close to "code-as-data", could escape this fate. That, IMO, had absolutely nothing to do with IDE support. Smalltalk IDE's of the day blew everything else out of the water (as did many of the Lisp IDEs) and it's only relatively recently that we're seeing similarly-functional non-Lisp/Smalltalk IDEs. > If it's only brevity that you're after then aget > could be abbreviated still, I guess: ag anyone? There's "terse", and there's "concise". I know you're attempting humor, but IMO there's a difference between "association"/"assoc" and "assoc"/"a" in the amount of information being lost in each pair. Nothing stopping anybody from writing "verbose mode" macros. Dave --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Wed, Nov 12, 2008 at 2:13 PM, David <[EMAIL PROTECTED]> wrote: > > On Nov 10, 3:50 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: >> > 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? >> >> I think so, but I understand this is somewhat subjective. It is useful >> to look at the 'competition' here (from random other languages): >> >> array-get -> [] >> associate -> put >> conjoin -> add >> compose -> . >> >> I don't see people coming from a language where array access is [] >> feeling good about the verbosity of array-get. > > You're right. We don't. Not only that. I can't think how aget instead > of [] (and all the similar verbosity, as it were) fits into "Almost no > syntax" and "Core advantage still code-as-data and syntactic > abstraction" of the "Lisp is a good thing" section of the (current) > Clojure rationale. As I understand it, "Almost no syntax" means there is common syntax for everything instead of a bunch of special case syntax for various different situations. > While "Almost no syntax" may be a good thing for the development of > Clojure itself, from my point of view a[5] is less "syntax" than (aget > a 5). I'm not saying my opinion won't change. Through everyday usage > it probably will, but it'll take longer than it would have if the > "syntax" had been a little bit friendlier. Which brings me to another > issue: I bet that for newcomers, non-abbreviated names would make a > transition to Clojure a lot smoother. > > Now, such thinking caused quite a reaction from established > "believers" as I can see. Which leaves us with only one option: make > both notations possible / available. This is by no means a new > invention (see "man less" -> OPTIONS for example). Which, yet again, > brings me to another issue: switching between the two "perspectives" > in a decent IDE should be a click of a button (or a key-press) away: > an extended pretty-printer/formatter if you will. Your hypothetical IDE, could provide what you want whether or not longer aliases exist. There's nothing stopping someone from writing an IDE that converts aget to array-get or [] when it reads in a file and does the opposite when it writes it. -- Michael Wood <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 12, 2008, at 14:52, David wrote: > That's why I put my "syntax" in quotes. From my chair having almost no > syntax is a non-issue. I'd trade in syntax smallness for readability > any time. Taste and personal preference aside, one can ask the question what you get and what you lose by choosing "readability" or "regular syntax". A feature that you get with Lisp's minimal syntax, and which is often overlooked or underestimated, is simple yet powerful metaprogramming through macros. Compare Lisp to any other metaprogramming language (C++ templates, Template Haskell, MetaOCaml, ...) and you will quickly notice that Lisp macros are simplicity itself. > Maybe I wasn't clear enough. I wasn't implying that having IDEs is the > only factor in making it in the real world. I'm just saying that not > having them doesn't improve the odds. IDEs are very much a matter of personal preference. Having one is not enough to make an impact, what you need is support by many different IDEs. I don't know any language that had this from the start, so I doubt it ever made a difference to language acceptance. Konrad. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 10, 3:50 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > > 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? > > I think so, but I understand this is somewhat subjective. It is useful > to look at the 'competition' here (from random other languages): > > array-get -> [] > associate -> put > conjoin -> add > compose -> . > > I don't see people coming from a language where array access is [] > feeling good about the verbosity of array-get. You're right. We don't. Not only that. I can't think how aget instead of [] (and all the similar verbosity, as it were) fits into "Almost no syntax" and "Core advantage still code-as-data and syntactic abstraction" of the "Lisp is a good thing" section of the (current) Clojure rationale. While "Almost no syntax" may be a good thing for the development of Clojure itself, from my point of view a[5] is less "syntax" than (aget a 5). I'm not saying my opinion won't change. Through everyday usage it probably will, but it'll take longer than it would have if the "syntax" had been a little bit friendlier. Which brings me to another issue: I bet that for newcomers, non-abbreviated names would make a transition to Clojure a lot smoother. Now, such thinking caused quite a reaction from established "believers" as I can see. Which leaves us with only one option: make both notations possible / available. This is by no means a new invention (see "man less" -> OPTIONS for example). Which, yet again, brings me to another issue: switching between the two "perspectives" in a decent IDE should be a click of a button (or a key-press) away: an extended pretty-printer/formatter if you will. There, I've said it. I. D. E.. Without it the whole thing (Clojure, that is) is in danger of remaining (merely) academic, joining a long line of other Lisps. Not even Smalltalk(s), with somewhat "more of a syntax" yet still close to "code-as-data", could escape this fate. > put and add have imperative connotations that don't fit what assoc and > conj do, so using them would only confuse people more. Confusion is in the eyes of the beer-holder, right? I bet newcomers would feel less confused looking at "verbosity" than "almost-no-syntax- code-as-data". At least for the duration of the transition period. > IDEs can be great, but having to rely on them is a real problem. > People stumble over Lisps due to editors without adequate paren > matching, and if my experience with Clojure users is a guide, people > tend to try to stick with the editor they already know, leaving them > waiting for specific language support. Adding completion to the > 'things your editor must do before you can write Clojure effectively' > sets a high bar. It does, yes. Which is why "project Clojure" should have it's own IDE (not only a REPL). > > Using full words as function names leads to more readable code .. > > which can only be a good thing. > > They do only to a point, and then the code gets larger and harder to > scan, lines spill etc. Which should be a matter of one click (key-press) as I explained above. > Well, people have to learn something new when they approach a new > language. I'm not sure associate or conjoin would be more readily > understood without some background on persistent immutable data > structures. But at least it's not a lot of arbitrary syntax and > associativity rules, and most of the short names are true > abbreviations. Short names are one way Clojure can compete for brevity > with languages that get their brevity from syntax. If it's only brevity that you're after then aget could be abbreviated still, I guess: ag anyone? > IMO, it's more > approachable than Haskell, Erlang, Scala or any of the ML variants. > > array-get, associate, conjoin and compose etc are all still available. > I wonder - would people use them if they were provided as aliases? I > know I wouldn't. The vocabulary of seqs and collections is so small. > While I appreciate the approachability argument, a language is > ultimately for its practitioners. Right. Potential practitioners however, can get scared away not only by their own "fears" (taking root at least in part in the aforementioned abbreviations), but by their bosses' ones also. If Clojure isn't widely accepted, in the development community as well as in the IT marketing, it's hard to imagine programmers brave enough to confront their bosses with "We'll do it in Clojure!". It's a vicious circle. Maybe a bit more flexibility on the Clojure side could help break it. > I imagine there are those that wish > assoc/conj/apply et al were even shorter, or dedicated symbols... Maybe not only dedicated symbols but a bit more syntax, too. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure"
Re: Readable names
On Nov 12, 1:40 pm, "Michael Wood" <[EMAIL PROTECTED]> wrote: > Your hypothetical IDE, could provide what you want whether or not > longer aliases exist. There's nothing stopping someone from writing > an IDE that converts aget to array-get or [] when it reads in a file > and does the opposite when it writes it. On Nov 12, 1:47 pm, Dave Newton <[EMAIL PROTECTED]> wrote: > --- On Wed, 11/12/08, David <[EMAIL PROTECTED]> wrote: > > > You're right. We don't. Not only that. I can't think how aget > > instead of [] (and all the similar verbosity, as it were) fits > > into "Almost no syntax" and "Core advantage still code-as-data and > > syntactic abstraction" of the "Lisp is a good thing" section of the > > (current) Clojure rationale. > > The "almost no syntax" part is because (aget a 5) introduces no additional > syntactical elements, whereas a[5] does. That doesn't mean it's better or > worse, it just means there's less syntax. > > > [...] from my point of view a[5] is less "syntax" than (aget > > a 5). I'm not saying my opinion won't change. > > We're just using different definitions of syntax. The Lispy idea of syntax is > that everything looks like same: (fn-or-special-form args). a[5] breaks that > regularity, value judgments aside. That's why I put my "syntax" in quotes. From my chair having almost no syntax is a non-issue. I'd trade in syntax smallness for readability any time. > > There, I've said it. I. D. E.. Without it the whole > > thing (Clojure, that is) is in danger of remaining (merely) > > academic, joining a long line of other Lisps. Not even > > Smalltalk(s), with somewhat "more of a syntax" yet still > > close to "code-as-data", could escape this fate. > > That, IMO, had absolutely nothing to do with IDE support. Smalltalk IDE's of > the day blew everything else out of the water (as did many of the Lisp IDEs) > and it's only relatively recently that we're seeing similarly-functional > non-Lisp/Smalltalk IDEs. Maybe I wasn't clear enough. I wasn't implying that having IDEs is the only factor in making it in the real world. I'm just saying that not having them doesn't improve the odds. > > If it's only brevity that you're after then aget > > could be abbreviated still, I guess: ag anyone? > > There's "terse", and there's "concise". I know you're attempting humor, but > IMO there's a difference between "association"/"assoc" and "assoc"/"a" in the > amount of information being lost in each pair. Nothing stopping anybody from > writing "verbose mode" macros. Michael also stated (see above) that nothing was stopping anyone from doing anything. Surely you're not proposing that we all write our own IDEs and/or macros? That would really make .cjls more colourful. It would, however, also make them unmaintainable. Take a look at the following code, for example: http://www.cs.bgu.ac.il/~omri/Humor/verbose-c.html Now think away the macros for a moment... No, I think that, if at all, we need a single set of macros. As far as the IDEs are concerned, if we all try "inventing" our own (or plugins for the existing ones), they will all be half-done at best. It's better to focus on one project than spread the effort across several ones. At least until the developer base is large enough to be able to afford such a distribution. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 12, 4:47 am, Dave Newton <[EMAIL PROTECTED]> wrote: > There's "terse", and there's "concise". I know you're attempting humor, but > IMO there's a difference between "association"/"assoc" and "assoc"/"a" in the > amount of information being lost in each pair. Nothing stopping anybody from > writing "verbose mode" macros. Or vice versa, which was basically the original implementation of Arc ;-P 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 -~--~~~~--~~--~--~---
Re: Readable names
On Nov 12, 5:52 am, David <[EMAIL PROTECTED]> wrote: > No, I think that, if at all, we need a single set of macros. As far as > the IDEs are concerned, if we all try "inventing" our own (or plugins > for the existing ones), they will all be half-done at best. It's > better to focus on one project than spread the effort across several > ones. At least until the developer base is large enough to be able to > afford such a distribution. How would you define "IDE"? There's already Slime (for Emacs) and Vim support for Clojure. Slime can do all kinds of function name completion, link up to documentation, run chunks of code on the fly, and help manage project directories (via Speedbar). Presumably Vim can do the same (I haven't used the Clojure environment for Vim). What is it that characterizes an "IDE" for you, if I may ask? What features would it need in order to be sufficiently capable? I don't mean "in order to win the whole world over to Clojure" (Smalltalk had a great IDE but that didn't help); I mean in order to be useful to you, your programmer friends or colleagues? 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 -~--~~~~--~~--~--~---
Re: Readable names
On Friday 14 November 2008 22:05, Mark H. wrote: > On Nov 12, 5:52 am, David <[EMAIL PROTECTED]> wrote: > > No, I think that, if at all, we need a single set of macros. As far > > as the IDEs are concerned, if we all try "inventing" our own (or > > plugins for the existing ones), they will all be half-done at best. > > It's better to focus on one project than spread the effort across > > several ones. At least until the developer base is large enough to > > be able to afford such a distribution. > > How would you define "IDE"? ... > > What is it that characterizes an "IDE" for you, if I may ask? ... I've worked with many IDEs over the years, and hated almost all of them. MPW was very good because it was more a programmable editor and integrated command processor (shell) in a mostly text-based GUI than it was a singly defined IDE (it was kind of a funky Emacs with a poorly designed scripting language, but it allowed you to have what you want, not what its developers decide you should get). JetBrains (formerly IntelliJ) IDEA is decent and it's what I've been using for a couple of years (before that I was using jEdit). What makes IDEA worth learning and using (and its shortcomings worth putting up with) is the incredibly comprehensive static analysis and indexing it does of your entire program and the (reasonably) good way that information is made available to the user. There's too much for me to try to describe, and I don't think I use half of its features. (The latest release has added support for Ruby and Scala and I understand Python is coming.) Syntax coloring is a near triviality, really, and auto-completion only somewhat less so. It's the analytical capabilities that make an IDE better than any good editor. Naturally, dynamic languages limit what can be done in this regard. IDEA has Groovy and Grails support, and the heavy use of dynamically injected methods, e.g., force it to flag many valid uses as questionable and to fail to note many errors that would be made quite clear to the programmer in Java. > mfh Randall Schulz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
