Why Perl? (bits.shutterstock.com)

indeed, or pypi, or PEAR, and I'm sure ruby has something similar too

Next time i'll make the ecosystem bit blinking and pink.

Maven repositories are just that: Repositories. They store file and display some metadata.

CPAN shows documentation from the code of a distribution itself. It also provides a bugtracker. When installing things from CPAN via cpan on the command line, the tests of that dist are run. Users can opt to install Test::Reporter, which then uploads those test results to cpantesters.org. Many people do this, across many OSes and Perl versions across the globe. Authors of dists get emails of failures. Users can look at nice matrices displaying the passes and failures on their platform combination. On failures regression analysis is performed automatically to try and pinpoint possible failure reasons. Since metacpan there is also a public API to an ElasticSearch database containing all the metadata about CPAN dists and their authors. So you can for example, find all dists written by authors living in your town.

Et cetera.

I could go on, but i think i made my point.

What was that library you reimplemented?

From what I've seen of at least Python, it can't really touch CPAN (yet?). It is not the same width of neither modules nor infrastructure (CPAN Testers, etc.).

And the lack of code blocks irritates the life out of me. But I get why it is a common education language, like Pascal in its days.

Edit: Mithaldu wrote this up well.

@ is common.. The others are pretty rare.

Ruby even uses some predefined globals (eg $_) that are pretty much straight out of Perl.

http://www.tutorialspoint.com/ruby/ruby_predefined_variables...

You are right. What I should have said is: "the lack of sigils to indicate type of a variable". In perl this noise is everywhere, while in Ruby its is a lot less common.

Specially if you use accessor methods. In ruby, unlike smalltalk, this instance variable sigils are pretty much impossible to get rid off. This is because in Smalltalk local variables have to be declared, and if you don't, the Language will try to use the instance variables. In Ruby it would default to being a local variable, if already assigned, or invoking a method with no arguments.

> giving me features which require all manner of annoying syntax in Python

    def foo(first, *rest):

vs

    sub foo{
        my ($first, @rest) = @_;

?

  >>> def foo(first, *rest):
  ...  print first
  ...  print rest
  
  >>> foo([1,2,3])
  [1,2,3]
  ()

  sub foo {
    my ($first,@rest) = @_;
    print $first . "\n"; 
    print @rest;
  }

  foo (1,2,3);

  1
  23

>>This suggests that Larry Wall was happy to create a kludgey language for the sake of just getting things done.

Don't really know what to reply to this. Is this your speculation, or do you have a citation to back this up. Have you had some programming experience in Perl?

Perl is the only programming language(the other tool is emacs) I have learn't so far which gives exponential gains in productivity with a linear learning curve.

No other scripting language remotely comes closer to Perl practicality and pragmatism in the real world. Python and Ruby aren't even closer.

All beauty and other merely-for-talk stuff aside, For serious applications nothing is beating C++/Java in the larger scenario. And Python and Ruby never came to match Perl's glory.

Python's glory is fading pretty quickly. The web crowd is going to the next cool framework. Ruby tends to be pretty famous these days.

Perl is truly among those first things done right tools. Nothing will ever replace C, Lisp, Perl, Unix, Emacs kind of tools completely. Because whatever tries to replace them, ultimately ends up looking up very similar to them.

  > 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.

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

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

  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']

  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']

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...

> 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.

  > I'd like to reply to your Unicode link with another link:
  >
  > http://stackoverflow.com/questions/6162484/why-does-modern-perl-avoid-utf-8-by-default/6163129#6163129

To which i have to say that both the Great Unicode Shootout as well as that answer are written by the same person. The point being: Yes, Perl's Unicode support is not perfect. But honestly? It's still the best you can get out there.

  > >Exceptions are built in:
  > 
  > Exceptions are built in?

The both of you are conflating two things here:

- Exception flow control - Exception objects

The former is in fact implemented in Perl core via eval { literal code block }. In earlier versions of Perl there were issues where DESTROY blocks, called on object destruction, were able to clobber $@, i.e. the error message. Thus Try::Tiny has become the preferred method of doing exception flow control:

  my $x;
  try {
      die 'foo';
  }
  catch {
      warn "Got a die: $_";
  } 
  finally {
      $x = 'bar';
  };

Mind, that issue has been fixed in 5.14 ( http://perldoc.perl.org/perl5140delta.html#Exception-Handlin... ), so if you're above that, you can safely use eval for your exception flow control.

  > does it support "bubbling up" the exceptions over different modules?

Yes, evals can be nested.

  > What if a module redefines signal handlers?

If it does it via local it won't even concern you. If it does it plainly you're in a bit of a bind, but in practice this kind of thing happens exceedingly rarely on CPAN outside of self-contained applications or testing/installing code.

  > I'm also not sure how the error message can be handed
  > over multiple exceptions

You die with an array reference containing the interesting exceptions.

  > or how to catch different types of exeptions.

If you know what kind of exception you expect, you write code that interrogates the scalar for that. For example, if you're expecting an object of a certain type:

handle_exception( $_ ) if blessed( $_ ) and $_->isa('Exception::Parse');

  > Finally, why are there myriads of Exception modules and
  > Error handling modules and die/croak/carp modules

Because we're collectively still trying to decide how to best handle exceptions.

  > I never came across the need of looking for a 
  > replacement for those in another language...

In other languages you get a solution plopped in front of you and have to accept it because you cannot even implement your own exception handling. If they got it right, great. If they didn't ... welp.

Anyhow, that was only the first part. The second part is Exception Objects, which is where a lot of the various CPAN modules come in. Since Perl does not provide a native exception object, you can return literally anything you wish and many people experimented to see which kind of exception object they wanted. The concensus for this has landed on Exception::Class.

  > Another point is: Very often i came across the 
  > recommendation to convert the array to a hash and then 
  > check for the key. What recommendation is that? When i
  > have a data structure that is best represented as
  > array, convert it for a simple operation? ugh...

Those recommendations are bullshit and that's where you're right. However the fact that you think Perl does not have tools to search through arrays shows a glaring gap in your knowledge. As i mentioned in another comment, Perl has excellent facilities for searching through arrays:

  > `my @hits = grep { $_ eq 'dogfood' } @array;`
  > 
  > Alternatively:
  > 
  > `use List::Util 'first'; my $has_dogfood = first { $_ eq 'dogfood' } @array;`
  > 
  &#...

  my @array = qw( your array here );
  my $search_for = "here";
  my( $index )= grep { $array[$_] eq $search_for } 0..$#array;
  splice @array, $index, 1

  array = ["a", "b", "c", "d"]
  search = "b"
  array.remove(search)
  print array
     ['a', 'c', 'd']

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