The snobbish attitude though is not reserved just for new developers. I'm not defending poorly written and possibly ill conceived modules that folks might naively upload to CPAN. I believe there need to be gatekeepers that keep the quality of the repository high. But can't reviews like that (however correct it might be) be done in a less public way?
Maybe create some phase gates for new contributors? or create some kind of bar to get over before you can upload and even get rated in the first place? I know that flies in the face of a free and open environment that promotes a rich marketplace of ideas, but the alternative creates a repo that will look like my garage. Who has time to sift through that junk? Ask my wife...
How about different CPAN tiers from free and open to highly restrictive where only the best tasting tuna gets to be Starkist? Or is that what the ratings are supposed to do and my suggestion is dumb?
It's really nice to have those in the community who are learned and experienced, and Perl has a lot of really smart people that happen to be programmers, but my experience has been that Perl's luminaries are at times either odd, obnoxious or both odd and obnoxious. People with a high degree of technical skill and acumen in this community would be well served in taking a few Dale Carnegie courses and understanding as the title of this post suggests, "we are all Perl ambassadors".
Bottom line I think the reputation of Perl developers as (sometimes) being old, out of touch and eccentric is not completely unfair and it is reflected sometimes in public ways that makes us all cringe. I'm encouraged at posts that point it out try to create a better experience for all Perl developers.
]]>Maybe create some phase gates for new contributors? or create some kind of bar to get over before you can upload and even get rated in the first place?
prepan.org exists as a place where authors can upload code for critique, but it doesn't get used often enough. I wouldn't mind the requirement for a new author to make at least one submission to prepan.org first (and get some positive feedback) before their first PAUSE upload, but this is difficult to enforce without a lot of code that no one would want to write.
]]>
$employee.name('Sally').surname('Ride').salary(200);
]]>
There are two problems with that statement. First, the Wikipedia page shows method chaining and not really "fluent" interfaces. Second, you're used to method chaining as a way of making some code more readable. Perl 6 uses different idioms and the given
idiom above is more natural for the language.
However...
"Perl 6 uses different idioms and the given idiom above is more natural for the language."
If that's really the case it would personally make Perl6 a pain to read and I hope (again personally, YMMV) that it's not true. Sorry :(
say $employee.name('Sally').surname('Ride').salary(200);
Seems natural to me and forces me to understand nothing about the internal structure of $employee (only the external API).
"given" is a flow control structure. Using it the way you have feels disconnected to me, there's no visible connection to the following "say" statement. Also you are directly setting attributes, rather than using a public API - isn't that usually something bad in OO code?
I like the general direction Perl6 took but some of the details, such as over-reliance on sigils (more line noise) really grate at me. If directly accessing object internal variables instead of using setters is now considered natural/best-practise in Perl6... I don't know... Maybe I don't understand real programming but I know what I like and this, I don't.
]]>Also, you can see an older version I did (with Jonathan's help with the MOP hackery) at this older version of that.
You'll note that you can use your version, but if you want it multi-line, you have to end each line with a backslash (or else Perl 6 will think that .foo
is being called on $_
instead of the invocant which was returned).
However, to fully take advantage of a "fluent" interface, we'd have to sit down and understand what users really need, what objects each method should return and write proper methods instead of the cheap method chaining hack. I was having enough fun with the Perl 6 that I should have paid more attention to the fact that what I wrote wasn't fluent (nor are most examples on that page).
]]>Also you are directly setting attributes, rather than using a public API - isn't that usually something bad in OO code?
Attributes in the interface don’t have to translate to fields in the class and assignments to such attributes don’t have to mean unchecked writes to private fields. It’s trivial to provide the same attribute interface outwardly but actually implement it with accessors/mutators behind the scenes.
Just because that code would be bad in Java doesn’t mean it’s bad in Perl 6.
]]>In PHP you have to count your way out.
Thats all for me. Perl labels > all