Live data from Hacker News

Why Perl?

bits.shutterstock.com

91–100 of 118 posts

Re: Why Perl?

#91
post #54
post #38

Earlier quoted context omitted.

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.

I was responding directly to the "loved" part, but now I realize that was not clear. For the record, I think everything but CPAN applies to Ruby and Python. And your personal irritations are not really relevant to people who use it, just as my personal irritations with Perl are relevant to people who use (and maybe love) it.

Considering the amount of trolling you get when Perl is mentioned on e.g. HN, I'd say that some other language culture's love is boundless -- and a bit less than fully grown up...

Which also applies to that "great community" point. Shudder.

Re: Why Perl?

#92
post #44

My perspective on Perl is that it's like a Dremel tool. If you've ever had a household project that requires a tool you don't have or skill you don't know, you can usually take your Dremel out, dig through the gift pack of attachments that you received for Christmas, and find a way to do what you need to do. Will the results be pretty? No. Is it the best way to get the job done? Probably not -- but it's good enough.…

> My perspective on Perl is that it's like a Dremel tool.

Or, perhaps less literally, like a Swiss-Army chainsaw. http://catb.org/jargon/html/S/Swiss-Army-chainsaw.html

Re: Why Perl?

#93

Earlier quoted context omitted.

"compilable perl" has been "on the horizon" for 15 years. I suggest you not measure it by that rate.

I don't know what "compilable Perl" has to do with the CPAN. "Compilation" suggests some sort of execution and distribution strategy, while the CPAN is an archive of resuable code and the surrounding ecosystem of dependency management, documentation, bug tracking, history, annotation, and comprehensive testing around it. I'm suggesting that if you measure the amount of code submitted to the CPAN, the number of author…

> you'll see that Perl 5 is far from stagnant.

You mean CPAN is far from stagnant. CPAN is nice, yes, but I don't think CPAN alone is enough to invite newcomers to Perl.

Perl 5 itself is stagnant. New features are not developed in Perl 5 but Perl 6. Perl 6 ist still not mature after several years of development. I tried it on Parrot yesterday, it ran way slower than Perl 5. Who ever would use it when even the Perl advocates don't recommend it? Perl 6 looked so promising. I am disappointed.

Re: Why Perl?

#94

Earlier quoted context omitted.

I don't know what "compilable Perl" has to do with the CPAN. "Compilation" suggests some sort of execution and distribution strategy, while the CPAN is an archive of resuable code and the surrounding ecosystem of dependency management, documentation, bug tracking, history, annotation, and comprehensive testing around it. I'm suggesting that if you measure the amount of code submitted to the CPAN, the number of author…

> you'll see that Perl 5 is far from stagnant. You mean CPAN is far from stagnant. CPAN is nice, yes, but I don't think CPAN alone is enough to invite newcomers to Perl. Perl 5 itself is stagnant. New features are not developed in Perl 5 but Perl 6. Perl 6 ist still not mature after several years of development. I tried it on Parrot yesterday, it ran way slower than Perl 5. Who ever would use it when even the Perl ad…

> Perl 5 itself is stagnant.

I'm sorry to say, but you're merely showing that you're not aware of core development of Perl. Not a mistake of your's, mind, marketing of perl core dev is terrible and i need to start fixing that, but there's a lot going on:

https://github.com/stevan/p5-mop http://perl5.git.perl.org/perl.git/shortlog http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ http://perldoc.perl.org/index-history.html

Re: Why Perl?

#95
post #66
post #28

This is my view on Perl after coding occasionally with it for 2-3 years. For the last 6+ months i've been coding Perl 8 hours per day. In general i'd consider myself at least average in those languages (meaning this list includes my favorite language(s) and ones that i came across for projects and never looked back): C, C++, Java, Javascript, Python, Groovy, Visual Basic, C#, PHP. To be honest i don't agree at all (a…

> Perl lacks basic language features of a modern language (Exceptions, Array Handling, Error Handling, Unicode Support is horrible and so much more) Perl has more extensive Unicode support than Javascript, PHP, Go, Ruby, Python, or Java. That alone disqualifies it from being "horrible". See http://98.245.80.27/tcpc/OSCON2011/gbu.pdf > Want to have exceptions in Perl? Turns out the language doesn't have them.. There a…

I'd like to reply to your Unicode link with another link:

http://stackoverflow.com/questions/6162484/why-does-modern-p...

>Exceptions are built in:

Exceptions are built in? Ok, someone decided that this strangely named construct can also be used to emulate exceptions to a minimal degree (finally statement where? does it support "bubbling up" the exceptions over different modules? What if a module redefines signal handlers? I'm also not sure how the error message can be handed over multiple exceptions or how to catch different types of exeptions.. can probably be done but only by bloating up the code unnecessarily). The man page of eval shows a lot of issues and broken cases. This is the preferred way to do exceptions? Really?

Interesting link on your use of "if ($@)": https://www.socialtext.net/perl5/exception_handling It looks like it's not a good idea to do that, because it's a global variable (which in itself shows bad design decisions in the language itself, IMHO).

Finally, why are there myriads of Exception modules and Error handling modules and die/croak/carp modules, if it's already working so good in the base language? All of them try to solve problems in the base language (most of them even state that they exist because of quirks and problems in Perl on their man page). I never came across the need of looking for a replacement for those in another language...

> Yes, Perl assumes that you did not sleep through "Introduction to Data Structures". If the operation of "find out of collection X contains element Y" is one that you need to do often and/or need to be more efficient than linear search, you should not be using an array.

If i would care that much about speed i would expect the language to have an efficient C/asm implementation and not rely on millions of programmers to do it right. It's no magic, it's expected to just be there, by me. Plus, not everyone that uses Perl is a good programer and this encourages bad behavior and hideous code which could just be avoided. Besides, i write lots of network heavy code. I could run multiple seti@home instances in parallel and not slow the script down. Tbh, i don't care about the speed of this operation. I far more care about convenience. It's not convenient for me to have to read and debug array search operations of other people because they didn't get it right.

One example: I was debugging a clients script and somehow for very few elements out of millions the script failed. Reason: He used regex to compare/search for elements which broke when the element contained a dot, which translated to the regex special character. It was easy to fix but it was a pain in the ass to find.

Another example: I had to review and maintain code at a client (mind you this is a Dr. and shouldn't be that stupid. Nowadays i think he shouldn't even program ever again but this is a real case!): He obviously wasn't able to figure this out a nice way and wrote a lot of code to put single elements into a string and separate each element by a predefined string (#### in this case). Afterwards he was using regex with #### and ######## and added and removed those limiters and what not. It was a horrible day for me to read this and took hours to even figure out what he tries to achieve. Imo, this person shouldn't touch an editor ever again, but the point here is: I bet you 100$ that he wouldn't have done this in Java or Python or Ruby or whatever, just because it's easy to do in those languages.

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

Re: Why Perl?

#96

Earlier quoted context omitted.

Age is not the real reason. Perl was first released in 1987, while Python was released in 1991, Tcl in 1990, and Ruby in 1995. I believe that Perl's success is due to the fact that it was written to scratch an itch. Larry Wall didn't care much about making a pretty language. He cared about creating a useful language. To this end, it was picked up quickly by Unix junkies everywhere. The other big issue, that's often o…

Larry Wall didn't care much about making a pretty language. This suggests that Larry Wall was happy to create a kludgey language for the sake of just getting things done. I don't have any references around to back this up, but given Wall's background in linguistics, and his demonstrated interest in language features, I have to believe he was interested in creating a coherent, thoughtful, as well as practical, languag…

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

Re: Why Perl?

#97
post #95
post #66

Earlier quoted context omitted.

> Perl lacks basic language features of a modern language (Exceptions, Array Handling, Error Handling, Unicode Support is horrible and so much more) Perl has more extensive Unicode support than Javascript, PHP, Go, Ruby, Python, or Java. That alone disqualifies it from being "horrible". See http://98.245.80.27/tcpc/OSCON2011/gbu.pdf > Want to have exceptions in Perl? Turns out the language doesn't have them.. There a…

I'd like to reply to your Unicode link with another link: http://stackoverflow.com/questions/6162484/why-does-modern-p... >Exceptions are built in: Exceptions are built in? Ok, someone decided that this strangely named construct can also be used to emulate exceptions to a minimal degree (finally statement where? does it support "bubbling up" the exceptions over different modules? What if a module redefines signal han…

  > 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;`
  > 
  > And this is in core.

Re: Why Perl?

#98
post #28

This is my view on Perl after coding occasionally with it for 2-3 years. For the last 6+ months i've been coding Perl 8 hours per day. In general i'd consider myself at least average in those languages (meaning this list includes my favorite language(s) and ones that i came across for projects and never looked back): C, C++, Java, Javascript, Python, Groovy, Visual Basic, C#, PHP. To be honest i don't agree at all (a…

Ok, more responses: > i can't say i love the language at all That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's. >> often can find the core developers in charge of some code > i browsed a lot through CPAN and a huge part of modules hasn't been touched for years What you said has nothing to do with what you quoted. CPAN allows you to email those authors and the vas…

> That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's.

Sure, i never said that no one likes Perl. I'm well aware that many people like Perl. This may sound harsh, but here is my impressions of the people i've personally talked to that use Perl (please don't take that personal, i'm well aware that there are A LOT of good programmers out there):

- Typically too lazy to learn a new language or even new paradigms (often enough aren't interested in OO style programming or even basic best practices, code conventions, some of them i had a hard time to even convince using a VCS!)

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

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.

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 ;) )

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.

> What you said has nothing to do with what you quoted. CPAN allows you to email those authors and the vast majority will reply happily. And even in cases where they don't, it's easy to go on irc.perl.org and ask around in #perl.

I must admit that i didn't write a mail to an author. I don't consider this a good way to discuss problems with modules anyway, since this results in closed discussion and won't help anyone with the same problem in the future. A forum, bugtracker or other means of collaboration software is far better suited for this, IMO. This may be a nice addition to CPAN, imo, having discussions on the modules.. probably linked on the module page.. Just dreaming here.. :) At the end (as i have said) CPAN is probably the biggest advantage of Perl.

>> It is perfectly true. See this post for elaboration: http://hackerne.ws/item?id=3238662

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

http://stackoverflow.com/questions/1693529/list-of-top-repos...

> Did you try asking around? Look for alternatives? Often that is because the remaining bugs are no dealbreakers (license nitpicks anyone?) or the modules have been determined to be crap (XML::Simple).

I don't want to ask around for two weeks, i want to work and get started. Time is money. Config::Simple (is it crap too? i don't know now anymore) contains quite some bugs that are marked as important for a few years now. So a module is stopped being developed and determined as being crap but how do i know that from the look at CPAN?! I'm not sure if i should go on here and just search CPAN for other modules for example. I can't really convince you here but the overall feeling of browsing CPAN for modules is that there is a lot of old and outdated stuff in there, no discussions, no way to tell what is best to use, what is maintained. If you don't see it like that, then ok, but that's not only my impression. I looked at the CPAN statistics page but unfortunately i can't find usable statistics for my cause. Is there a statistic that shows the average time since the last update for all modules over the years? May be not a good statistic.. mhh... Amount of new package versions uploaded overall? Amount of fixed/open bugs? A TOP100 of most active modules?

> `use warnings FATAL => 'all';`

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

> `my @hits = grep { $_ eq 'dogfood' } @array;` > Alternatively: > `use List::Util 'first'; my $has_dogfood = first { $_ eq 'dogfood' } @array;` > And this is in core.

I think i was picking on the "search" too much, actually i meant the whole handling of arrays. Try to remove an item in the middle. Try to find which position element X has and delete or move this element. Stuff like that. It's really not as nice as in pretty much every other major language. The hint at List::Util is good but List::Util is really just a small list of functions.

Example: Looking for an element and deleting it? (Taken from perlmonks.org)

  my @array = qw( your array here );
  my $search_for = "here";
  my( $index )= grep { $array[$_] eq $search_for } 0..$#array;
  splice @array, $index, 1
I'm sorry, but this is hideous, really. Just to show you an example of what "modern" languages can do:

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

Unforunately i have read this statement in a magazine about Perl 6 and some tutorials for it. I don't have this magazine anymore but it's a quite respected IT journal in germany (i'x from Heise). I am trying to find prove.

> Well how nice to show at the end at least that you're a troll.

Sorry to have wasted your time, then. No, honestly. I can see how Perl can be used as a very powerful replacement for bash scripts, but i can't see it as a serious choice for a large product programmed by dozens of people (surely you now head of to show me examples of Perl software. This doesn't change my mind, though. There probably even is a significantly large program written in brainfuck, this wouldn't convince me to use it, though.)

Last Note: I may sound like harsh, bitter or trolling and i feel that HN is not the right place to have this discussion. I'm surprised that i haven't been downvoted to hell, but i think i am quite alone with my opinion here.. Rest assured that i had this discussion with other IT guys in the past and i'm not alone..

Re: Why Perl?

#99
post #95

Earlier quoted context omitted.

I'd like to reply to your Unicode link with another link: http://stackoverflow.com/questions/6162484/why-does-modern-p... >Exceptions are built in: Exceptions are built in? Ok, someone decided that this strangely named construct can also be used to emulate exceptions to a minimal degree (finally statement where? does it support "bubbling up" the exceptions over different modules? What if a module redefines signal han…

> 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 bu…

Thanks for your answer.

I'm very aware how to search an array in Perl. I really concentrated to much on searching in my text, whereas the critic should have been for array handling in general which i find far more inferior to other languages. From my other comment:

Example: Looking for an element and deleting it? (Taken from perlmonks.org)

  my @array = qw( your array here );
  my $search_for = "here";
  my( $index )= grep { $array[$_] eq $search_for } 0..$#array;
  splice @array, $index, 1
I'm sorry, but this is hideous, really. Just to show you an example of what "modern" languages can do:

  array = ["a", "b", "c", "d"]
  search = "b"
  array.remove(search)
  print array
     ['a', 'c', 'd']
They may have nearly the same amount of loc but imo the second one is by far more readable and not as error prone to typos or simple bugs as the Perl one.

Re: Why Perl?

#100
post #98

Earlier quoted context omitted.

Ok, more responses: > i can't say i love the language at all That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's. >> often can find the core developers in charge of some code > i browsed a lot through CPAN and a huge part of modules hasn't been touched for years What you said has nothing to do with what you quoted. CPAN allows you to email those authors and the vas…

> That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's. Sure, i never said that no one likes Perl. I'm well aware that many people like Perl. This may sound harsh, but here is my impressions of the people i've personally talked to that use Perl (please don't take that personal, i'm well aware that there are A LOT of good programmers out there): - Typically too lazy…

  > 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.
Post reply on HN