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.
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.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']
The correct answer should've been:
@list = grep { $_ ne 'dogfood' } @list;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?
> 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.
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.
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..
> 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.)
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.
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.
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.
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...
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.
I'm just confused how this precludes inclusion of Perl5 in Perl6.
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!]