151–160 of 180 posts
Earlier quoted context omitted.
25k lines of spaghetti garbage - all in one file.
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?
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…
That being said, I'm a professional dev and we own a decent amount of perl. That codebase is by far the most difficult to work in out of anything we own. New hires have trouble with it (nobody learns perl these days). Lots of it is next to unreadable.
I agree that like any other language, perl can be written well and can be written poorly. That being said, perl makes it _really_ easy to write something poorly, in contrast to something like python which is a bit more rigid and tries to have one right way to do things.
I still use perl pretty extensively for little one liners, but at this point we are actively trying to get rid of as much perl that we own as possible. We find that rarely writing anything longer than 10 lines should be done in perl, if only from a readability and maintainability standpoint.
I love perl. It was THE game changer for many many years. But perl is falling out of fashion quick.
I'd have no problem working in the language with some very rigid guidelines and a bunch of experts.
But the reality is that nobody is hiring perl experts, perl experts are becoming more and more scarce, and most new hires have a bit of experience with py or rb. I dont dislike perl, I'd just argue it's almost always the wrong thing tool for the job these days.
In a previous life I worked at a large E commerce company. You've likely ordered from them. Pretty much everything ran on perl/perl Mason for over a decade. At that time perl was the cool new thing that everyone wanted to pick up. Now (or when I left a few years back), most of that code represented a liability if it needed to be changed.
IMO this is just the cycle of a programming language.
I remember reading Spolsky articles where he talks about VB6 like it's some shiny new amazing scripting language, akin to python 10 or so years ago. But alas, time moves on and so do most programmers.
Earlier 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.
But why obnoxious? Do you know how old Perl is? Have you written shell scripts before? My point is, some of choices Larry and others made wouldn't necessarily be made today, but there's a history, a lineage, a reason for all of this. I actually like the magic variables, but as I said in my other comment, you need to learn it first. X language is an unreadable heap of spaghetti if the programmer writes X language in a…
Same age as Haskell.
Perl is the language I once understood when I used it everyday but now look at with utter confusion. It's definitely not a casual language. As a comparison, I peeked at some Delphi/pascal code I'd written and a book a few weeks back and it was still parseable by my brain years later.
No languages are casual. I wrote Perl for about 5 years and was super productive with, but haven't looked it for quite a while. Most energy these days goes into JavaScript/node and it devolves into gibberish really, really quickly. The community really dove into the punctuation-based syntax, preprocessors and meta languages head first and created a real Frankenstein. And they'll complain that Java or C# are too verbo…
Not sure I agree with that. Languages which share widely used conventions and syntax can be picked back up much more quickly.
Earlier quoted context omitted.
>Some assignments copy the data and some create references and you need to memorize the conventions of which does what? This is a nightmare for beginner coders trying to make sense of Pandas or R subsetting.
I don't think there's any way to avoid that. You could always copy, but then you'd sacrifice performance. You could always make a reference, but then other parts of the language would become really complicated.
Earlier 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.
Don't forget sigils. Because the difference between @foo and $foo is obvious, right?
$ → S → scalar
That's how I learned and remember them.
What makes that less obvious is when you work with references to arrays; the reference itself is a scalar, so it gets the scalar sigil. You can dereference it, though, by sticking an array sigil in front of it, thus telling the interpreter "hey, this is a scalar reference to an array".
Earlier quoted context omitted.
> Almost anything can "work" Yet after yesterday's attempt to get a small cherrypy webserver running, python doesn't.
If 1 out of 100 people fail to do a thing, it doesn't mean that thing is bad...
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).
Earlier quoted context omitted.
I used python for a bit but switched to Perl because it 1) Works 2) Is ubiquitous 3) Is stable 4) Is normal (semicolons, braces etc)
> 2) Is ubiquitous On which systems do you have Perl readily available but not Python?
Not that installing Python is especially difficult, but still.
I'd need to do some more polishing before putting it up on GitHub or something (namely: sanitize incoming single-quotes in CSV cells, and possibly break the steps into subroutines), but I was yet again impressed by the ability to automate a bit of text data processing with less than an hour's work.