On Tue, Mar 27, 2012 at 3:05 PM, Herwig Hochleitner
<hhochleit...@gmail.com> wrote:
> 2012/3/26 Cedric Greevey <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.
> 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
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
