Why Perl?(bits.shutterstock.com)
bits.shutterstock.com
Why Perl?
http://bits.shutterstock.com/?p=63
21 comments
> 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 are modules.. all of them do some black magic trying to emulate this. The number one google hit (Error.pm) even states "Using the "Error" module is no longer recommended due to the black-magical nature of its syntactic sugar, which often tends to break.". And this is not some fancy 2011 language feature, it still isn't built in!
Exceptions are built in:
> Want to know if an element is in an array? There are some hideous for loops you could do, but nothing like "if X in Y".. best thing: Most recommended way to do this is to convert your array to a hash/dictionary and check for the key.. that's basic array handling.
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.
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 are modules.. all of them do some black magic trying to emulate this. The number one google hit (Error.pm) even states "Using the "Error" module is no longer recommended due to the black-magical nature of its syntactic sugar, which often tends to break.". And this is not some fancy 2011 language feature, it still isn't built in!
Exceptions are built in:
eval {
....code...
die("foo"); # throw exception
}
if ( $@ ) {
....this is exception handler...
}
> Want to know if an element is in an array? There are some hideous for loops you could do, but nothing like "if X in Y".. best thing: Most recommended way to do this is to convert your array to a hash/dictionary and check for the key.. that's basic array handling.
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.
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...
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...
> 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
> >Exceptions are built in:
>
> Exceptions are built in?
- 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';
};
> 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.
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
> I never came across the need of looking for a
> replacement for those in another language...
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...
> `my @hits = grep { $_ eq 'dogfood' } @array;`
>
> Alternatively:
>
> `use List::Util 'first'; my $has_dogfood = first { $_ eq 'dogfood' } @array;`
>
> And this is in core.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)
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
array = ["a", "b", "c", "d"]
search = "b"
array.remove(search)
print array
['a', 'c', 'd']
I guess i'll have to repost this here. :)
The correct answer should've been:
The correct answer should've been:
@list = grep { $_ ne 'dogfood' } @list;Didn't read all of it yet, but one thing i can answer right now:
The modules you mentioned have been superceded by better ones like XML::Twig, Config::INI::Reader/Writer and HTML::Treebuilder (and likely a lot more that i don't recall presently). Also, those bugs you point at are of medium amount, and not exactly crippling. Similar libraries in other languages likely have similar bugs, but they're less known because there's no unified bug tracker.
> Unicode Support is horrible
http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/ms...
Really now?
The modules you mentioned have been superceded by better ones like XML::Twig, Config::INI::Reader/Writer and HTML::Treebuilder (and likely a lot more that i don't recall presently). Also, those bugs you point at are of medium amount, and not exactly crippling. Similar libraries in other languages likely have similar bugs, but they're less known because there's no unified bug tracker.
> Unicode Support is horrible
http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/ms...
Really now?
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 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.
> the IRC channels i know are more idle then other languages
You're not in the right channels. Try irc.perl.org or #perl on freenode.
> it's really untrue to say "there is nothing like it"
It is perfectly true. See this post for elaboration: http://hackerne.ws/item?id=3238662
> often enough i think "mhh, should i even use this module? Nobody seems to care about this anymore"
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).
> But it tries to solve a problem that shouldn't be there in the first place.
I fully agree, but quite frankly, if you view this as a downside of Perl then you're just plain being short-sighted. The problem was created over a decade ago, at the conception of Perl 5; yet it is comfortably fixable without even changing core. And additionally, there is active work on fixing this issue in core:
https://github.com/stevan/p5-mop
> Want to have exceptions in Perl? Turns out the language doesn't have them.
Valid complaint. Exception::Class is a good tool for this, but i'd also like to have them in core. So far there has been no concensus on how to do it properly though without breaking backwards compatibility.
> The number one google hit
Google's search results for Perl are terrible and do not reflect the state of the community. Try searching for exception on CPAN itself.
> Perl thinks it's ok when you read an uninitialized variable. Want the script to terminate when this happens?
`use warnings FATAL => 'all';`
> Want to know if an element is in an array?
`my @hits = grep { $_ eq 'dogfood' } @array;`
Alternatively:
`use List::Util 'first'; my $has_dogfood = first { $_ eq 'dogfood' } @array;`
And this is in core.
> Unicode Support is horrible
I'll have to post this twice because you're so wrong:
http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/ms...
> My fun fact on Perl:
{{citation}}
> When your script/tool exceeds 100 lines of code, don't use Perl! Atleast not if there is the remote possibility of another human being having to understand or maintain it. Please!
Well how nice to show at the end at least that you're a troll.
> 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 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.
> the IRC channels i know are more idle then other languages
You're not in the right channels. Try irc.perl.org or #perl on freenode.
> it's really untrue to say "there is nothing like it"
It is perfectly true. See this post for elaboration: http://hackerne.ws/item?id=3238662
> often enough i think "mhh, should i even use this module? Nobody seems to care about this anymore"
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).
> But it tries to solve a problem that shouldn't be there in the first place.
I fully agree, but quite frankly, if you view this as a downside of Perl then you're just plain being short-sighted. The problem was created over a decade ago, at the conception of Perl 5; yet it is comfortably fixable without even changing core. And additionally, there is active work on fixing this issue in core:
https://github.com/stevan/p5-mop
> Want to have exceptions in Perl? Turns out the language doesn't have them.
Valid complaint. Exception::Class is a good tool for this, but i'd also like to have them in core. So far there has been no concensus on how to do it properly though without breaking backwards compatibility.
> The number one google hit
Google's search results for Perl are terrible and do not reflect the state of the community. Try searching for exception on CPAN itself.
> Perl thinks it's ok when you read an uninitialized variable. Want the script to terminate when this happens?
`use warnings FATAL => 'all';`
> Want to know if an element is in an array?
`my @hits = grep { $_ eq 'dogfood' } @array;`
Alternatively:
`use List::Util 'first'; my $has_dogfood = first { $_ eq 'dogfood' } @array;`
And this is in core.
> Unicode Support is horrible
I'll have to post this twice because you're so wrong:
http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/ms...
> My fun fact on Perl:
{{citation}}
> When your script/tool exceeds 100 lines of code, don't use Perl! Atleast not if there is the remote possibility of another human being having to understand or maintain it. Please!
Well how nice to show at the end at least that you're a troll.
> 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)
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..
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
>>> array = ["a", "b", "c", "d"]
>>> search = "b"
>>> array.remove(search)
>>> print array
['a', 'c', 'd']
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..
> And you don't believe how many people like this are out
> there (not related to Perl, but in every area)!
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.
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!
> I don't want to ask around for two weeks
> Config::Simple (is it crap too? i don't know now anymore)
> So a module is stopped being developed and determined
> as being crap but how do i know that from the look at
> CPAN?!
> A TOP100 of most active modules?
> Tried that, but somehow it didn't work for everything,
> i'm not sure if some module was misbehaving.
> Try to remove an item in the middle.
@list = grep { $_ ne 'dogfood' } @list;
> Unforunately i have read this statement in a magazine
> about Perl 6 and some tutorials for it.
> Sorry to have wasted your time, then.
> This doesn't change my mind, though.
> Rest assured that i had this discussion with other IT
> guys in the past and i'm not alone.
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..
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.
> 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.)
> 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;
@links = grep { $_->protocol ne 'https' } @links;
> 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:
Of course you'd replace the url.startswith with whatever your criteria is.
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']
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']
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.
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.
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...
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.
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.
I'm just confused how this precludes inclusion of Perl5 in Perl6.
Not sure why you're being downvoted. Your points are valid.
One of the main points that caught my eye while reading this was the fact that the author mentioned that Perl programmers love their language.
As a Perl hacker, I couldn't agree more, and that's the main point I guess. Sure, CPAN is awesome (there is even a module for controlling USB rocket launchers - http://search.cpan.org/~pen/Device-USB-MissileLauncher-Rocke...) and everything is open source, but the thing I love most about Perl is the fact that thought is translated into code very quickly and naturally. Something just clicks and feels right.
I suppose that's why despite being fluent in several languages, I always come back to it.
As a Perl hacker, I couldn't agree more, and that's the main point I guess. Sure, CPAN is awesome (there is even a module for controlling USB rocket launchers - http://search.cpan.org/~pen/Device-USB-MissileLauncher-Rocke...) and everything is open source, but the thing I love most about Perl is the fact that thought is translated into code very quickly and naturally. Something just clicks and feels right.
I suppose that's why despite being fluent in several languages, I always come back to it.
I think this issue is where a lot of the schism comes from - not everyone's thoughts translate well into perl.
I've tried to "get" perl a few times, and I also get tasked with maintaining legacy perl code from time to time. Perl is the only language I can't readily use without a few books and perldoc.perl.org handy. It just doesn't fit my brain - yet I can jump around in other languages with little trouble.
Maybe it's just me, but I imagine that there's others that have a similar dissonance with the language.
I've tried to "get" perl a few times, and I also get tasked with maintaining legacy perl code from time to time. Perl is the only language I can't readily use without a few books and perldoc.perl.org handy. It just doesn't fit my brain - yet I can jump around in other languages with little trouble.
Maybe it's just me, but I imagine that there's others that have a similar dissonance with the language.
Sometimes it takes a while to click. I abhorred `map` for the longest time, but nowadays i use it everywhere; since i read the SICP and suddenly grokked them.
We shape our tools and thereafter our tools shape us. -- Marshall_McLuhan
It's not that Perl makes it natural for people to express their thoughts. It's simply that your mind was trained to think in Perl.
It's not that Perl makes it natural for people to express their thoughts. It's simply that your mind was trained to think in Perl.
It can be very revealing how people feel about a programming language after they stop using it for new projects. Some people can't quite give it up, others fondly send flowers once a year, and some people piss on the grave.
I do think people often wind themselves up when they're breaking up with something - could be a personal relationship, a hobby, a programming language - anything that required a lot of devotion. I think we do this to justify the decision and overcome the dissonance we feel (ie., we overstate the problems we have experienced as a way of overcoming the pain of leaving), so it's especially impressive when people still look back on a programming language with affection. Perl seems to be one of those languages.
Java gets a lot of scorn from people who once used it and have moved on. I personally look back on the days of servlets, jsp, and jdbc fairly positively - I do remember sometimes looking at the screen and realizing that my fingers were going to spend a few days typing something that I'd already thought out, but it all made sense and I felt like I could do anything. I didn't start hating java until configuration hell arrived. Then, I wanted out.
I do think people often wind themselves up when they're breaking up with something - could be a personal relationship, a hobby, a programming language - anything that required a lot of devotion. I think we do this to justify the decision and overcome the dissonance we feel (ie., we overstate the problems we have experienced as a way of overcoming the pain of leaving), so it's especially impressive when people still look back on a programming language with affection. Perl seems to be one of those languages.
Java gets a lot of scorn from people who once used it and have moved on. I personally look back on the days of servlets, jsp, and jdbc fairly positively - I do remember sometimes looking at the screen and realizing that my fingers were going to spend a few days typing something that I'd already thought out, but it all made sense and I felt like I could do anything. I didn't start hating java until configuration hell arrived. Then, I wanted out.
Hear hear, Perl developer here.
I've used C/C++/ObjC/Java/Erlang and I just love Perl for gluing it all together.
I must admit my stack is outdated, I still use CGI::Application, though I love Moose. I haven't kept us since catalyst, etc started to appear. CGI::Application works really well for me.
The other day I implemented push notification and geolocation bases functionality for a client in a couple of days.
To them it looks like magic, but to me it's just awesome that there are libraries in cpan to do just about everything making it a real time saver.
I must admit my stack is outdated, I still use CGI::Application, though I love Moose. I haven't kept us since catalyst, etc started to appear. CGI::Application works really well for me.
The other day I implemented push notification and geolocation bases functionality for a client in a couple of days.
To them it looks like magic, but to me it's just awesome that there are libraries in cpan to do just about everything making it a real time saver.
The thing I admire most about Perl is that the libraries written for it tend to be more complete than what I've seen in other, similar languages. I think this is due to its age. This may not seem important, but when you need a complete implementation of something you'll likely find it in a Perl library before you will in a Python or Ruby library... just my experience.
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 overlooked, is the Perl community itself. People working on Perl are really passionate about it. Spend some time reading the perl5-porters (p5p) archives, and you'll see for yourself.
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 overlooked, is the Perl community itself. People working on Perl are really passionate about it. Spend some time reading the perl5-porters (p5p) archives, and you'll see for yourself.
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, language.
Perhaps you nor I find the results pretty per se, but the language does have its own aesthetic which apparently many find to have a kind of beauty.
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, language.
Perhaps you nor I find the results pretty per se, but the language does have its own aesthetic which apparently many find to have a kind of beauty.
>>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.
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.
Is this your speculation, or do you have a citation to back this up.
As I wrote, "I don't have any references around to back this up."
I used Perl for a few years about 10 years ago; was quite the perl evangelist at that job. Then I found Ruby, which won my heart. But I have a pick-cover copy of the book perl (yes, all lower case). And I've read the whole thing and liked Wall's jokes. :)
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.
Pure trolling.
Because whatever tries to replace them, ultimately ends up looking up very similar to them.
That's an amazing assertion for which I would like to see proof. FWIW, I don't think Haskell looks like any of those, a passing resemblance to Lisp notwithstanding.
Perl, et al may have been done right, but it's myopic to think they are some sort of end point of perfection, if only because we don't know all the things we want to do, so we don't know all the things we need to have, "done right" or otherwise.
"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."
As I wrote, "I don't have any references around to back this up."
I used Perl for a few years about 10 years ago; was quite the perl evangelist at that job. Then I found Ruby, which won my heart. But I have a pick-cover copy of the book perl (yes, all lower case). And I've read the whole thing and liked Wall's jokes. :)
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.
Pure trolling.
Because whatever tries to replace them, ultimately ends up looking up very similar to them.
That's an amazing assertion for which I would like to see proof. FWIW, I don't think Haskell looks like any of those, a passing resemblance to Lisp notwithstanding.
Perl, et al may have been done right, but it's myopic to think they are some sort of end point of perfection, if only because we don't know all the things we want to do, so we don't know all the things we need to have, "done right" or otherwise.
"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."
Perl, et al may have been done right, but it's myopic to think they are some sort of end point of perfection...
I'm not sure anyone will argue that seriously.
That's an amazing assertion for which I would like to see proof.
It's probably not true for Perl 5's concurrency and parallelism features, such as they are. (You get fork() and POSIX-style shared memory with IPC or a queue or RPC or whatever, and you like it.)
It's probably true for access to POSIX and other standards. (I can't remember the article here several months ago about how to write fast network code, but it's essentially "Embrace what Unix and Unix-like systems give you." It's not the article about the Varnish architecture.)
It's almost definitely true for module repositories, where it's not enough to track dependencies and mirror downloadable code bundles. Testing, change management, dependency resolution tracking, and documentation formats and presentation systems are essential. Not even CTAN gets it as right as CPAN.
I'm not sure anyone will argue that seriously.
That's an amazing assertion for which I would like to see proof.
It's probably not true for Perl 5's concurrency and parallelism features, such as they are. (You get fork() and POSIX-style shared memory with IPC or a queue or RPC or whatever, and you like it.)
It's probably true for access to POSIX and other standards. (I can't remember the article here several months ago about how to write fast network code, but it's essentially "Embrace what Unix and Unix-like systems give you." It's not the article about the Varnish architecture.)
It's almost definitely true for module repositories, where it's not enough to track dependencies and mirror downloadable code bundles. Testing, change management, dependency resolution tracking, and documentation formats and presentation systems are essential. Not even CTAN gets it as right as CPAN.
Pure trolling.
Call it whatever you like, but I have observed Python related posts/discussions experiencing a rapid decline. Clojure/Ruby et al are beginning to take more center stage now. In most discussions, which used to be generally a buzz with Python web frameworks these days doesn't even get a slight mention of Python.
Nothing wrong here, Python was the trend of the near past. There are newer trends these days. And there will other newer trends in the future. That's how it is, every couple of years. Something new comes to replace the famous. That's how technology works.
Now just because you don't like what you read, it doesn't automatically amount to trolling.
Call it whatever you like, but I have observed Python related posts/discussions experiencing a rapid decline. Clojure/Ruby et al are beginning to take more center stage now. In most discussions, which used to be generally a buzz with Python web frameworks these days doesn't even get a slight mention of Python.
Nothing wrong here, Python was the trend of the near past. There are newer trends these days. And there will other newer trends in the future. That's how it is, every couple of years. Something new comes to replace the famous. That's how technology works.
Now just because you don't like what you read, it doesn't automatically amount to trolling.
The author originally posted this article on his blog a few days before this one. If you ignore the trolling then there are some interesting comments on what Perl offers today: http://jjnapiorkowski.typepad.com/modern-perl/2011/10/why-pe...
Thanks. That one also doesn't require JS ("Why not JS"?).
(Call me old-fashioned)
(Call me old-fashioned)
Perl is also an awesome language for web automation and testing, esp with WWW:Mechanize and LWP.
Also the kind of freedom or strictness Perl offers to users is just unique. It's like slider on top. Building a website or project? then use strict, and warnings and objects. Want to write a quick and dirty csv parser? well just paste your code in the command line. How cool is that!
Also the kind of freedom or strictness Perl offers to users is just unique. It's like slider on top. Building a website or project? then use strict, and warnings and objects. Want to write a quick and dirty csv parser? well just paste your code in the command line. How cool is that!
I program in a variety of languages and Perl has formed a big part of that during the last 12 years. The one thing that all other languages seem to lack is the native support for regex that Perl has. Perl also seems to give the best regex performance of any language. Regex is the swiss army knife of text processing, which is most of what we do when building web apps. I'd like to see all major web languages support regex natively like perl does including things like:
$str =~ s/([a-z])/$myFunc->($1)/ge;
$str =~ s/([a-z])/$myFunc->($1)/ge;
A few years ago I did a lot of Perl work. Since I do interactive multimedia, I wanted to try my hand at game programming (Frozen Bubble is written in Perl, it couldn't be that hard, right?). At the time, however, the only graphics libraries were extremely limited, which forced me to work in different languages.
Recently, a new awesome SDL library has been created: http://sdl.perl.org/ that actually supports drawing lines on the screen! It's really tempting to make some perl games again.
Right now I'm using the Effect Engine which has a perl backend. It's wonderfully written and straightforward. Many of the "simple" things it does would have been a lot more complicated had they been written using other popular languages. The library support also means that extending anything is easy as pie.
Recently, a new awesome SDL library has been created: http://sdl.perl.org/ that actually supports drawing lines on the screen! It's really tempting to make some perl games again.
Right now I'm using the Effect Engine which has a perl backend. It's wonderfully written and straightforward. Many of the "simple" things it does would have been a lot more complicated had they been written using other popular languages. The library support also means that extending anything is easy as pie.
I made a few patches for SDL::Perl and I'm a fan. I also helped do some of the porting work on Frozen Bubble and Pangzero to the new APIs. It was pretty fun.
Perl isn't easy to learn because it's difficult to become familiar with it. However, I found it enjoyable to work with. It's certainly a little quirky but for a dynamic language it is also quite malleable. My example is Moose: Perl didn't ship with an OO system but is flexible enough that Perl6's object model could be back ported. Don't like Moose? There are others. Or you could just use straight blessed hashes (which Python, Ruby, and others just put syntactic sugar around).
For a dynamic language it's pretty nice. But I don't think it's going to be winning many converts these days. The tower of babel had fallen long ago and people are starting to pick up the pieces again. Languages that stray too far from the squishy middle of collective wisdom, I fear, are likely to relegate themselves to history.
That being said, Perl does have an excellent community. And I really like reading Perl books. They're really fun where too many are either dry or over-compensating in quirkiness. Perhaps its those unixy origins that still pull me to it.
Perl isn't easy to learn because it's difficult to become familiar with it. However, I found it enjoyable to work with. It's certainly a little quirky but for a dynamic language it is also quite malleable. My example is Moose: Perl didn't ship with an OO system but is flexible enough that Perl6's object model could be back ported. Don't like Moose? There are others. Or you could just use straight blessed hashes (which Python, Ruby, and others just put syntactic sugar around).
For a dynamic language it's pretty nice. But I don't think it's going to be winning many converts these days. The tower of babel had fallen long ago and people are starting to pick up the pieces again. Languages that stray too far from the squishy middle of collective wisdom, I fear, are likely to relegate themselves to history.
That being said, Perl does have an excellent community. And I really like reading Perl books. They're really fun where too many are either dry or over-compensating in quirkiness. Perhaps its those unixy origins that still pull me to it.
I've said it before and I'll say it again: other imperative scripting languages feel like incomplete subsets of Perl. And the community is fantastic.
This is the language that doesn't have proper function arguments, exceptions, objects, etc, and you're calling OTHER languages a subset? Sorry, I just don't see it. What exactly is so awesome in Perl that isn't easily done in Python/Ruby/Scala/D/Haskell?
> proper function arguments
> exceptions
http://search.cpan.org/~nilsonsfj/Error-TryCatch-0.07/lib/Er...
or just eval and see what the output is.
> objects
Edit: I was being an asshole Perl has a decent object system out of the box and Moose for those times when you want type constraints.
Lexical scoping, anonymous coderefs that can be passed as data, modifiable syntax, reference semantics, and the regex engine I see other languages comparing theirs too.
my ($a, $b, $c) = @_; # this works
my ($first, @rest) = @_;
> exceptions
http://search.cpan.org/~nilsonsfj/Error-TryCatch-0.07/lib/Er...
or just eval and see what the output is.
> objects
Edit: I was being an asshole Perl has a decent object system out of the box and Moose for those times when you want type constraints.
package MyClass;
use base 'Parent';
sub new { my $class = shift; bless { prop1 => undef }, $class; }
package main;
my $obj = new MyClass;
Lexical scoping, anonymous coderefs that can be passed as data, modifiable syntax, reference semantics, and the regex engine I see other languages comparing theirs too.
> giving me features which require all manner of annoying syntax in Python
def foo(first, *rest):
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
It's probably my Python deficiency. My claim that Python's syntax was going to be uglier is probably wrong, but I think the claim that Perl's is appreciably worse is also wrong. We can all get along!
Not sure I follow you. Your python example is very explicitly passing a _single_ arguement, a list of three items. If you call it the same way you call the perl code, you'd have the same result.
Exactly, it's a trade-off. Making the other side of the fence not impossible to reach, you just have to hop a little. Perl can easily be made nicer and Python can surely with ease be made more flexible.
use Method::Signatures;
func set (Str $key, Int $val) {
func set (Str $key, Int $val) {
Honestly, I am completely unsure why we are discussing this article, or why it showed up in a place like HN. It is clearly based on shutterstock's agenda in acquiring perl developers.
I coded perl full-time for a year, straight up, for 10+ hours a day -- using it as the glue to hold a rudimentary distributed system together.
To show that I myself am not biased, I will admit Perl has a lot of nice things, but it also has a lot of undesirable things. This article only concentrates on the former (and doesn't even focus on what could arguably be the right nice things to speak of).
I coded perl full-time for a year, straight up, for 10+ hours a day -- using it as the glue to hold a rudimentary distributed system together.
To show that I myself am not biased, I will admit Perl has a lot of nice things, but it also has a lot of undesirable things. This article only concentrates on the former (and doesn't even focus on what could arguably be the right nice things to speak of).
Perl was the first language I loved, and I'll always love it, but I'm sticking with ruby. No more my $self = shift
Also, Ruby's lack of @ $ % is great. And the fact that it has a single object model, not falling to the Paradox of Choice[1] makes it a great alternative to Perl.
And what is best: I've never seen anyone that loved Perl not enjoy Ruby. They both have very similar ideologies, but Ruby stands on the shoulders of Perl, Smalltalk and Lisp. Therefore it could see farther.
[1] http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More...
And what is best: I've never seen anyone that loved Perl not enjoy Ruby. They both have very similar ideologies, but Ruby stands on the shoulders of Perl, Smalltalk and Lisp. Therefore it could see farther.
[1] http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More...
"In Ruby, ordinary variables lack sigils, but "$" is prefixed to global variables, "@" is prefixed to instance variables, and "@@" is prefixed to class variables."[0]
Okay, I don't know Ruby well enough to know if these are commonly used features, but the statement that there are no sigils is false.
[0] http://en.wikipedia.org/wiki/Sigil_(computer_programming)#La...
Okay, I don't know Ruby well enough to know if these are commonly used features, but the statement that there are no sigils is false.
[0] http://en.wikipedia.org/wiki/Sigil_(computer_programming)#La...
@ 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...
http://www.tutorialspoint.com/ruby/ruby_predefined_variables...
Ruby even uses some predefined globals (eg $_) that are pretty much straight out of Perl.
They exist, and while I'm a fan of $: over $LOAD_PATH I don't think I've even seen $_ used in the wild.
They exist, and while I'm a fan of $: over $LOAD_PATH I don't think I've even seen $_ used in the wild.
I don't really have the perspective to comment on how common they are, but they do exist. Ruby is full of little things like this, which one of the things I simultaneously love and hate about Ruby
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.
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.
>>No more my $self = shift
E.g.:
E.g.:
use Method::Signatures::Simple;
method get_file_sizes(@files) {
# ...
}This is really just a checklist that can be applied to any language. So yes, why not Perl after all...
Hmm let's see.
"Perl Programmers love their language." Sadly not true enough for many languages. Does PHP programmers love their language like Perl programmers do for example? Somehow I doubt it.
"True Freedom" Perl is free and open source and most code is too. How does that compare to Java or the microsoft stack?
"Great Community" There are a lot of great communities surrounding most languages to be sure, but it's a stretch to say that any (every) language has it.
"CPAN" How would this apply to any language? There's simply nothing near CPAN anywhere. Ruby has gems and Haskell has hackage, but they aren't comparable to CPAN in size or breadth.
"Awesome Third Party Support" Is a language simply the syntax and the standard library or could the freely available libraries and tools be counted too? In that case Perl stands out as well, there's just so much of it. Can C or Java rival it? Sure, maybe, but most others won't even come close.
"Jobs" I wouldn't say that Perl has the highest job count out there, but compare it to Scala, Haskell, Go, Rust and many other and it's probably easier to get hired.
I like Perl, it's a fun language to use, but I'm not the biggest Perl advocate in the world. But it does do pretty good in the above points and to say it's a checklist that can be applied to any language is just untrue.
If there are good or bad points that's a whole other topic. I think they are pretty good points, and we must remember that this is an explanation of why they personally are using Perl. Find another language which does better on these points if you can, cause I can't think of any.
"Perl Programmers love their language." Sadly not true enough for many languages. Does PHP programmers love their language like Perl programmers do for example? Somehow I doubt it.
"True Freedom" Perl is free and open source and most code is too. How does that compare to Java or the microsoft stack?
"Great Community" There are a lot of great communities surrounding most languages to be sure, but it's a stretch to say that any (every) language has it.
"CPAN" How would this apply to any language? There's simply nothing near CPAN anywhere. Ruby has gems and Haskell has hackage, but they aren't comparable to CPAN in size or breadth.
"Awesome Third Party Support" Is a language simply the syntax and the standard library or could the freely available libraries and tools be counted too? In that case Perl stands out as well, there's just so much of it. Can C or Java rival it? Sure, maybe, but most others won't even come close.
"Jobs" I wouldn't say that Perl has the highest job count out there, but compare it to Scala, Haskell, Go, Rust and many other and it's probably easier to get hired.
I like Perl, it's a fun language to use, but I'm not the biggest Perl advocate in the world. But it does do pretty good in the above points and to say it's a checklist that can be applied to any language is just untrue.
If there are good or bad points that's a whole other topic. I think they are pretty good points, and we must remember that this is an explanation of why they personally are using Perl. Find another language which does better on these points if you can, cause I can't think of any.
Sadly not true enough for many languages.
But I think equally true for the languages considered its successors: Ruby and Python.
But I think equally true for the languages considered its successors: Ruby and Python.
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.
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.
Which also applies to that "great community" point. Shudder.
There are lots of great languages. I think we can learn from each other. Perl has a lot of problems but also a lot of strengths. CPAN is one of its strengths.
Compare CPAN: https://metacpan.org/module/Moose::Manual
Then compare with other repositories from other languages: http://stackoverflow.com/questions/1693529/list-of-top-repos...
CPAN does
* Documentation
* Historical versions of libraries
* Search
* Source code
* Integrated bug tracker
* Integrated review system
* Links to repositories
* Integrated automated tests regularly run against hundreds of machines/operating systems/perl versions.
Compare CPAN: https://metacpan.org/module/Moose::Manual
Then compare with other repositories from other languages: http://stackoverflow.com/questions/1693529/list-of-top-repos...
CPAN does
* Documentation
* Historical versions of libraries
* Search
* Source code
* Integrated bug tracker
* Integrated review system
* Links to repositories
* Integrated automated tests regularly run against hundreds of machines/operating systems/perl versions.
And also there is:
* CPAN Forum - http://cpanforum.com/
* Annotated CPAN - http://www.annocpan.org/
* Discussion/review on pre CPAN modules - http://prepan.org/
* CPAN Forum - http://cpanforum.com/
* Annotated CPAN - http://www.annocpan.org/
* Discussion/review on pre CPAN modules - http://prepan.org/
Sure but 99% of what I want is something that A. Has a library I want and B. can install it easily.
All those bells and whistles are nice. But they're not something I'm basing my technology stack on because most of the time theyre not something I need.
All those bells and whistles are nice. But they're not something I'm basing my technology stack on because most of the time theyre not something I need.
Honestly, the only point there that applies to any language is the "freedom" one. The rest are, with varying margins, real differentiators. Especially the CPAN ecosystem one. No other language has that.
Having worked on real-world projects in Perl, Python and Ruby, I can tell you that CPAN is not a differentiator. It doesn't matter if there are gazillions of packages to choose from. What matters is if I can find the packages I need to do the job. I remember working on a Perl project and being mocked by a Python guy because I had to implement a library that was already available for Python. On the other hand, I could choose from many different Perl packages to help me write classes and do things that Python does out of the box.
What was that library you reimplemented?
What are the differences between CPAN and, for instance, Maven repositories?
indeed, or pypi, or PEAR, and I'm sure ruby has something similar too
http://rubygems.org/gems 2005 gems listed at the moment.
All of those have a long way to go yet to match the CPAN ecosystem. See my reply above.
and as a user of packages, rather than a package developer, I care about precisely none of that functionality.
I want this package installed (plus its dependencies), and I want it now, that's all.
I'm not sure I buy that (paraphrased) "Perl is good because CPAN has billions more packages than other language's repos" either, for one I remember trying to find a library that did SHA1 digests, there were three, and I managed to pick the one that give incorrect results...
of course in Python it's just built-in, as are sockets, http, smtp, imap...
I want this package installed (plus its dependencies), and I want it now, that's all.
I'm not sure I buy that (paraphrased) "Perl is good because CPAN has billions more packages than other language's repos" either, for one I remember trying to find a library that did SHA1 digests, there were three, and I managed to pick the one that give incorrect results...
of course in Python it's just built-in, as are sockets, http, smtp, imap...
As a user of dists all that stuff is extremely important to you for two reasons:
For one, it means the dists are of higher quality because authors have better tools at their hands and get poked to increase quality.
For the other, as a user you can tell whether the dist works on your particular system without even installing it and if it doesn't, you can easily find out on what system it DOES work, or which previous version did work on your system: http://www.cpantesters.org/distro/M/Moose.html#Moose-2.0205
> I managed to pick the one that give incorrect results...
That's why there is a review system:
http://cpanratings.perl.org/dist/Email-Send http://cpanratings.perl.org/dist/Email-Sender
For one, it means the dists are of higher quality because authors have better tools at their hands and get poked to increase quality.
For the other, as a user you can tell whether the dist works on your particular system without even installing it and if it doesn't, you can easily find out on what system it DOES work, or which previous version did work on your system: http://www.cpantesters.org/distro/M/Moose.html#Moose-2.0205
> I managed to pick the one that give incorrect results...
That's why there is a review system:
http://cpanratings.perl.org/dist/Email-Send http://cpanratings.perl.org/dist/Email-Sender
I guess understanding why purely language bound code (which most likely accounts for 95% of the packaged code out there), e.g. an object system, would need testing across the cartesian product of all versions, all OSes and all archs, is beyond me...
I guess when you have a language that doesn't have a specification, you require things like this...
I guess when you have a language that doesn't have a specification, you require things like this...
It doesn't need it. It just gets it because the ecosystem is there and automatically does it for everything. The database interfaces get it, the Windows Process Memory access library gets it, the Hiragana learning tool gets it. Doesn't matter how big or small the project is, the service is provided for free, for all.
That is why i said the other languages have a long way to go yet; no matter how much you try to shift goal posts or resort to out-of-band attacks.
That is why i said the other languages have a long way to go yet; no matter how much you try to shift goal posts or resort to out-of-band attacks.
yes, but the point is if the utility provided by these "dists" would be mostly useless for other languages, then it's hardly honest to use said feature to promote CPAN (and therefore perl) against other languages.
the review system is a questionable advantage too, as I don't want to go digging through 16 SMTP packages to find the best one, and especially as I suspect most people install CPAN modules through the command prompt (or via their distro's package manager), rather than digging through a website.
I also note that Python tends to adopt the best packages into the standard library...
the review system is a questionable advantage too, as I don't want to go digging through 16 SMTP packages to find the best one, and especially as I suspect most people install CPAN modules through the command prompt (or via their distro's package manager), rather than digging through a website.
I also note that Python tends to adopt the best packages into the standard library...
> yes, but the point is if the utility provided by these "dists" would be mostly useless for other languages, then it's hardly honest to use said feature to promote CPAN (and therefore perl) against other languages.
Jeeze, you're barely making any sense. I have to wonder if you're trolling here. My point was about the utility of the ecosystem, which is useful for any language. The dists i mentioned are just examples of distributions you could find on CPAN other than Moose which all receive the same treatment.
> I suspect most people install CPAN modules through the command prompt (or via their distro's package manager), rather than digging through a website.
The installation is done via command line, but it is always preceded by research on the websites. Would you exclusively buy movies by title alone without looking at reviews?
> I also note that Python tends to adopt the best packages into the standard library...
Perl core developers do include useful things as well, but they are fairly strict about which ones, since they prefer to leave them on CPAN so they can be developed and released at a faster pace than the core. And in fact, the core is increasingly being viewed merely as a tool to access CPAN.
Jeeze, you're barely making any sense. I have to wonder if you're trolling here. My point was about the utility of the ecosystem, which is useful for any language. The dists i mentioned are just examples of distributions you could find on CPAN other than Moose which all receive the same treatment.
> I suspect most people install CPAN modules through the command prompt (or via their distro's package manager), rather than digging through a website.
The installation is done via command line, but it is always preceded by research on the websites. Would you exclusively buy movies by title alone without looking at reviews?
> I also note that Python tends to adopt the best packages into the standard library...
Perl core developers do include useful things as well, but they are fairly strict about which ones, since they prefer to leave them on CPAN so they can be developed and released at a faster pace than the core. And in fact, the core is increasingly being viewed merely as a tool to access CPAN.
Maybe I can put this arguement to rest.
It doesn't matter how competant your product is (CPAN) if you aren't delivering what the market wants.
Yes, CPAN provides a utility in the ecosystem, but most users do not use the extra features that CPAN provides over something like PyPi.
And even in the cases where there is a feature overlap (e.g. repository storage and breath), after a certain point things are "good enough" and theres a marginal return for adding more.
Does it matter if there are 17 SHA1 implementations on CPAN and 3 on PyPi? Not really, since you only need 1 good implementation. In fact it could be argued that having more implementations is worse due to paradox of choice.
It doesn't matter how competant your product is (CPAN) if you aren't delivering what the market wants.
Yes, CPAN provides a utility in the ecosystem, but most users do not use the extra features that CPAN provides over something like PyPi.
And even in the cases where there is a feature overlap (e.g. repository storage and breath), after a certain point things are "good enough" and theres a marginal return for adding more.
Does it matter if there are 17 SHA1 implementations on CPAN and 3 on PyPi? Not really, since you only need 1 good implementation. In fact it could be argued that having more implementations is worse due to paradox of choice.
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.
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.
[deleted]
Perl is my first choice go-to language, but I'm not finding the CPAN advantage as big as it used to be. Increasingly I'm having to use languages I don't prefer (not out of any hostility, just not as comfortable in them) because they have libraries that CPAN either doesn't include, or doesn't include with the same polish/functionality. For example, there doesn't seem to be anything in the Perl world as good as the Python Imaging Library (PIL); PerlMagick is featureful but not very fun to use. The data-visualization libraries are also way behind Python's matplotlib. NLP is a closer call, but overall I find NLTK better integrated and maintained than the stuff in CPAN, though CPAN does have modules for most things you might want to do. I'm currently using Perl for some simple GIS stuff, and the GIS packages also are pretty hit-or-miss.
Admittedly I might just not be good at finding the right packages. Python seems to have more of a culture of headline projects, which register their own domain names, like NLTK, PIL, numpy, etc., while Perl mostly has a big pile of CPAN modules, which range from excellent and actively maintained, to a script someone once wrote that's incomplete and hasn't been touched in 12 years.
Admittedly I might just not be good at finding the right packages. Python seems to have more of a culture of headline projects, which register their own domain names, like NLTK, PIL, numpy, etc., while Perl mostly has a big pile of CPAN modules, which range from excellent and actively maintained, to a script someone once wrote that's incomplete and hasn't been touched in 12 years.
Have you tried Imager[1]? It's what I'd recommend these days, but I don't have experience with image manipulation in any other language so I can't compare.
I agree that there need to be better ways to find modules. I have high hopes for MetaCPAN in this regard.
[1] https://metacpan.org/release/Imager
I agree that there need to be better ways to find modules. I have high hopes for MetaCPAN in this regard.
[1] https://metacpan.org/release/Imager
NLTK is great; it's one of a handful of headline projects that make Python worth knowing. (Pygame is another.)
I haven't found anything that makes GIS easy.
I haven't found anything that makes GIS easy.
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.
Perl's great because it has the power to do lots of things, quickly, and without alot of drama. It's dangerous because it's just good enough to keep some hastily written program around too long. Many "black box" processes written in unintelligible Perl by persons unknown haunt data centers all over the globe.
I enjoyed the time I spent with Perl immensely. But I spent it as a individual sysadmin/DBA turned developer integrating lots of complex systems on multiple platforms a decade ago. (For better or for worse, some of those apps are still working!) For a team of programmers in 2011, there are probably tools out there that will do the job better for the same price.
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.
Perl's great because it has the power to do lots of things, quickly, and without alot of drama. It's dangerous because it's just good enough to keep some hastily written program around too long. Many "black box" processes written in unintelligible Perl by persons unknown haunt data centers all over the globe.
I enjoyed the time I spent with Perl immensely. But I spent it as a individual sysadmin/DBA turned developer integrating lots of complex systems on multiple platforms a decade ago. (For better or for worse, some of those apps are still working!) For a team of programmers in 2011, there are probably tools out there that will do the job better for the same price.
> 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
Or, perhaps less literally, like a Swiss-Army chainsaw. http://catb.org/jargon/html/S/Swiss-Army-chainsaw.html
That's great... I somehow never ran into that before. Thanks!
Anyone using Perl 6?
What is your experience? Is it mature enough for serious use or should we stay with Perl 5?
This article http://perlgeek.de/en/article/5-to-6 shows a glimps of the features of Perl 6.
What is your experience? Is it mature enough for serious use or should we stay with Perl 5?
This article http://perlgeek.de/en/article/5-to-6 shows a glimps of the features of Perl 6.
Is it mature enough for serious use or should we stay with Perl 5?
Stay with Perl 5.
Stay with Perl 5.
The great downfall of Perl is that it's slow:
http://shootout.alioth.debian.org/u64/which-programming-lang...
60X slower than C. 30X slower than Java
If sed/awk/grep/sort/tr is not up the task, sure, try Perl for those one offs. For serious computation? Fuggedit.
60X slower than C. 30X slower than Java
If sed/awk/grep/sort/tr is not up the task, sure, try Perl for those one offs. For serious computation? Fuggedit.
> The great downfall of Perl is that it's slow:
What about Perl6 and LLVM?
My personal experience with Perl5:
- It has incomparable expressiveness. Only APL is more expressive. But more expressiveness makes source code less readable.
- Perl's regexp engine is the best - no doubt about it.
- I would never use Perl for big projects. Its odd syntax ($, sometimes %,... before variable names etc.) is terrible for long term maintainability.
What about Perl6 and LLVM?
My personal experience with Perl5:
- It has incomparable expressiveness. Only APL is more expressive. But more expressiveness makes source code less readable.
- Perl's regexp engine is the best - no doubt about it.
- I would never use Perl for big projects. Its odd syntax ($, sometimes %,... before variable names etc.) is terrible for long term maintainability.
What about [Perl 6] and LLVM?
No Perl 6 implementation is mature enough to use for practical purposes.
LLVM probably won't help Perl 5, because Perl 5 lacks sufficient type information, and because LLVM's design really seems to want static languages. See also the JVM and the CLR.
Its odd syntax ... is terrible for long term maintainability.
I would never attempt to maintain code written in a language I don't know.
No Perl 6 implementation is mature enough to use for practical purposes.
LLVM probably won't help Perl 5, because Perl 5 lacks sufficient type information, and because LLVM's design really seems to want static languages. See also the JVM and the CLR.
Its odd syntax ... is terrible for long term maintainability.
I would never attempt to maintain code written in a language I don't know.
> I would never attempt to maintain code written in a language I don't know.
I know Perl 5 well enough but will my successors also? Is Perl still rising? I don't think so.
I know Perl 5 well enough but will my successors also? Is Perl still rising? I don't think so.
I know Perl 5 well enough but will my successors also?
That sounds like a hiring and training question.
That sounds like a hiring and training question.
> That sounds like a hiring and training question.
Yes, Fortran, APL and Ada had the same questions.
Yes, Fortran, APL and Ada had the same questions.
If only they had a CPAN growth rate to measure.
"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 authors, the frequency of updates, and the freshness of versions, you'll see that Perl 5 is far from stagnant.
I'm suggesting that if you measure the amount of code submitted to the CPAN, the number of authors, the frequency of updates, and the freshness of versions, you'll see that Perl 5 is far from stagnant.
> 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.
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.
> 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
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
> marketing of perl core dev is terrible
A link "Current Developments" in perl.org would be helpful. Thanks for the links but I'm not interested in minor changes of Perl 5 (Unicode etc.). I was very interested in the new features of Perl 6.
No matter, I lost my patience and left Perl years before and returned into the Lisp and Scheme world where I was before. Sometimes I still use Perl 5 but merely for small scripts.
Perl 6 got stuck in Parrot while Lisp enjoys a revival in Clojure, Qi/Shen and Racket Scheme which are all usable and under heavy development.
The new Lisp versions support multiprocessors and compile to JVM, Javascript (V8), Lisp, Scheme or C. Lisp and Scheme macros are still superior. In Qi/Shen I can even write attribute grammars in BNF style. I can compile my source to standalone native EXE files which are really fast. For that reason I prefer Scheme and Lisp over Python and Ruby. I don't need Perl 6 anyymore!
A link "Current Developments" in perl.org would be helpful. Thanks for the links but I'm not interested in minor changes of Perl 5 (Unicode etc.). I was very interested in the new features of Perl 6.
No matter, I lost my patience and left Perl years before and returned into the Lisp and Scheme world where I was before. Sometimes I still use Perl 5 but merely for small scripts.
Perl 6 got stuck in Parrot while Lisp enjoys a revival in Clojure, Qi/Shen and Racket Scheme which are all usable and under heavy development.
The new Lisp versions support multiprocessors and compile to JVM, Javascript (V8), Lisp, Scheme or C. Lisp and Scheme macros are still superior. In Qi/Shen I can even write attribute grammars in BNF style. I can compile my source to standalone native EXE files which are really fast. For that reason I prefer Scheme and Lisp over Python and Ruby. I don't need Perl 6 anyymore!
So if I compile a busybox-like crunched binary with a variety of "do one thing well" UNIX utilities, including sh itself, and then I write a shell function that only calls this single binary it its various incantations and uses pipes and temporary files residing on tmpfs or mfs (instead of reading entire files into memory the way perl does), and this binary used like this can do all that Perl can do, why should I use Perl?
That's my question.
That's my question.
So, if I can build a wagon with a lawnmower engine from parts, and it is able to putter down the street (barely) faster than I can walk, why should I use a car?
That's my question.
I'm a sysadmin. I have been for years. My coworker calls me "the encyclopaedia of Linux", because I know all the command line tools, their functions and features, and how to tie them together. I write one-liners that are 5 lines long. And I like it. I love the Unix philosophy and design and tools.
But, that doesn't make it a perfect fit for anything. Shell scripts are very limited and painful for a lot of things. When I'm writing something I expect to be 50 lines or less, shell scripts and *nix utilities will usually (not always, but usually) get the job done (especially if you include sed/awk in there). For anything more than that, I break out Perl and I never regret it.
Complicated logic, non-trivial data structures, multiple chains of processing, these are things that just don't do well with shell scripts and tools. It's also a lot cleaner and simpler using a real data structure, instead of forcing everything into pipes and temporary files.
Note: Your comment of "instead of reading entire files into memory the way perl does" shows your ignorance. Perl is an immensely flexible tool, and it gives you the ability to process files line-by-line, stream-style, or by reading the entire file into memory. Both methods are trivial, and having the choice means you can use whichever method is appropriate for the task at hand (your comment suggests that reading the whole file is somehow "wrong", but for many tasks it's a faster and cleaner method).
That's my question.
I'm a sysadmin. I have been for years. My coworker calls me "the encyclopaedia of Linux", because I know all the command line tools, their functions and features, and how to tie them together. I write one-liners that are 5 lines long. And I like it. I love the Unix philosophy and design and tools.
But, that doesn't make it a perfect fit for anything. Shell scripts are very limited and painful for a lot of things. When I'm writing something I expect to be 50 lines or less, shell scripts and *nix utilities will usually (not always, but usually) get the job done (especially if you include sed/awk in there). For anything more than that, I break out Perl and I never regret it.
Complicated logic, non-trivial data structures, multiple chains of processing, these are things that just don't do well with shell scripts and tools. It's also a lot cleaner and simpler using a real data structure, instead of forcing everything into pipes and temporary files.
Note: Your comment of "instead of reading entire files into memory the way perl does" shows your ignorance. Perl is an immensely flexible tool, and it gives you the ability to process files line-by-line, stream-style, or by reading the entire file into memory. Both methods are trivial, and having the choice means you can use whichever method is appropriate for the task at hand (your comment suggests that reading the whole file is somehow "wrong", but for many tasks it's a faster and cleaner method).
* [If] ... this binary used like this can do all that Perl can do...*
If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.
If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.
It's actually a very small job.
The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it.
If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise.
I want to learn Perl. But I just cannot find the motivation because I never need more than what UNIX gives me.
The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it.
If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise.
I want to learn Perl. But I just cannot find the motivation because I never need more than what UNIX gives me.
> If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise.
Here again, your ignorance is showing, and you are projecting your own limitation onto others. You suggest that someone who uses Perl feels the need to use it everywhere, that it's more complex than shell tools, and that Perl somehow becomes a crack-like addiction, forcing you to never use command line tools again.
That's just plain silly. There are tons of people who make heavy use Unix tools and Perl. This isn't an either-or situation like you seem to be pushing. They're all just tools for solving problems. The smart thing is to recognize when each tool is appropriate, and then use them properly.
For example, the other day I was working with a log file. Initially, I was beating on it with command line tools: find, grep, cut, sed, sort, uniq, wc, etc. Eventually, I got what I needed out of it, but knew I was going to need something more to present to my team, so I pulled out awk, and I wrote a little script to extract the data and generate a simple report. A few days later, management saw the report, and liked it. But, they wanted some additional features added, and some changes to the processing. I could have hacked what they wanted into the awk script, but the processing had gotten complex enough that I knew I was better off making the jump to Perl. So, I rewrote it in Perl, and got everything they wanted. Additionally, it had the flexibility with Perl that the next two feature requests that management made were implemented in just a few minutes each.
Also, in case you weren't aware of it, Perl integrates and happily makes use of external commands. If there's a tool out there that will do some heavy lifting for you, Perl makes it trivial to call out to that command (just like backticks or $(/bin/foo) in bash).
If you really want to do complex scripting with Unix tools, then you're either limiting yourself to pretty trivial work, or you're making things a lot harder on yourself than they need to be. Perl was created for a reason, and it's a good one. Small scripts or glue to tie things together, use a shell script and Unix tools. Complex scripts, use a real scripting language, make things easier on yourself, and get more work done in a faster, better way.
Here again, your ignorance is showing, and you are projecting your own limitation onto others. You suggest that someone who uses Perl feels the need to use it everywhere, that it's more complex than shell tools, and that Perl somehow becomes a crack-like addiction, forcing you to never use command line tools again.
That's just plain silly. There are tons of people who make heavy use Unix tools and Perl. This isn't an either-or situation like you seem to be pushing. They're all just tools for solving problems. The smart thing is to recognize when each tool is appropriate, and then use them properly.
For example, the other day I was working with a log file. Initially, I was beating on it with command line tools: find, grep, cut, sed, sort, uniq, wc, etc. Eventually, I got what I needed out of it, but knew I was going to need something more to present to my team, so I pulled out awk, and I wrote a little script to extract the data and generate a simple report. A few days later, management saw the report, and liked it. But, they wanted some additional features added, and some changes to the processing. I could have hacked what they wanted into the awk script, but the processing had gotten complex enough that I knew I was better off making the jump to Perl. So, I rewrote it in Perl, and got everything they wanted. Additionally, it had the flexibility with Perl that the next two feature requests that management made were implemented in just a few minutes each.
Also, in case you weren't aware of it, Perl integrates and happily makes use of external commands. If there's a tool out there that will do some heavy lifting for you, Perl makes it trivial to call out to that command (just like backticks or $(/bin/foo) in bash).
If you really want to do complex scripting with Unix tools, then you're either limiting yourself to pretty trivial work, or you're making things a lot harder on yourself than they need to be. Perl was created for a reason, and it's a good one. Small scripts or glue to tie things together, use a shell script and Unix tools. Complex scripts, use a real scripting language, make things easier on yourself, and get more work done in a faster, better way.
You wrote a website with only the shell and unix utilities?
I write small, simple shell functions using a single busybox-like binary that do the same things as Perl modules. I store the shell functions in a local repository and load/unload them as needed. I make "programs" by combining different functions.
There’s nothing that can’t be said about any other scripting language from their respective fans.
Perl is easily the worst language I have ever had to use. I just can't stand it. Maybe perl 6 changed everything, but I thought perl 5 was such a terrible hack.
Perl blah Perl Perl Perl? Perl! Also, did I mention Perl?
To be honest i don't agree at all (actually i'm all for letting Perl die except for little scripts less then 100 loc):
Perl Programmers love their language:
Me (and colleagues) had to use Perl for some projects and i can't say i love the language at all. I understand it, i can write it and i am constantly underwhelmed, disappointed and sometimes disgusted. The point is that Perl is sort of a zombie in many businesses and runs often enough that it can't be ignored and often enough has to be maintained.
True Freedom:
Probably yes, but "and often can find the core developers in charge of some code" really doesn't apply anymore.. i browsed a lot through CPAN and a huge part of modules hasn't been touched for years (i can't count how many modules i've seen from 2001).
Great Community:
I certainly wouldn't bash a whole community, it sure may be great, but when searching online you get the feeling it died years ago (most posts are ooooold). perlmonks.org is often a good resource, but beyond that... the IRC channels i know are more idle then other languages (by far).
CPAN:
True, a big selling point for Perl is the huge amount of libraries on CPAN. But it's really untrue to say "there is nothing like it" (PIP for example).. Same point as above, a big amount of CPAN seems to be not maintained anymore, there are many modules with unsolved bugs.. just a few examples of widely used modules that haven't been updated for years and have open bugs:
And i just went through search.cpan.org hit some "buzzwords" and checked the results, there is a BIG amount of modules nobody looked at for years. I'm not saying that there is no development at all, but often enough i think "mhh, should i even use this module? Nobody seems to care about this anymore". Certainly the most important libraries are actively maintained for sure, no doubt about that!
Awesome Tools:
Yes sure.. Moose is a good example of what's wrong.. it's trying to bring object system to a language that wasn't even remotely designed to support modern language features. Not to bash Moose, i like Moose, it's good! But it tries to solve a problem that shouldn't be there in the first place.
Another creepy example:
Want to have exceptions in Perl? Turns out the language doesn't have them.. There are modules.. all of them do some black magic trying to emulate this. The number one google hit (Error.pm) even states "Using the "Error" module is no longer recommended due to the black-magical nature of its syntactic sugar, which often tends to break.". And this is not some fancy 2011 language feature, it still isn't built in! What's also not built in? Perl thinks it's ok when you read an uninitialized variable. Want the script to terminate when this happens? You'll have to implement and change signal handlers and take care of it yourself when other modules try the same... ugh.. Want to know if an element is in an array? There are some hideous for loops you could do, but nothing like "if X in Y".. best thing: Most recommended way to do this is to convert your array to a hash/dictionary and check for the key.. that's basic array handling.. I could go on with this list for weeks but i fear this is already too long of a text..
Jobs:
Yes, where i live it doesn't matter. As IT guy it's unbelievable easy to get a job, that has nothing to do with the language. At least where i live.
My criticism on Perl:
- Perl lacks basic language features of a modern language (Exceptions, Array Handling, Error Handling, Unicode Support is horrible and so much more)
- In general Perl code from different programmers looks very different, because basic things can be done equally "well". This and a hideous syntax leads to really hard to read code unless you know every way a Perl program can be written (and i'm sure not even Larry Wall knows that)
My fun fact on Perl:
- Did you know that Parrot (the Perl6 VM) won't have a Perl5 interpreter because it's next to impossible to craft a 100% perl5 compatible parser.. at least they gave up early.
I've had the highest WTF-count while reviewing other peoples code by far(i may at one day put my prime example on thedailywtf.com).
Now this will get me a massive downvote, but this is my Perl experience. I can only beg people:
When your script/tool exceeds 100 lines of code, don't use Perl! Atleast not if there is the remote possibility of another human being having to understand or maintain it. Please!
[edited for some paragraphs, but well... not as readable as i'd like it to be, sorry!]