'(Devin Walters)
On Tuesday, March 27, 2012 at 8:54 PM, Cedric Greevey wrote: > On Tue, Mar 27, 2012 at 3:05 PM, Herwig Hochleitner > <hhochleit...@gmail.com (mailto:hhochleit...@gmail.com)> wrote: > > 2012/3/26 Cedric Greevey <cgree...@gmail.com (mailto:cgree...@gmail.com)>: > > > (comp <{:k1 5 :k2 6}), that is not used in production whereas (comp < > > > {:k1 5 :k2 6}) (note spacing) is used in production but isn't broken. > > > > > > > > > (comp <{:k1 5 :k2 6}) _is_ used in Production, > > Without a space right after the <? Where? What is your evidence? > > > > > Without even showing a page of code using said new syntax, let alone > > > > make an effort to enumerate cases where it would break. > > > > > > > > > > > > > I did in fact make such an effort, which should also have been clear > > > from an earlier post. > > > > > > > > > Not in your initial post and none of the latter ones, as far as I saw > > while skimming. > > > > > If you're not very good at skimming without missing important points, > just set aside some time at some point and read it thoroughly. > > > > > Furthermore you don't seem to recognize the gravity of those issues > > > > > > The only issue arguably possessing substantial gravity is the > > > oddly-spaced (comp <{:k1 5 :k2 6}) and similar. > > > > > > > > > That statement is arguably wrong. > > And I am arguably a butterfly dreaming I'm a man. But it's a > hypothesis of no real practical import. > > > - Hacking a second pass into the compiler (the single pass compiler is > > a feature) > > > > > Avoided by <{...}> (or <[...]>). > > > - Breaking existing conventions > > I disagree that adding a syntax (without removing #{}) is "breaking" a > convention. On the other hand, allowing sets to be specified with a > symmetric delimiter pair arguably is UNbreaking a convention. > > > - Dual end tokens (the reason i chose lisp is, that I don't want to > > bother with foo.bar(); note the _);_ ). Yes, this makes a difference > > when you edit your program. > > > > > But you don't mind dual start tokens, or you'd object to #{. Seems > you're being fairly arbitrary there. > > > Lisp is about prefix notation. > > I don't see what bearing this has. Moreover, Lisp is many things to > many people. Others would say Lisp is about lambdas; still others, > that Lisp is about macros; and of course many would say Lisp is about > list processing. > > > - Adding duplicate reader syntax (the only other place we've done that > > is #^, which is deprecated and where nobody liked the original syntax, > > esp. in combo with type hinting) (the other examples you gave, e.g. > > deref vs @ were the reader macro vs the form into which it gets > > translated) > > > > > Duplicate syntax is duplicate syntax. Your reader vs. other > distinction is an artificial one. > > > - Introducing a new reader table (i.e. a prefix character that > > switches the reader mode) for '{', '<', or whichever you choose. right > > now the '#' is the only reader table and it is an important visual > > indicator for "here, the reader inserts a datatype determined by the > > next character" [or few characters, since we have tagged literals]) > > > > > And this is just plain wrong. There must be a reader table for the > default case as well as a secondary one activated for the next token > by #. Also, there's nothing inherently icky about adding one more. > Furthermore, the notion that # indicates "here, the reader inserts a > datatype determined by what's next" is ... a simplification, at best. > #^, though deprecated, still exists and attaches metadata rather than > deciding a datatype. #_ comments out the following form rather than > deciding a datatype (and can't really be interpreted as making what > follows some sort of "do nothing" datatype; (two-arg-fn 1 #_2 3) won't > throw bad arity). #' suppresses lookup of a var's contents, so the > form is the var itself instead of whatever's inside it. In fact, #{, > #", and arguably #( are the ones that do specify a datatype, and do > not outnumber the others. > > > > I offer(ed) my ideas for free. > > > > Yes you can _offer_ them for free. Which doesn't mean we can > > _implement_ them for free. > > > > > Nobody claimed otherwise. You, on the other hand, erroneously implied > that I was charging or costing you money. > > > Also, getting your idea implemented is > > valued very highly in this community, even if you get no money. > > > > > How is that relevant to the question of price? In fact by your own > admission ("even if you get no money") it's orthogonal to the question > of price, and therefore *not* relevant. > > > > Are you implying that you think I don't have a coherent view? > > > > I only implied that you didn't _demonstrate_ it (please read) > > Now you're implying that I lack reading comprehension skills. Please > stop being gratuitously insulting and rude. And please stop implying > things about me that are untrue. > > > > Because such an implication would be both factually false and an insulting > > > public mischaracterization of me, perpetrated without provocation. > > > > > > > > > But the fact that you didn't even consider implementation complexity, > > And what, pray tell, is your evidence for this latest unflattering > claim about me? > > Oh, that's right, you don't have any, because it's simply not true. > Indeed, my posts to this thread contain sketches of implementations of > both proposals, and neither description is especially complex. > > > language elegance, > > You call #{...} elegant? > > > implications on existing code (in your initial example anyway), > > The {{...}} proposal wouldn't alter the meaning of any existing code > that didn't currently bomb with a compile error, which you'd know if > *you* were reading rather than skimming (poorly) what I wrote. In > light of which your earlier implication that *I* lack decent reading > skills acquires a distinct whiff of irony. > > The <{...}> proposal would alter a rare-to-purely-hypothetical subset > of existing code that does not adhere to normal spacing conventions > around operators and delimiters, and was only suggested when everyone > seemed so dead set against having a form that human readers might need > to read to the end of to classify. > > > ... while the biggest merits are some 0.7% of some users, > > 93% of statistics are made up on the spot, and unless you back it up > with some evidence I'll consider your "0.7%" figure above to be just > another instance of such. > > > and an unverify_able_ claim of code beauty ... > > Beauty is in the eye of the beholder but I'm guessing {{1 2 3}} and > <{1 2 3}> both look nicer to most people that #{1 2 3} does. > > You say "most people." If you're taking a survey, I find the spaceship-like <{1 2 3}> to be aesthetically gross, and that's me trying really hard to be polite. For me, {{}} would come in second to #{1 2 3}. {{}} would immediately make me think nested hash-maps. I remember the old metadata syntax, and I remember disliking it. I've never felt the same way about #{1 2 3}. > > > tells me your grasp on the topic is not as complete as you might think. > > That you feel the need to resort to emotional appeals, ad hominems, > invective, and made-up numbers to try to bolster your position tells > me *yours* is not as complete as *you* might think. Furthermore, > several of your misunderstandings indicate that your grasp of what I > actually wrote is not as complete as you might think, especially > combined with your own prior admission that you only skimmed it rather > than truly reading it for comprehension. > > > This is not an insult, but a challange to prove otherwise, > > I'd already done so earlier in the thread, which you'd know by now if > you'd bothered to read the whole thing carefully and understand it > before responding instead of skimming it, seeing something you had an > initial negative emotional reaction to, and immediately firing off a > knee-jerk flame, which when you were called on it you followed up with > a somewhat calmer and more detailed but still not very informed post. > > > your two valid responses are proving and denying the need to prove. > > I choose what's behind door #2. I don't need to prove something a > second time after I'd already done so once. > > > > Since there are none, that would seem to be moot. On soliciting > > > feedback in general, what do you think this thread was for? > > > > > > > > > Looking at the initial post, it seems like it was for putting a > > not-that-well thought out idea out there, and see if it sticks. > > > > > Almost correct this time. Leaving out your gratuitous shot > ("not-that-well thought out") would have gotten you the A on that one, > but since you included it, and it's wrong, I can't give you more than > a B+ on this question. :) > > You may not have *thought* it was well thought out, but since (as you > admitted earlier) you only skimmed it you could not be sure whether > that perception was because of something I omitted or something I > included that you didn't notice in your skimming. You guessed the > former. You guessed wrong. Them's the breaks. Look on the bright side: > if you do the same thing again, you might get it right next time. > 50/50 odds aren't particularly bad. I'd still recommend reading > something you skimmed and didn't like before launching into a critique > over guessing blindly, though. > > > > Unfortunately, the feedback I've gotten thus far seems to consist more > > > of knee-jerk hostility than of reasoned debate on the technical > > > matters. > > > > > > > > > You didn't credibly address the technical reasons that were given to > > you (IMO, anyway) > > > > > What "technical reasons" were those? I'm guessing most likely one of > three misunderstandings has happened here: > > 1. The "technical reason" actually wasn't technical -- likely some > emotional argument based on a subjective aesthetic rather than a truly > technical argument based on an objectively measurable thing such as > correctness, ease of implementation, or performance. > > 2. I did credibly address the technical reason, but you mis-classified > my response as not credible for emotional reasons of your own. > > 3. I did credibly address the technical reason, but in your skimming > you didn't even see it; you went on to assume incorrectly that since > you hadn't seen it it wasn't there. > > I do recall a few instances of technical and semi-technical reasons > that I did credibly address; did you misunderstand one of those? They > include: > > * The suggestion not to parse in two passes. Arguably a technical > reason, based on simplicity of implementation. I addressed that by > quickly figuring out a way to implement the {{...}} proposal without > adding a delimiter-matching pre-pass to the reader and posting a > detailed algorithmic description that not only kept our existing > one-pass reader but localized the changes to it in one very small > region, around a single throw statement. > > * The complaint that human readability would be impaired by having to > read to the end of a form. I pointed out that to the extent that that > objection was technical at all, a) it would be possible to adopt > spacing conventions that made the code easily grokked at a glance and > b) though that convention could then be ignored, it's always possible > to write poor-readability code in any Turing-complete language by > flouting that language's formatting conventions. When that wasn't > enough to satisfy the nay-sayers I also suggested <{...}>. > > * The claim that <{...}> would break existing code. This claim is > predicated on the assumption that there's poorly spaced code out there > now that has a <{ pairing, for which no-one has provided any evidence. > I indicated that that assumption is questionable, since such code must > necessarily violate decades of Lisp spacing convention and the > language is young enough that not very much unusually-formatted code > in it is likely to exist yet. It should also be noted that backward > compatibility is not to be taken as absolutely inviolable (1.3's > numerics were much more seriously breaking changes!) and that a > special compiler message could be emitted for an unpaired <{ to alert > people to any poorly-spaced code that needs a space inserting. (The > ^:dynamic requirement for rebindable globals came accompanied by a > similar warning when that breaking change was introduced.) > > > At which point we can repeat the questions (reason), > > Repeating questions that have already been answered simply because you > didn't like the answer is not a rational way of debating. You can > either accept the answer despite not liking it or address perceived > flaws in the answer. Simply repeating the question as if the answer > hadn't even been uttered is not proper debate, however. > > > just tell you why it's a bad idea anyway (emotion), > > Appeal to emotion is a logical fallacy and fails to prove your case. > > > or just ignore you (will do, promise) > > You may certainly do that, but doing so doesn't prove you right. > > > > It's remarkable how emotional some people get in response not only to > > > merely words, but even to merely dry, technical words devoid of any > > > personal attacks, threats, unflattering public disclosures, or > > > implications of same. > > > > > > > > > Let me take the opportunity to apologize to you for where you feel I > > overstepped my boundaries. > > > > > Apology accepted. However, there were several more such missteps in > this post. Along with "Didn't mean to suggest that". I think you may > actually have an undiagnosed communication difficulty, between your > skimmings-and-misunderstandings and your > didn't-mean-to-suggest-that's. Sloppy reading and writing, together, > could explain it; on the other hand, your unusual name suggests a less > unflattering hypothesis: that English is not your primary language and > your grasp of it is not yet complete. Is this the case? > > > > Too late. You already, by implication, called me "incoherent", > > > "half-blind", and other things. > > > > > > > > > Well, the name I was shooting for, doesn't actually fit, since you > > seem to be interested in ongoing discussion involving you. > > > > > ??? > > > > Meanwhile, I have refrained for the most part from like behavior, and > > > I have, contrary to one of your implications, made a good-faith effort > > > to address each objection that has been raised. > > > > > > > > > You seem to have done that, truth be told. > > Earlier in *this same post* you intimated that I had not! To wit, > > > You didn't credibly address the technical reasons that were given to > > you (IMO, anyway) > > > > > These seem contradictory. Please clarify. > > > > I get the distinct > > > impression that several here *first* concluded that my idea was > > > terrible, and only *then* tried to form an argument proving it so, > > > rather than examining the idea with an open mind first and then > > > drawing a logical conclusion based on reason and evidence. > > > > > > > > > A page of example code could remedy that, mostly. > > We all see enough clojure code that we ought to be able to visualize > it readily enough. > > > > However, an > > > inquiry in search of truth must needs start with the bare facts and > > > suggestions and ideas and follow, unbiasedly, wherever these may lead; > > > an inquiry that starts with coming to a conclusion and only afterwards > > > attempts to apply the tools of reason is not a search for truth but > > > rather a search for a rationalization for a decision already made, > > > and, in many such cases, made blindly. > > > > > > > > > There are no bare facts in "I think a {{ }} set literal would be > > better / attract more users / ..." > > > > > There's the fact that I think that. > > > You can project facts by imagining it were so. > > How ironic. > > > By imagining, you also get an emotional response. If at this point the > > emotional response + projected facts are a net negative, your idea isn't > > received well. It's called human psychology. > > > > > And *that*'s called patronizing language. > > > Please don't be discouraged by this. I like to say yes much more than > > I like to say nay. I'd love to comment positively on your well thought > > out proposal. > > > > kind regards > > Anyone else feel that there are mixed signals being given off here? > > -- > 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 > (mailto:clojure@googlegroups.com) > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > (mailto:clojure+unsubscr...@googlegroups.com) > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
