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, because it works and
somebody left it in.
>> 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. And it should have been in the initial post (by my
definition of should)
>> 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. Instead of arguing it, I'll present
my personal (descending) issue gravity list:
(Note that not all of those stem from your initial proposal, but there
are some from the various solutions you additionally proposed)
- Hacking a second pass into the compiler (the single pass compiler is
a feature)
- Breaking existing conventions
- 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. Lisp is about prefix notation.
- 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)
- 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])
> I offer(ed) my ideas for free.
Yes you can _offer_ them for free. Which doesn't mean we can
_implement_ them for free. Also, getting your idea implemented is
valued very highly in this community, even if you get no money.
> Are you implying that you think I don't have a coherent view?
I only implied that you didn't _demonstrate_ it (please read)
> 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,
language elegance, implications on existing code (in your initial
example anyway), ... while the biggest merits are some 0.7% of some
users, and an unverify_able_ claim of code beauty ... tells me your
grasp on the topic is not as complete as you might think. This is not
an insult, but a challange to prove otherwise, your two valid
responses are proving and denying the need to prove.
> 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. Every
PL community has those a lot.
> 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)
At which point we can repeat the questions (reason), just tell you why
it's a bad idea anyway (emotion), or just ignore you (will do,
promise)
> On the contrary, all decisions should be made from a weighing of costs
> versus benefits rather than, as you seem to be suggesting, considering
> just the costs alone.
Didn't intent to suggest that, otherwise: Exactly my view.
> 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.
> 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.
> 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.
> 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 / ..."
You can project facts by imagining it were so. 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.
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
--
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
