Oh My Glob
hoelz.ro
hoelz.ro
A new admin comes along in 3 years time, and doesn't know the difference between , \, \, $?, $@, $&, $$, or gets confused between [] type ifs and [[ ]] ifs and 'test -' type ifs in BASH. Or doesn't know which variety of escape quotes are needed for which variety of strings.
Python has so much less "non-alphanumeric semi-random-combo" syntax.
Even though often a 3 line perl script would do the job, I prefer a 20 line python script that is easy to grok.
A new admin comes along in 3 years time, and doesn't know the difference(...)
It's not a mark on the language but rather one on the understanding of your potential successor. Would the same sysadmin who is unfamiliar with [[ vs [, or $ vs @, be handily equipped to do common system administration tasks? Rebuild a degraded software RAID array? Troubleshoot a faulty network interface? Chances are comparatively slim.
Lowest common intelligence? Sounds like anyone unfamillar with perl is stupid.
Perl is very different from other languages an has a very special syntax. The only way to REALLY understand perl is reading and writting lots of perl code from different authors.
In perl nearly every problem can be solved in many different ways.
If you are used to one style of perl you might still have trouble understanding the code someone else wrote.
No, someone who uses things they don't understand without looking at the documentation is stupid. One could similarly make such comments about the user interfaces of vi or emacs, and get the justified response to RTFM. Only in programming languages is RTFM apparently not expected.
> The only way to REALLY understand perl is reading and writting lots of perl code from different authors.
No, the way to understand Perl is to read the documentation. There is nothing special to Perl about this and the same applies to any language. Just look for example at how many blog posts are written to explain with() and decorators in Python.
> In perl nearly every problem can be solved in many different ways.
The same is true for any language.
> If you are used to one style of perl you might still have trouble understanding the code someone else wrote.
Only if you don't read the documentation.
I disagree, that's sometimes the best way to learn something. I learnt C, Java and Perl just by ploughing in without reading anything. Change something, see what happens, if it doesn't make sense ask Google.
Also programming languages aside, I never read computer game manuals before playing
I learned Perl the same way and play my games the same way, but when i write code that'll be used for anything that isn't frivolity, out comes the documentation to ensure the code doesn't destroy cash (or worse, lives) by the fistful.
I've watched people who didn't know python edit existing python scripts and make the change they wanted. To be fair, I've seen the same thing happen with well-written perl scripts - but only the kind that don't use [[ vs [ or the hundreds of random $* variables.
What does that even mean?
Thanks for the last bit though. Perl has been in heavy use since the late 80s and a LOT of shitty legacy Perl has been written, while the Modern Perl renaissance only started in 2005. Many people still think all Perl looks like legacy Perl 4 style code and it's an image that's been hard to get rid of.
Maybe because Perl 6 adds even more obscure and magical operators?
However, people don't care to look and judge books by their cover, so you're probably right that it's a part of the reason.
You are the reason why people hate dealing with IT.
Talking about a 3 line Perl script doesn't make a nice comparison. Multiply those numbers by a minimum of 1000.
Now you have a 3000 line Perl script Vs 60000 line Python program.
Suddenly you go from one person writing a Perl script,to 10 people writing the same in Python.
I've written > 3000 line Perl scripts quite a few times.
Once it's beyond the difference between a one-line regexp/fork-to-shell/reverese combo type thing that perl is so great at, most of the code becomes your actual business logic, and logic code I feel ends up being similar lengths in perl, ruby, python, and other similar languages.
Python has more boilerplate to get at regexps, or calling external programs and doing stuff with the output, say - but it's explicit. Perl has a lot more built in, and hidden behind non-alpha syntax.
Both are great languages, and both have their place. I much prefer python, but also find perl a very versatile and useful tool.
That's just the very start, the very beginning of what Perl is good at. Read this book called "Higher Order Perl" by Mark Jason Dominus. You will see why 60000 line Python program actually becomes a 3000 line Perl program.
>>most of the code becomes your actual business logic, and logic code I feel ends up being similar lengths
No,
You must take a serious look at Perl. Please read the book I mentioned.
Some languages do make it very easy to write short, powerful, clear succinct code.
More importantly you need to work in situations where Perl can show its magic. I've written scripts in a week alone which were easily 6 month Java projects.
Could you please (1) give a couple of concrete examples that don't involve regular expressions (yes, Perl is very good with hairy REs; no, very few 3000 line programs consist mostly of REs) and (2) indicate your level of expertise in Python?
Thanks!
Python does not guarantee garbage collection at scope end. Thus you need code like this:
def controlled_execution(callback):
set things up
try:
do something
finally:
tear things down
class controlled_execution:
def __enter__(self):
set things up
return thing
def __exit__(self, type, value, traceback):
tear things down
with controlled_execution() as thing:
some code
Thus, file opening and using code for example can look as simple as this and contain zero gotchas and no "you need to understand this to actually know what it does":
sub do_a_thing {
my $file = io->file(".bashrc");
print $file->slurp;
}Since python's file class already implements the with protocol, I don't see how
sub do_a_thing {
my $file = io->file(".bashrc");
print $file->slurp;
}
def do_a_thing:
with open(".bashrc") as f:
print(f.read())
> Thus objects can carry their teardown around in their class definition (which can be easily modified by overriding or wrapping the method in a new class)
is any different from implementing the with protocol in the class, which is strictly speaking "carry their teardown around in their class definition"
Python has a __del__ method that will be called on destruction, but is not guaranteed to be called in the case of cycles. That's what the with statement solves, guaranteeing destruction at the end of the block. It's common to have both __del__ and __exit__ call the same thing.
http://eli.thegreenplace.net/2009/06/12/safely-using-destruc...
Also, even with largely text-based programming you can run into obscure issues very easily. See for example:
if a in b.keys()
vs.
if a in b(For those not familiar with the genius masterpiece that is Adventure Time: http://adventuretime.wikia.com/wiki/Lumpy_Space_Princess )
One of my favorite design elements of perl is the ability to lexically declare "Ok, now for some magic!" (aka "no strict 'refs';") while keeping strict checking in effect throughout the rest of the code.