First, Perl takes some unique approaches to programming language design, and that will stretch your brain and make you a better programming. New concepts and ideas (to you), particularly ones with a long and proven record, are almost always worthwhile.
Secondly, Perl is incredibly useful. It's still my go-to choice for a most things that need more than can easily be done as a shell script, but don't have a specific reason why I should use a different language. I find that Perl is more fun to code, and it's incredibly efficient for getting things done. If you're doing anything that involves text processing, Perl is still king, IMO.
One note: Perl style shifted significantly about ~15 years ago with the "Modern Perl" movement. This was a good thing, and you should ensure that any books or articles that you work with take advantage of those modern approaches. This can largely resolve the "write-only" complaints that some people have about Perl. Which, to that point, I'll note that it is very easy to write very readable and easily maintainable Perl code. Use a recent version of Perl and make sure you always have strict and warnings enabled!
Also, if you're wanting to do OO, check out Moose, Moo, or Perl's newly released OO class system.
"Perl 5 has been on the same major version for 30 years now"
I don't know that I would consider that accurate. 'Perl 5' is really no longer a version, but the language itself. It's had a lot of "major" releases over the last ~20 years and it's evolved significantly in that time. Sure, the language does prioritize backwards compatibility, but that is common among many programming languages. New features have been added regularly, however, and 'Modern Perl' brought around a lot of change in style and approach from the Perl of 30 years ago.
If you're doing some sort of processing where you're calling an external script hundreds or thousands of times, you're probably doing it wrong. You should be writing it to get called once and process your input as it comes in.
That goes regardless of language. If you're calling an external "thing" thousands of times to process something, you're going to have issues with performance because the approach to processing the data is bad.
You can get away with it to a point by using only the most simple and basic of tools (cat/cut/tr/echo/grep/etc), but one of the common reasons that shell scripts get rewritten in Perl/Python/etc is to process data without making hundreds of thousands of calls to spawn external processes.
I'm not sure I understand your complaint/concern. We're talking about text chat and video chat clients, and you're concerned with giving them access to your contacts? How are you going to contact your contacts with the apps if they don't know who your contacts are?
All communication apps are going to require access to your contacts so that your contact information can be used to communicate with your contacts. Duo and Allo are tied to phone numbers. They use phone numbers to identify users, so without access to phone numbers (contacts), they can't function. This is the same as all text message (SMS) clients, and the same way that many other chat clients work (Signal, WhatsApp, etc.).
Times change. IBM-style "professional" is not the "anal retentive, by the book pedantic clock puncher" you might think. I worked there over 10 years ago, and we had no written dress code, flex-time scheduling, remote work, etc. The building I worked in had a 9 hole putt-putt course outside it, with foosball tables in a couple of the stairway landings.
Interesting how long we can hold on to perceptions from the past, even when they've been wrong for over a decade.
(I'm not implying that I'm disagreeing with you, in fact I think this shows that even what people think of as "pedantic clock puncher" and "fun loving rock star" from the outside is often very different on the inside.
I think it's a pretty weak reason to give up on a language because you were using a global variable and expecting it to automatically be treated as a local variable within your function.
As others have mentioned, you are using a global variable ($_) inside a function. This is generally considered a bad practice.
The standard perl idiom of getting your function arguments via shift would make this a non-issue.
I found the statistics to be quite interesting. The conclusions drawn by the author, however, left a lot to be desired. Most of them were not directly (or even indirectly) supported by the data, and consisted primarily of random opinions that left me feeling negatively about an otherwise interesting post.
I would have also like to see data on the mean for some of the statistics, and not just the median. In some cases, one or the other can provide very misleading statistics, and providing both to compare would have helped smooth over concerns there.
I think you make some very good points, but I have to disagree rather strongly with this one:
> My general experience with DBAs, sysadmins, techs and the like is that they generally resent you for asking them to do things, making the entire experience unpleasant. I'm not sure if such people are attracted to such positions or such positions end up making such people but whatever the case, "surly" is a commonly appropriate adjective to use.
I've spent 15 years working in a variety of positions in IT, from tech support, to developer, to sysadmin, to supervisor, to architect/design engineer. My experience with DBAs and sysadmins is that they rarely resent you for asking them to do things. However, they may very well resent the way you ask them to do things.
Much of modern society is very me-focused, impatient, and with short attention spans. This goes double for the corporate business world. When many people run into a technical problem, they tend to want an immediate response and an immediate resolution to their problem, expecting everyone else to drop everything and attend to them. Their problem affects them, therefore it is the most important problem around right now.
What they fail to appreciate and understand, is that many DBAs and SysAdmins are supporting systems and infrastructure that has importance much greater than you. Yes, you have a problem, and yes, they want to help you. But they have visibility into things with potentially much greater impact than you, and those things may have a higher priority and importance than your problem.
An example I saw just a few weeks ago. I had a problem that needed attention from a sysadmin. I went to the guy who could fix it, and there was someone already at his desk. I waited outside his cube, and listened to the guy already there bitch at him. Apparently the guy had an application that was having issues, and he couldn't work on his report until the application was fixed. He wanted the sysadmin to drop everything to fix it, and he wasn't happy at being told that the sysadmin was busy with something else, and couldn't help him until it was fixed.
After yelling guy finally left, I ducked my head in and asked him if something was blowing up. He nodded distractedly and said that the server a PostgreSQL database ran on was misbehaving, and that the DB was utilized by an application used by 3 different business units and dozens of people. I offered my sympathy, told him I needed his help, but it could obviously wait until he fixed this problem, and said I'd e-mail him the details.
He thanked me for being understanding (twice), and called me as soon as he'd fixed the server issue to help me out.
> The cliche of the bearded UNIX purist exists for a reason.
I'm afraid you're going to have to explain the reason for this one. The bitchiest guy I know at work is clean shaven, and the nicest guy I know has a full beard. Exactly what reason is there behind your negative beard perception? ;-)
Yeah, I found the title to be misleading and quite annoying. It should definitely be fixed to clarify. To the vast majority of the IT world, Apache == Web Server, not Apache Software Foundation.
First, Perl takes some unique approaches to programming language design, and that will stretch your brain and make you a better programming. New concepts and ideas (to you), particularly ones with a long and proven record, are almost always worthwhile.
Secondly, Perl is incredibly useful. It's still my go-to choice for a most things that need more than can easily be done as a shell script, but don't have a specific reason why I should use a different language. I find that Perl is more fun to code, and it's incredibly efficient for getting things done. If you're doing anything that involves text processing, Perl is still king, IMO.
One note: Perl style shifted significantly about ~15 years ago with the "Modern Perl" movement. This was a good thing, and you should ensure that any books or articles that you work with take advantage of those modern approaches. This can largely resolve the "write-only" complaints that some people have about Perl. Which, to that point, I'll note that it is very easy to write very readable and easily maintainable Perl code. Use a recent version of Perl and make sure you always have strict and warnings enabled!
Also, if you're wanting to do OO, check out Moose, Moo, or Perl's newly released OO class system.