Earlier quoted context omitted.
Sorry you had to deal with that. Do you think it would have been easier to deal with 25k lines of spaghetti garbage in a file named .py?
I think it actually probably would have been - not an ideal way to write code, but Python is certainly easier to read than your average Perl.
Dwindling CPAN Releases
161–170 of 180 posts
Re: Dwindling CPAN Releases
#162Earlier quoted context omitted.
Perl 5.001 is really old (25 years or so), and lots has changed since then. v5.10 introduced a barrel-full of new features; other important features like the "use v5.10" syntax for supporting older scripts didn't land until much later (v5.16). Where I work, a few of our legacy systems are still dependent on ~v5.10, which can be a real pain when trying to port code back to legacy. I agree that the Python versioning pr…
The "use VERSION" syntax is fundamentally much older. It used to strictly just assert a minimum version. It also, pre 5.6, required floating point versions ("use 5.005"). In newer versions of perl, this syntax will also invoke "use feature " which allows the use of incompatible new features in its lexical scope. One example is that "use 5.12;" and above will turn on "use strict" in the lexical scope. I fought long an…
Re: Dwindling CPAN Releases
#163I used Perl for a bit but switched to Python because I was finding it harder to work out what some code I'd written a year or so ago did than to write it again, a problem I don't have with Python.
Re: Dwindling CPAN Releases
#164I still use perl for handy one liners on the command line. E.g. I had a 1 GB log file where I wanted to generate a histogram of the intervals between certain log messages. I used a perl one-liner to extract the timestamp via regex (regexs are perl's bread and butter), calculate the diff between the previous timestamp (easy because of auto string => double conversion), use the diff value as a key in a hash of counters…
Re: Dwindling CPAN Releases
#165Earlier quoted context omitted.
From a experienced linux sysadmin point of view perl5 is as good as it gets. I've been searching for alternatives for about 10 years now, at first because my novice self was heaving headaches reading other people code and even my own. I hated perl but I hated everything else even more as I came to know them. No autovivification? Some assignments copy the data and some create references and you need to memorize the co…
Autovivication seemed like a great feature to me, back in the day, when I was getting started with Perl. Working with similar data structures in languages like Python always seemed like a chore. I had heard a few perl monks criticize it a bit, as an "end run around use strict ", but I was kind of dismissive. It turns out, that's a really apt way to describe it. It basically tosses the niceties of use strict out the w…
Re: Dwindling CPAN Releases
#166Earlier quoted context omitted.
This post reminded me that Perl doesn’t even have a concept of a method signature, even so much as showing the number of arguments. You have to look at the next few lines to hopefully see all the `... = shift;` lines to see what you’re actually supposed to send. I mean, a lack of type annotations is normal for a scripting language, but Perl always seemed to go a bit far by not even having a standard way of showing pa…
I usually do sub mymethod($$) my ($arg1, $arg2) = @_; } Apart from on the smallest programs. So it does have a method signature (obv it's an untyped language) There are shortcuts (just like you could write "doSometing() unless $var;"). Perl does give you options. Python has different options for passing methods - passing variables, passing a dict, P.S. while looking at python method declartions, you can send variable…
That does not work. Prototypes are ignored for method calls. You are expected to not abuse prototypes for signatures as they serve a different purpose.
> it's an untyped language
That's wrong even with the most lenient/charitable interpretation. Using an unexpected type of data is a fatal error.
perl -e'$x = {}; $x->[0]; print "survived"'
Not an ARRAY reference at -e line 1.
Type constraints have existed for a very long time, for example see http://p3rl.org/Kavorka::Manual::Signatures#Type-constraintsRe: Dwindling CPAN Releases
#167I think Perl was fighting on too many fronts at the turn of the century: web, systems automation, data processing, science and a few more. Today these areas are better covered by other languages that have hefty internet buzz and corporate support behind. Perl also has no shiny features. It's just extremely dynamic and paradigm agnostic, great at shell interactions and natural at text processing (specially with regexe…
> web, systems automation, data processing, science and a few more. doesn't this apply to python, although now there are additional competitors? > reinvented itself as a web language (Mojolicious, Plack). highly opinionated and potentially flame creating , but - perl was the original web language in the CGI era, PHP pretty much dethroned it due to simplicity of server integration, rails knocked them both out of 'lead…
I love Perl but I'm currently looking at around a decade of experience which is really hard to take into a new role. I'm working a bit on Wordpress now but PHP is basically close enough to Perl for me that it sits in a weird uncanny valley where I get things just wrong enough to cause headaches every time.
Re: Dwindling CPAN Releases
#168Earlier quoted context omitted.
The most obnoxious parameter passing in existence? The magic variables everywhere? Perl code is an unreadable heap of spaghetti, I’d much rather be figuring out unallocated memory bugs in C then read Perl.
Is its function parameter passing really more obnoxious than python, which lets you mutate the default parameter across calls: def foo(bar=Bar(1)): Unless bar is a primitive type, in which case each invocation gets the same value? def foo(bar=1): Perl wears its idiosyncrasies as badges of honor. Python keeps them hidden so they can sneak up on you when you least expect it.
Re: Dwindling CPAN Releases
#169Earlier quoted context omitted.
If 1 out of 100 people fail to do a thing, it doesn't mean that thing is bad...
1 out of 100 might be understating it, though. Or it might be overstating it. Who knows? As another data point, I've had very few good experiences with Python. The primary exception has been with PyQt5, and chiefly by going with Qt's conventions instead of Python's (i.e. being as Qt-like and un-Pythonic as possible).
https://stackoverflow.com/questions/54831915/python-3-5-2-in...
> I want to run this on a production Server with ubuntu 16.04. My Sysadmin tells me that I shall not use pip or github repository, because of ... something wrong with using anything but apt ... he says.
Sysadmin is right.
First response?
> sudo apt-get install python-pip
Now there are ways to convert modules to debs (or rpms on redhat style machines) so they can be managed cleanly across an estate, but that's not the python way.
Re: Dwindling CPAN Releases
#170Earlier quoted context omitted.
Wanted to use Python 3 for some processing but the Sysadmin said that only Python 2 was available for that distributions version and "didn't want to frankenstein the box"
What about installing miniconda in your home folder? How ancient is that system?
This is not how you deploy software