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 <donning-my-garlic-necklace>marketing</donning-my-garlic- necklace>, 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" 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 -~----------~----~----~----~------~----~------~--~---
