> And you don't believe how many people like this are out
  > there (not related to Perl, but in every area)!

This is the core point i was making. You have people who couldn't care less about their tool in every human endeavour. You knowing some doesn't mean that on average Perl devs don't love it.

To elaborate a bit more: At my last $work i was in a team of four, who preferred to use bash for most things. This however was borne from a sheer lack of knowledge and once i showed them how to get real work done with Perl they started to prefer it.

  > A forum, bugtracker or other means of collaboration 
  > software is far better suited for this, IMO.

There is a bug tracker attached to each project. Them having old bugs in there does not mean that they're being ignored, just that the author is lacking round tuits.

Also, there is a cpan annotation thing. Unsure of how much it's used. I must admit: CPAN's biggest weakness is that search.cpan.org is closed source. However metacpan is trying to fix that and has made huge strides. :)

  > "there is nothing like it" states that CPAN is unique
  > in every way, and it is not!

It is a question of scale. Is a 5% match in similary enough to say that it's "like it"?

  > I don't want to ask around for two weeks

I have never needed more than two hours to get feedback on a module in #perl. In fact, i was once trolled for taking more than 5 minutes to accept that XML::Simple is crap.

  > Config::Simple (is it crap too? i don't know now anymore)

Yes it is. Note how it has not been touched since 2005. As i mentioned: Config::INI::Reader/Writer are preferrable nowadays.

  > So a module is stopped being developed and determined
  > as being crap but how do i know that from the look at
  > CPAN?!

We are a community. You look at the reviews to see if there's anything obvious (I just added one: http://cpanratings.perl.org/dist/Config-Simple ) and if the module looks sketchy (long ago since last release, bugs open) you ask on IRC if better solutions have come around in the meantime. As mentioned, you'll get speedy answers.

  > A TOP100 of most active modules?

I like this idea. I have the feeling i've seen something like that before, but i'm not sure. I think the best solution would be to be able to order the search results by date.

  > Tried that, but somehow it didn't work for everything,
  > i'm not sure if some module was misbehaving.

It's lexical and only applies for your code. If you wish to capture warnings in third-party code, the cleanest solution is to wrap it in Capture::Tiny. :)

  > Try to remove an item in the middle.

Is this nice enough?

  @list = grep { $_ ne 'dogfood' } @list;

  > Unforunately i have read this statement in a magazine
  > about Perl 6 and some tutorials for it.

Ah, ok then. Honestly, i can accept that, i just would've liked to see more. Then again, not everyone writing about Perl 6 actually know a lot.

  > Sorry to have wasted your time, then.

Nah, it's fine. You allow me to demonstrate more powerful perl to the casual reader.

  > This doesn't change my mind, though.

This is a problem though. You've already decided that no matter what i say, you will remain stubborn.

  > Rest assured that i had this discussion with other IT
  > guys in the past and i'm not alone.

How many people think Britney Spears made amazing music? Appeal to majority is not always a good idea.

I think we have reached the depth of discussion threads on HN, so i'd like to thank you and tzs for your comments and this (imo) good discussion.

The use of map is nice, BUT it shows partially what is wrong:

1. there are too many non-obvious ways to do simple things (this means that out of 10 programmers you will typically see 10 different solutions to a simple problem)

2. i have a problem with using functions for "different" usecases as what their name implies.. in my world eval simply evaluates code and map is short for "apply function to every item" not "filter out an item"

- i hate doing "go over every item in a list and execute a function that returns the item if it is not 'dogfood' and return that new list, overwriting the original one" when all i want is "delete 'dogfood' from my list"

As good as your answers were, you've shown me some good points and that your community indeed is very helpful, i am not convinced of this language. Both of you said yourself that there are quirks in the language. "still try to decide what exceptions look like" after how many years of perl? That was my thought ;)

At the end of the day i will still try to find and fix bugs in other peoples perl code, curse frequently and hope that people move on to the next language..

I do appreciate the grace you've shown in replies.

> 1. there are too many non-obvious ways to do simple things

To a person who learned Lisp first your pythonish ways would be similarly non-obvious. Obviousness depends always on previous knowledge and you seem to know a lot about python; and as such expect things to operate like there.

Consider how confused a foreigner would be when he hears the word "bowling" and does not know about the sport and thinks it has to do with bowls.

> map is short for "apply function to every item" not "filter out an item" - i hate doing "go over every item in a list and execute a function that returns the item if it is not 'dogfood' and return that new list, overwriting the original one" when all i want is "delete 'dogfood' from my list"

But that is what filter does. Literally, there is no other way to implement this, unless you're operating with linked lists, which are not arrays. Filter is a map with a negated search func - wait, i'm an idiot. it should've been grep. But yeah, filter is just a grep with a negated search function.

  @list = grep { $_ ne 'dogfood' } @list;

Let me ask you a question though. In Perl, if i have a list of objects representing links and i want to remove all SSL links, i can do this:

  @links = grep { $_->protocol ne 'https' } @links;

How would i implement this in python? Does array.remove() accept lambdas as parameter? Or would i need to go another way?

> At the end of the day i will still try to find and fix bugs in other peoples perl code, curse frequently

Good luck and hop by on IRC! It will increase your curse frequency a LOT. (Until you meet mst and start to pick things up from him.)

I'll visit that channel when back from vacation for sure.

To do what you want you could use list comprehensions or the filter(function, sequence) function:

List comprehension:

  links = ["https://securesite.com", "http://unsecuresite.com", "https://sec2.com", "http://unsec2.com"]
  [url for url in links if not url.startswith("https")]
  >>> ['http://unsecuresite.com', 'http://unsec2.com']

filter() + lambda:

  links = ["https://securesite.com", "http://unsecuresite.com", "https://sec2.com", "http://unsec2.com"]
  filter(lambda url: not url.startswith("https"), links)
  ['http://unsecuresite.com', 'http://unsec2.com']

I'd go with the list comprehension, from your use of map i'd guess you'd go with the filter ;)

Of course you'd replace the url.startswith with whatever your criteria is.

Ah, that's kinda what i expected. Suddenly the two languages look fairly similar, no? :)

Also, list comprehension doesn't look bad to me. It's just a slightly weird and more verbose syntax of doing map, while filter does an in-place operation.

> A basic problem: Perl allows them to hack away all day and write hideous code that ensures they will never get fired. Due to their laziness the script will be undocumented, lack basic error checking, will have myriads of bugs and often fail, but no one except them will be able to fix it in a reasonable time frame.

Can you provide me with a link to any non-toy programming language for which this isn't the case? I've seen beautiful code in a lot of languages, and I've seen god-awful ugly code in a lot more. I don't think I've ever found a language that doesn't have some ugly code written in it, though.

> This is where you will be upset and think i am really unjust and a troll: I'm stating that Perl supports this behavior like no other language. (except maybe brainfuck ;) )

Well, when you offer up a statement that applies to essentially every programming language in existence, and then suggest that it only really applies to Perl, I can see where they might get that impression. A programming language is just a programming language. It's programmers that write it, and a poor programming can, and will, write piss-poor code in any language.

> My basic statement about Perl: It is possible to write readable, tested and maintainable code in Perl. BUT it is hard if not impossible with just the base language. It is by far easier to get it wrong then to get it right in Perl for the newcomer or average programmer.

No offense, but that's just flat out silly. First of, it's not at all hard to write readable, tested, and maintainable Perl in the "base" language.

Beyond that however, saying "just the base" language is very misleading and shows either ignorance or malice. Perl, by design, maintains a moderate "core". It doesn't ship with every module included. That doesn't make it hard to access additional functionality (such as Moose, Test::More, and thousands of others). That's a simple design decision, and isn't good or bad, it's simply a matter of trace-offs.

By your logic then, C is a horrible language, because it's almost impossible to write "readable, tested and maintainable" code with the base language, right? I mean, it has no object oriented functionality, no testing framework, and a very minimal standard library. What were they thinking? How is anyone supposed to get work done with C?

Oh, right. They get the libraries they need, and get stuff done. Just like in Perl. Only, in C you don't get CPAN to take 99% of the effort of finding and installing libraries out of the equation.

Regarding the "perl5 not in parrot" citation, i found some pretty good hints at this problem:

From the Perl Wikipedia page:

It is often said that "Only perl can parse Perl",[49] meaning that only the Perl interpreter (perl) can parse the Perl language (Perl), but even this is not, in general, true. Because the Perl interpreter can simulate a Turing machine during its compile phase, it would need to decide the Halting Problem in order to complete parsing in every case. It's a long-standing result that the Halting Problem is undecidable, and therefore not even perl can always parse Perl. Perl makes the unusual choice of giving the user access to its full programming power in its own compile phase. The cost in terms of theoretical purity is high, but practical inconvenience seems to be rare. Other programs that undertake to parse Perl, such as source-code analyzers and auto-indenters, have to contend not only with ambiguous syntactic constructs but also with the undecidability of Perl parsing in the general case. Adam Kennedy's PPI project focused on parsing Perl code as a document (retaining its integrity as a document), instead of parsing Perl as executable code (which not even Perl itself can always do). It was Kennedy who first conjectured that "parsing Perl suffers from the 'Halting Problem'",[50] which was later proved.[51]

Also interesting is the proof that Perl cannot be parsed:

http://www.jeffreykegler.com/Home/perl-and-undecidability

In general the saying "only perl can parse perl" has to have some root... http://www.google.de/search?q=%E2%80%9COnly+Perl+can+parse+P...

That's not completely true though; most of those analyses take the conclusion way past the point where it's accurate.

You cannot definitively produce a single canonical parse tree for every valid Perl 5 program without executing code in some cases, but you can produce a coherent and accurate parse tree without executing code if you allow nodes in the parse tree which express the two types of ambiguity (undeclared bareword interpretation and unknown arity).

Most of the time this doesn't come up.

Oh yes. I am perfectly aware of the impossibility of static analysis of Perl. You do have to execute Perl in order to be able to say definitely what any Perl construct will mean.

I'm just confused how this precludes inclusion of Perl5 in Perl6.