brian.goetz at oracle.com
Sat Jun 11 09:41:20 PDT 2011
Your arguments make sense, but you make a lot of questionable
assumptions (this is the only poll I intend to do, that this is the only
audience I intend to poll, that I intend to base my decisions solely (or
even at all) on the results of this poll, that the goal of this poll was
to select a winner, etc.)
I do want to ask the "target drivers" eventually. But I would almost
certainly phrase the questions differently to the "drivers" than to the
"theoretical physicists". I might want to refine my poll questions
based on small "trial" polls, or polls of communities with specific
characteristics. I may want to eliminate options which might be popular
with drivers but which the experts have good reasons to think are bad
ideas. In any given study, I may be looking for hidden correlations and
clustering (such as "people who like X like Y") rather than "which do
people like best".
Further, I might ask questions to different populations separately, to
identify whether the populations have different characteristics.
(Thought experiment: if you discovered "the experts love X, but the
drivers hate it", wouldn't that be really thought-provoking data which
would affect your data gathering / decision making process?)
Bottom line: there are lots of good reasons we might be taking this
approach. This is an iterative process. (Politicians do lots of polls
before election day.)
So, let's take for sake of argument that the data resulting from polling
this group has value. My question was: is that experiment even
practical to do?
> If you wanted to know how a car should handle in traffic, would you
> poll the doctors in theoretical physics that are the experts on the
> differential equations in the suspension, or would you ask the target
> audience drivers?
> One should always ask in the middle of the bell curve, if they
> understand the question. When it comes to the extreme technical
> details of this proposal I think they don't, but when it comes to
> syntax I think they do.
> There are one reason not to ask them and that's if you are afraid
> they'll make the "wrong" choice. But then you shouldn't ask anyone
> and instead make the decision on what you believe is the right choice
> and motivate that.
> Cheers, Mikael
> On Jun 11, 2011, at 17:38 PM, Brian Goetz wrote:
>>> Yes, I was chastised for daring to mention it publicly at
>>> http://www.infoq.com/news/2011/06/lambda-syntax and according to
>>> comments there, it appears that the 100 vote limit has already
>>> been exceeded.
>> For everyone's benefit: what I was trying to do here was poll the
>> lambda-dev community, not the entire Java developer community. I
>> wanted to get the sense from a small group that had already been
>> thinking about the issue for a while, and had seen most of the
>> alternatives at least once before, not a mass poll of people who
>> were seeing the alternatives for the first time and only thought
>> about it for a few seconds. (Because the data is now mixed
>> together, I have the worst of both worlds.)
>> The survey was further polluted because not only did the link
>> escape (I'll accept that's my fault for not explicitly asking not
>> to, lesson learned), but because Alex' blog entry restated the
>> questions in his own words! So not everyone was even voting on the
>> same thing. I suspect most people here read my guidelines and
>> thought about it a bit before they voted. Most of the people who
>> discovered the poll via twitter didn't even see those guidelines.
>>> So we might as well talk about this now.
>> You can, but I am still asking that you not.
>> But here's something we can talk about: is it even practical to
>> take a poll of this group? I am more than willing to repost the
>> poll, but I want data on what *this* group thinks, and that won't
>> happen if the poll is reposted elsewhere with someone else's
>> paraphrasing of what the instructions were. (I can post polls on
>> twitter too, and I might do that some day, but that's not what I
>> want now.)
More information about the lambda-dev