Well, considering you mentioned that you haven't seen a resource for learning Perl "that presents code that is well structured, commented, and tolerant of bad inputs" and I named 4 of the top 10 renowned authors of Perl books, I'd say it's fair to name them.
Since Perlmonks along with Use Perl; and the Perl newsgroups, IRC groups, and mailing lists are the Perl community, I'd say they are representative. Conway, Schwartz, Larry Wall, chromatic, brian d foy, and several other very respected authors of Perl (the language), perl (the language system), and references about Perl and perl have accounts on and are relatively active on Perlmonks, too.
If you speak about "the Perl programming community" and don't recognize those names, then what you know about the community is what's not representative of the community.
You'll probably never see more than three object systems for Perl in use, and no more than two in the same shop.
Which two is a more open question. It's almost certainly two of the traditional blessed hash variety, Moose, and Object::InsideOut. Those are the ones people recommend and that have been widely adopted.
How many different ways do you think structures and unions have been coerced into acting as object systems in C, not even counting C++, Objective C, C#, D, and Java as C-family languages?
Moose is basically the Perl 6 object system ported back to Perl 5. It's the new standard way to do things, but it'll still be possible to do something else.
Perl 6 will try to appease the OO syntax goons who keep chanting "the dot is the way, the dot is here to stay", too. We're getting a new concatenation operator so everyone else won't have to deal with '->'.
Take a look at Perl 6 even if you don't like Perl 5. It's meant to be a new language in the Perl family, retaining only the best of Perl 3 through Perl 5.
Also, there are comp.lang.perl.misc and comp.lang.perl.moderated for Usenet, PerlMonks, Use Perl;, Perl.com, and many IRC channels, books, and mailing lists.
There are specific threads on Perlmonks about how to make it easier to choose which object-relational mapper, which text templating system, which web application framework, which object system, which date and time modules, and which modules for any given task.
Anything you want to do has two or three more popular, better documented ways with more community support and a host of other ways just in case. The community does a very good job of recommending one or two over the others.
I'm not sure why "grew organically" is something to "put up with". The fastest way to overengineering something is to design what you think you want before you know what you really want. Iterative design can be a good thing, in moderation.
So does CCP. They run EVE Online, the world's largest online game, which they developed in Stackless Python.
I'm not a huge fan of Python as a programmer. I'm primarily a Perl guy myself. That's just personal taste and is entirely subjective. Despite my dislike of its syntax and that it mostly fills a niche I've already covered with more than one other language I've considered giving it a go just because of the projects for which I've seen it used.
There are many wonderful things being done with Python, and they range from small things to huge things. Anyone who underestimates what Python and its community are capable of getting done do so at their own peril. From Google and EVE down to my favorite solitaire game (PySol), it's a language and group of developers worthy of respect.
On the up side for C++ is the fine-grained control it gives you. On the down side for C++ is the fine-grained control it demands of you.
You can use smart pointers, better string libraries, garbage collection libraries, and more to make you life with C++ easier.
If you're using garbage collection and string libraries, though, you're not gaining quite as much performance by using C++. You're also probably not using the same garbage collection and string libraries as your next hire used at his last employer.
You start getting the same issues as Perl, the many Pascal flavors, and Forth: there are more ways to do something than you need. Not all of them are compatible with one another, not all of them work as well alone as the incompatible pieces, and not all of them are familiar to the maintainer.
The problem is not the language, but how it's extended. The whole reason for standardization of languages is that once people start extending them, they start extending them in different ways. That's why CPL is not BCPL is not B is not K&R C is not the first ISO C which is not C99 which is not C++ which is not D, C# or Objective C.
Perl 5 is not Perl 4 and Perl 6 will not be Perl 5. Turbo Pascal is not ISO Pascal, Objective Pascal is neither of those. VB is not Dartmouth Basic, QuickBASIC, or LibertyBasic. Scheme is related to Lisp, but is not Common Lisp. Arc is not quite Scheme. OCaml is not Caml is not Standard ML of New Jersey.
It's time that Perl got a rewrite and a stronger standard. There's an actual language specification for Perl 6, and there will be multiple compatible implementations. That's how C evolved. It's only natural that as many ways to do something come along that a few of the best get selected for a new iteration. C++ might be next if any of Java, D, C#, Objective C, and whatever else aren't considered close enough descendants already.
It really depends on what sort of programs you are having implemented.
If you have the budget for many mediocre to downright poorly skilled people to work on a team for a huge multi-year project, then by all means choose a language and support tools for the language which facilitate that.
If you need one, a couple, or a handful of mediocre to fantastic programmers to be really productive on many smaller programs, then use a language which facilitates that.
Sometimes you can use the same programming language for both, but it's more difficult to use Perl, Forth, Lisp, or C for the former and more difficult to use Java, Ada, Eiffel, or COBOL for the latter.
I disagree. Languages don't encourage bad code (well, maybe Intercal, Malbolge, etc). They just don't enforce good coding practices.
There are problems with enforcing good coding practices, too, though. One that there are so many from which to choose that are good in different ways. You could just pick one, as Guido did, but then that makes other ones harder to use or less clear.
Vertical whitespace often makes things easier to read than horizontal whitespace does, but the majority of the time horizontal whitespace wins. Objects can really help clarity and modularity, but they get in the way when a small procedural program makes more sense. Some programs make more sense in a functional style with recursion while many recursive solutions can be made clearer and faster with iteration and a few side effects.
The difficulty people have with Perl is not that it encourages bad coding. It's that puts the responsibility for choosing a decent style and model on the programming team. If you're not ready to make those decisions, you can use Perl::Critic and PerlTidy or you can use a language that makes those decisions for you.
Just be aware that whether you make coding standard decisions consciously or by defaulting to some language designer with a particular taste, you're going to have pros and cons to your coding standards. It is an advantage in some ways, I suppose, that you end up with the same standards as your competitor down the street. It's also an advantage if you come up with one that allows your coders to be more productive than his.
You seem to be unfamiliar with the work of Damien Conway, Randal Schwartz, Tom Phoenix, and Lincoln Stein.
Stop by Perlmonks to read some book reviews and maybe lurk the Seekers of Perl Wisdom or Meditations sections. You'll see that what you've been reading is not representative of how things actually get done.
There are Perl Poetry and Obfuscation sections on the Perlmonks site, but those are games. You'll notice that there's a clear division between neat tricks for the sake of neat tricks and maintainable code for the sake of maintainable code.
If you can't read the code you're not very good with the language or the person who wrote the code isn't very good with the language. Writing clean, maintainable Perl takes some discipline. It's not the language's fault that people lack discipline.
So, Perl 5.8.5 to 5.8.8 and 5.10.0 are not incremental improvements?
5.8.5 was released in July 2003, and 5.8.6 was released in November of that year. 5.8.8 wasn't until January of 2006.
5.10.0 wasn't until December of 2007. The unstable development branch of 5.9 ran up to 5.9.5 in the meantime. The current iterative, incremental improvement is less than 9 months old.
Considering that Perl was originally intended to replace sed, awk, and many twisty shell languages, all different in many projects, saying that rewriting something from Perl into sed obfuscates it is exactly the point.
"Building in" is a key phrase there. PHP's biggest disadvantage is that everything becomes part of the main namespace. Most extensions in Perl are provided in manageable external modules that import nothing or optionally import nothing into your main namespace. For all the people talking about "maintainability" this and "hard to understand" that and praise PHP over Perl, they've obviously never messed with PHP extensions with conflicting function names. Perl has its downsides, but this generally isn't one of them.
Since you think that Perl has pointers, your opinion of the language should be taken with a grain of salt. It has references, but not pointers. There are substantial differences despite that there are similarities. Besides, if you're writing with accessor and mutator methods nobody cares what the inside of the object uses for a data structure.
Which of the many object systems for Perl have you used?
There are regular, ordinary, blessed hash objects. Then there are many more.
You might want to look up Moose and Object::InsideOut on CPAN Search.
There are also Object::Declare, Object::Prototype, Class::Dot, and others which are less widely used.
In Perl, TIMTOWTDI, and you can probably find one that you like if you're willing to look. Just be careful who else's code you have to maintain, because they might have taken TIMTOWTDI too far and use a way that's better left not done.
Like I said in #24674295, the press surrounding the iPhone 3G is what matters. The Apple ads were not entirely fair, although they were based in ideas that were basically true. Microsoft has been known for spreading FUD for years, and this is a perfect opportunity to use those skills.
Slashdot Mirror
Well, considering you mentioned that you haven't seen a resource for learning Perl "that presents code that is well structured, commented, and tolerant of bad inputs" and I named 4 of the top 10 renowned authors of Perl books, I'd say it's fair to name them.
Since Perlmonks along with Use Perl; and the Perl newsgroups, IRC groups, and mailing lists are the Perl community, I'd say they are representative. Conway, Schwartz, Larry Wall, chromatic, brian d foy, and several other very respected authors of Perl (the language), perl (the language system), and references about Perl and perl have accounts on and are relatively active on Perlmonks, too.
If you speak about "the Perl programming community" and don't recognize those names, then what you know about the community is what's not representative of the community.
It's kind of silly to rewrite basename at all, considering all one needs to do is this:
use File::Basename;
$basename = basename($fullname,@suffixlist);
$dirname = dirname($fullname);
my %hash = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
My, that's awfully ugly, isn't it?
You'll probably never see more than three object systems for Perl in use, and no more than two in the same shop.
Which two is a more open question. It's almost certainly two of the traditional blessed hash variety, Moose, and Object::InsideOut. Those are the ones people recommend and that have been widely adopted.
How many different ways do you think structures and unions have been coerced into acting as object systems in C, not even counting C++, Objective C, C#, D, and Java as C-family languages?
Moose is basically the Perl 6 object system ported back to Perl 5. It's the new standard way to do things, but it'll still be possible to do something else.
Perl 6 will try to appease the OO syntax goons who keep chanting "the dot is the way, the dot is here to stay", too. We're getting a new concatenation operator so everyone else won't have to deal with '->'.
Take a look at Perl 6 even if you don't like Perl 5. It's meant to be a new language in the Perl family, retaining only the best of Perl 3 through Perl 5.
If only there was somewhere to rate CPAN packages...
Also, there are comp.lang.perl.misc and comp.lang.perl.moderated for Usenet, PerlMonks, Use Perl;, Perl.com, and many IRC channels, books, and mailing lists.
There are specific threads on Perlmonks about how to make it easier to choose which object-relational mapper, which text templating system, which web application framework, which object system, which date and time modules, and which modules for any given task.
Anything you want to do has two or three more popular, better documented ways with more community support and a host of other ways just in case. The community does a very good job of recommending one or two over the others.
Have you ever heard of Moose, Catalyst, Jifty, CGI::Application, TemplateToolkit, DBIx::Class, Class::DBI, or Rose::DB?
I'm not sure why "grew organically" is something to "put up with". The fastest way to overengineering something is to design what you think you want before you know what you really want. Iterative design can be a good thing, in moderation.
Yes, suffocating you by holding you too tight. What a perfect analogy for the one true brace(less) style!
I'm sure Yahoo!, Amazon, CSC, and the BBC will be glad to hear it.
So does CCP. They run EVE Online, the world's largest online game, which they developed in Stackless Python.
I'm not a huge fan of Python as a programmer. I'm primarily a Perl guy myself. That's just personal taste and is entirely subjective. Despite my dislike of its syntax and that it mostly fills a niche I've already covered with more than one other language I've considered giving it a go just because of the projects for which I've seen it used.
There are many wonderful things being done with Python, and they range from small things to huge things. Anyone who underestimates what Python and its community are capable of getting done do so at their own peril. From Google and EVE down to my favorite solitaire game (PySol), it's a language and group of developers worthy of respect.
Most of them have to do with using a systems language to write user-level applications.
On the up side for C++ is the fine-grained control it gives you. On the down side for C++ is the fine-grained control it demands of you.
You can use smart pointers, better string libraries, garbage collection libraries, and more to make you life with C++ easier.
If you're using garbage collection and string libraries, though, you're not gaining quite as much performance by using C++. You're also probably not using the same garbage collection and string libraries as your next hire used at his last employer.
You start getting the same issues as Perl, the many Pascal flavors, and Forth: there are more ways to do something than you need. Not all of them are compatible with one another, not all of them work as well alone as the incompatible pieces, and not all of them are familiar to the maintainer.
The problem is not the language, but how it's extended. The whole reason for standardization of languages is that once people start extending them, they start extending them in different ways. That's why CPL is not BCPL is not B is not K&R C is not the first ISO C which is not C99 which is not C++ which is not D, C# or Objective C.
Perl 5 is not Perl 4 and Perl 6 will not be Perl 5. Turbo Pascal is not ISO Pascal, Objective Pascal is neither of those. VB is not Dartmouth Basic, QuickBASIC, or LibertyBasic. Scheme is related to Lisp, but is not Common Lisp. Arc is not quite Scheme. OCaml is not Caml is not Standard ML of New Jersey.
It's time that Perl got a rewrite and a stronger standard. There's an actual language specification for Perl 6, and there will be multiple compatible implementations. That's how C evolved. It's only natural that as many ways to do something come along that a few of the best get selected for a new iteration. C++ might be next if any of Java, D, C#, Objective C, and whatever else aren't considered close enough descendants already.
It really depends on what sort of programs you are having implemented.
If you have the budget for many mediocre to downright poorly skilled people to work on a team for a huge multi-year project, then by all means choose a language and support tools for the language which facilitate that.
If you need one, a couple, or a handful of mediocre to fantastic programmers to be really productive on many smaller programs, then use a language which facilitates that.
Sometimes you can use the same programming language for both, but it's more difficult to use Perl, Forth, Lisp, or C for the former and more difficult to use Java, Ada, Eiffel, or COBOL for the latter.
I disagree. Languages don't encourage bad code (well, maybe Intercal, Malbolge, etc). They just don't enforce good coding practices.
There are problems with enforcing good coding practices, too, though. One that there are so many from which to choose that are good in different ways. You could just pick one, as Guido did, but then that makes other ones harder to use or less clear.
Vertical whitespace often makes things easier to read than horizontal whitespace does, but the majority of the time horizontal whitespace wins. Objects can really help clarity and modularity, but they get in the way when a small procedural program makes more sense. Some programs make more sense in a functional style with recursion while many recursive solutions can be made clearer and faster with iteration and a few side effects.
The difficulty people have with Perl is not that it encourages bad coding. It's that puts the responsibility for choosing a decent style and model on the programming team. If you're not ready to make those decisions, you can use Perl::Critic and PerlTidy or you can use a language that makes those decisions for you.
Just be aware that whether you make coding standard decisions consciously or by defaulting to some language designer with a particular taste, you're going to have pros and cons to your coding standards. It is an advantage in some ways, I suppose, that you end up with the same standards as your competitor down the street. It's also an advantage if you come up with one that allows your coders to be more productive than his.
You seem to be unfamiliar with the work of Damien Conway, Randal Schwartz, Tom Phoenix, and Lincoln Stein.
Stop by Perlmonks to read some book reviews and maybe lurk the Seekers of Perl Wisdom or Meditations sections. You'll see that what you've been reading is not representative of how things actually get done.
There are Perl Poetry and Obfuscation sections on the Perlmonks site, but those are games. You'll notice that there's a clear division between neat tricks for the sake of neat tricks and maintainable code for the sake of maintainable code.
Worse than obscuring, too many comments easily get out of sync with the code and become downright misleading.
If you can't read the code you're not very good with the language or the person who wrote the code isn't very good with the language. Writing clean, maintainable Perl takes some discipline. It's not the language's fault that people lack discipline.
So, Perl 5.8.5 to 5.8.8 and 5.10.0 are not incremental improvements?
5.8.5 was released in July 2003, and 5.8.6 was released in November of that year. 5.8.8 wasn't until January of 2006.
5.10.0 wasn't until December of 2007. The unstable development branch of 5.9 ran up to 5.9.5 in the meantime. The current iterative, incremental improvement is less than 9 months old.
Considering that Perl was originally intended to replace sed, awk, and many twisty shell languages, all different in many projects, saying that rewriting something from Perl into sed obfuscates it is exactly the point.
"modern".
"Building in" is a key phrase there. PHP's biggest disadvantage is that everything becomes part of the main namespace. Most extensions in Perl are provided in manageable external modules that import nothing or optionally import nothing into your main namespace. For all the people talking about "maintainability" this and "hard to understand" that and praise PHP over Perl, they've obviously never messed with PHP extensions with conflicting function names. Perl has its downsides, but this generally isn't one of them.
A construct in Perl does not have a runtime in relation to its length. It has a runtime in relation to the number of opcodes it generates.
Since you think that Perl has pointers, your opinion of the language should be taken with a grain of salt. It has references, but not pointers. There are substantial differences despite that there are similarities. Besides, if you're writing with accessor and mutator methods nobody cares what the inside of the object uses for a data structure.
Which of the many object systems for Perl have you used?
There are regular, ordinary, blessed hash objects. Then there are many more.
You might want to look up Moose and Object::InsideOut on CPAN Search.
There are also Object::Declare, Object::Prototype, Class::Dot, and others which are less widely used.
In Perl, TIMTOWTDI, and you can probably find one that you like if you're willing to look. Just be careful who else's code you have to maintain, because they might have taken TIMTOWTDI too far and use a way that's better left not done.
Like I said in #24674295, the press surrounding the iPhone 3G is what matters. The Apple ads were not entirely fair, although they were based in ideas that were basically true. Microsoft has been known for spreading FUD for years, and this is a perfect opportunity to use those skills.