141–150 of 180 posts
Earlier quoted context omitted.
> 1) Works Almost anything can "work" > 2) Is ubiquitous So is awk, don't write software in it. > 3) Is stable This will become questionable as Perl slips into non-maintained mode. > 4) Is normal (semicolons, braces etc) Perl syntax is very far from "normal"
> Almost anything can "work" Yet after yesterday's attempt to get a small cherrypy webserver running, python doesn't.
Earlier quoted context omitted.
All the "big" Perl codebases I've worked with were as readable as I'd have expected any "big" codebase to be, if not better. What was your experience like?
25k lines of spaghetti garbage - all in one file.
Earlier quoted context omitted.
Which one? Python 3.5.x or 3.7.x or something else? Version 3 should be version 3. Anything written in 3 ought to work on every Python 3. Not so in the Python world. And that makes it a mess to use (unless you Dockerize every script). Perl 5 is Perl 5 everywhere.
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…
I work on a large, legacy codebase (the oldest modules date from the mid-nineties) that's slowly being rewritten from Perl into Python. A handful of developers have been involved with the project from the beginning. Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language. Unsurprisingly, the person who produced the most unreadable, unmaintainable code is…
The biggest problem I have with Perl is like C++, the language is so stupidly big that every single programmer knows a different subset of the language.
I used to bump into this problem when I was interviewing for VLSI jobs and somebody would always do the "Let's talk about Perl" round. I was quite fluent at Perl at the time, and there would ALWAYS be some idiom that would stump me.
I solved this by bringing my own Perl program on a printout with me--I also brought the Python version of the same program with me. Suddenly, the interviewer was in MY subset of Perl and almost always went "Oh, you're a lot better at Perl and programming than I am" instead of dinging me for not knowing weird Perl trivia.
Earlier quoted context omitted.
"There should be one — and preferably only one — obvious way to do it.” In practice, perl came closer to achieving this than python.
Minus the dozens of cryptic special variables.
There's so much negativity in this thread. I think that a big part of Perl's decline is exactly because of people's attitudes. I don't actually write any Perl now, but to me it's a beautiful language, I always enjoy working in it. You can abuse it in the wrong way like every other language. If I was to suggest using it in the day job there would be uproar probably. But just because I like Perl doesn't mean I want to…
Earlier quoted context omitted.
That was the point they were making, that you can write horribly ugly code in Python if you really put a lot of effort into it, and that you can kinda sorta write readable Perl if you put a lot of effort into it.
If one is marginally literate, one cannot read or write coherently.
... in any language.Earlier quoted context omitted.
"There should be one — and preferably only one — obvious way to do it." That is a python design principle https://en.wikipedia.org/wiki/Zen_of_Python Now there are multiple (sometimes very confusing) ways to import stuff in python, so I am not quite sure if this principle is being followed. https://realpython.com/absolute-vs-relative-python-imports/
The other place where this principle is completely ignored is when it comes to Python packaging, which is a complete and utter disaster. There are many different ways to package Python, none of them are feature complete, and the result is an absolute maintenance nightmare for those of us who have to maintain tools that have Python dependencies. Perl got packaging right, there's one way to do it, and it just works!
Earlier 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?
Earlier quoted context omitted.
What about installing miniconda in your home folder? How ancient is that system?
Possibly CentOS, which requires python 2.7 even now.
No matter, that system is going to be decommissioned and functions will go over to a new EL7 install.
It just stalls that project till the new server is ready.