When it's valid and constructive, negative feedback is a good thing.
When it's neither of those, and repetitive on top of that, you can't help but leave civility at the door and tell the complainers to shove it.
I get a lot of bitching and negative outside feedback in my project too, including some very uninformed and unreasonable comments, boiling down to "$past_competitor released much more often than you do" and ignoring the fact that their releases were much buggier and less polished. I am not sure what I can do to reduce the amount of complaints like that...
I am not sure what I can do to reduce the amount of complaints like that
Nothing. Those commends look like they're about you, but they are really about the author trying to prove something about themselves to themselves. Searching for and commenting on perceived faults in other people's work is a valuable therapeutic exercise, and shouldn't be confused with genuine, constructive feedback.
If absolutely feel the need to respond, say "Yes, those are absolutely valid concerns, and you're welcome to work to fix them. However, they're perpendicular from my personal vision for this project (link to vision), so I'll keep working on things which I, personally, consider more relevant."
Unless the exchange is in public, in which case, something more thorough (like the article) may be proper.
"The standard grammar doesn't need a frozen specification to be implemented, because its implementation is considered part of the spec." Huge step backwards in semantics/specification.
If I understand what he's saying correctly, it's quite the opposite: because of a frozen specification, Python needed to halt syntax changes [1] as secondary language implementations catch up. Perl 6, on the other hand, will never have this problem, as the standard grammar will be executable in the language itself.
I don't agree. Python is also suffering from the "we don't need a specification because we have a reference implementation" problem. A very small part of the problem is mitigated if the reference implementation is frozen and is self-hosting (a plus). You really want something you can reason about, otherwise all you have is "that didn't work because the reference parser barfed" versus "you need a close brace."
Perl 5 also suffers from the "reference implementation as specification" problem, which is why Perl 6 is actually being quite careful to avoid designating a "reference implementation".
I think our (Perl 6's) notion of "standard grammar as specification" is more of a temporary designation than a permanent one. For now we need a rough guideline to follow when the prose description isn't matching the implementation, both of which are still undergoing a fair bit of revision and updating as we work through the implementation details.
The ultimate arbiter in the Perl 6 specification is the official Perl 6 test suite (http://perl6.org/specification/), which is to be shared among all implementations. Basically, if something is to be considered "official Perl 6", it has to appear in the test suite, and any implementation that then passes the test suite is considered a valid Perl 6 implementation.
Pm
(Yes, the test suite is also evolving. But the test suite certainly gives us something that can be reasoned about without having to also adopt all of the quirks of a specific reference implementation.)
A more valid criticism of the perl 6 development model is that it's a big-bang approach. They have sunk enormous resources into the components of this system with limited capacity to test either the compatibility of the components they're generating or the utility of the features they're implementing. Sounds like a recipe for disappointment.
I'll start this with "I'm a Perl programmer" but I'm not looking for a flame war. I am interested in hearing an expansion of your statements. I am going to admit I don't understand this one.
What do you mean by "Big Bang"? That Perl 6 is being developed on top of Parrot? That Perl 6 is a reinvention instead of re-iteration?
What "enormous resources" are you referring to? The Perl 6 team isn't huge and it's all volunteer with very little financial backing (only some relatively small grants from the Perl Foundation).
Which components are you referring to? Where are the "limited ability to test the compatibility of the components"? Which components? There are a lot of tests though... a truly massive test set. I'm assuming you're not referring to these.
From my understanding the "utility" is a pretty big part of what they're testing. There are folk writing Perl 6 (November wiki http://www.perlfoundation.org/perl6/index.cgi?november). The implementors are going back and forth with Larry about things. A lot of the ideas aren't new, just new in Perl.
I'm just trying to understand where you're coming from. :)
9 comments
[ 2.6 ms ] story [ 23.9 ms ] threadI get a lot of bitching and negative outside feedback in my project too, including some very uninformed and unreasonable comments, boiling down to "$past_competitor released much more often than you do" and ignoring the fact that their releases were much buggier and less polished. I am not sure what I can do to reduce the amount of complaints like that...
Nothing. Those commends look like they're about you, but they are really about the author trying to prove something about themselves to themselves. Searching for and commenting on perceived faults in other people's work is a valuable therapeutic exercise, and shouldn't be confused with genuine, constructive feedback.
If absolutely feel the need to respond, say "Yes, those are absolutely valid concerns, and you're welcome to work to fix them. However, they're perpendicular from my personal vision for this project (link to vision), so I'll keep working on things which I, personally, consider more relevant."
Unless the exchange is in public, in which case, something more thorough (like the article) may be proper.
1. http://www.python.org/dev/peps/pep-3003/
I think our (Perl 6's) notion of "standard grammar as specification" is more of a temporary designation than a permanent one. For now we need a rough guideline to follow when the prose description isn't matching the implementation, both of which are still undergoing a fair bit of revision and updating as we work through the implementation details.
The ultimate arbiter in the Perl 6 specification is the official Perl 6 test suite (http://perl6.org/specification/), which is to be shared among all implementations. Basically, if something is to be considered "official Perl 6", it has to appear in the test suite, and any implementation that then passes the test suite is considered a valid Perl 6 implementation.
Pm
(Yes, the test suite is also evolving. But the test suite certainly gives us something that can be reasoned about without having to also adopt all of the quirks of a specific reference implementation.)
What do you mean by "Big Bang"? That Perl 6 is being developed on top of Parrot? That Perl 6 is a reinvention instead of re-iteration?
What "enormous resources" are you referring to? The Perl 6 team isn't huge and it's all volunteer with very little financial backing (only some relatively small grants from the Perl Foundation).
Which components are you referring to? Where are the "limited ability to test the compatibility of the components"? Which components? There are a lot of tests though... a truly massive test set. I'm assuming you're not referring to these.
From my understanding the "utility" is a pretty big part of what they're testing. There are folk writing Perl 6 (November wiki http://www.perlfoundation.org/perl6/index.cgi?november). The implementors are going back and forth with Larry about things. A lot of the ideas aren't new, just new in Perl.
I'm just trying to understand where you're coming from. :)