Is TPF working on PR?
Perl 6 gets a fair mention in eWeek's article: "Perl 6 Further Widens Language Use". It's a start...
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
languages that don't have as many different ways of doing any given task."
The author gave no facts in the form of developer surveys or quotes from intimidated developers :) to back up that assertion.
I first became acquainted with Perl through reading O'Reilly's book "Google Hacks." My first impression of the language,
coming from a Visual Basic/Pascal background, was that there sure were a lot of curly braces:). As I started digging into Perl, particularly through Wall et al's "Programming Perl", the language made a lot of sense. In short, I did not find Perl intimidating.
When I discovered that Perl automatically handled array/list sizing, my reaction was to shout "Hallelujah!"
In some other languages, obviously, adjusting array sizes takes more work than in Perl. So that feature practically sold me on Perl all by itself.
Did any of you monks out there find Perl intimidating at first, and if so, what attributes of the language were problematic?
A discussion on this might be useful to the folks who are putting a lot of time into promoting this language...
Scott
Mostly what I find intimidating now are the people who look at Perl golf and Perl JAPHs and the slapped-together perl4-style CGI scripts and think that this is "normal" Perl. If I could eliminate those items from the Perl culture, I think we'd have fewer people intimidated by Perl in general.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
some of them. However, I can understand the intellectual appeal to folks of creating code like that. It seems like it is partly art
and partly demonstrating a certain level of mastery of the language.
Scott
Perl fit like a new glove for me. It was a little tight at first, but quickly loosened up to a perfect, comfortable fit. :)
I've been in these discussions many times and they are difficult because everyone can have good reasons for their approach.
However, once you decide on how you're going to do it 90% of the time, you are set. And with Perl, you still have the flexibility to consciously decide to do it different 10% of the time to handle a strange corner case. If there is only one way to do it, you don't have this flexibility.
I believe Perl 6 will address this nicely. I think they will provide one recommended way to do things, but still leave in the other ways to do it.
So for environments without good structure and standards, Perl can be challenging because it will highlight the lack of management. But as merlyn says, this isn't Perl's fault, it's a problem with the environment.
In languages with only one way to do it...
I've programmed non-trivial code in about 10 languages in the last eighteen months (and read code in a few others). Which languages provide only one way to do something?
Turn that around and ask what thing can only be done one way (if at all) in some languages, but one or more ways in Perl. Classes/objects come to mind immediately. Functional programming is another.
For other things, while there may not be only one way to do it in other languages, Perl offers many more options. For that, loops and loop control comes to mind, particularly postfix modifiers and next, last, map, grep, etc. All the array modifiers might be in that camp, too.
In a more abstract sense, subroutine argument passing and argument type validation is something that gets done lots of different ways in Perl, where in some other languages that is never even a question the programmer has to consider.
Some of these are exactly the kinds of things that Perl 6 is trying to define in a more standard way.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
But you're correct that I'm waving my hands a bit there. I spend most of my coding time with Perl, so it's been a while since I played with Java, C++, or others.
I think many languages that support OO have just one way to do it, but with Perl there is an amazing array of choices.
Well there are other languages that have a flexible approach to OO. Lisp and Ruby both spring to mind.
The other thing is that with Perl's OO a lot of the TIMTOWTDI comes from there not being one 'good' way of doing it. This hurts rather than helps Perl's OO system because the various different ways of doing it don't always play well together.
With development releases of Perl 6 expected to emerge this year, and perhaps a production release by around this time next year [...]i guess by "developement release" they mean some kind of beta release. i wonder, might the release of Perl6 be so close? is this too optimistic?
:)))))