ccashell

It can definitely be worthwhile.

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.

For many languages, the implementation and spec are completely separate entities. Many of the biggest ones, actually: - C - C++ - Java - JavaScript

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.

> If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise.

Here again, your ignorance is showing, and you are projecting your own limitation onto others. You suggest that someone who uses Perl feels the need to use it everywhere, that it's more complex than shell tools, and that Perl somehow becomes a crack-like addiction, forcing you to never use command line tools again.

That's just plain silly. There are tons of people who make heavy use Unix tools and Perl. This isn't an either-or situation like you seem to be pushing. They're all just tools for solving problems. The smart thing is to recognize when each tool is appropriate, and then use them properly.

For example, the other day I was working with a log file. Initially, I was beating on it with command line tools: find, grep, cut, sed, sort, uniq, wc, etc. Eventually, I got what I needed out of it, but knew I was going to need something more to present to my team, so I pulled out awk, and I wrote a little script to extract the data and generate a simple report. A few days later, management saw the report, and liked it. But, they wanted some additional features added, and some changes to the processing. I could have hacked what they wanted into the awk script, but the processing had gotten complex enough that I knew I was better off making the jump to Perl. So, I rewrote it in Perl, and got everything they wanted. Additionally, it had the flexibility with Perl that the next two feature requests that management made were implemented in just a few minutes each.

Also, in case you weren't aware of it, Perl integrates and happily makes use of external commands. If there's a tool out there that will do some heavy lifting for you, Perl makes it trivial to call out to that command (just like backticks or $(/bin/foo) in bash).

If you really want to do complex scripting with Unix tools, then you're either limiting yourself to pretty trivial work, or you're making things a lot harder on yourself than they need to be. Perl was created for a reason, and it's a good one. Small scripts or glue to tie things together, use a shell script and Unix tools. Complex scripts, use a real scripting language, make things easier on yourself, and get more work done in a faster, better way.

So, if I can build a wagon with a lawnmower engine from parts, and it is able to putter down the street (barely) faster than I can walk, why should I use a car?

That's my question.

I'm a sysadmin. I have been for years. My coworker calls me "the encyclopaedia of Linux", because I know all the command line tools, their functions and features, and how to tie them together. I write one-liners that are 5 lines long. And I like it. I love the Unix philosophy and design and tools.

But, that doesn't make it a perfect fit for anything. Shell scripts are very limited and painful for a lot of things. When I'm writing something I expect to be 50 lines or less, shell scripts and *nix utilities will usually (not always, but usually) get the job done (especially if you include sed/awk in there). For anything more than that, I break out Perl and I never regret it.

Complicated logic, non-trivial data structures, multiple chains of processing, these are things that just don't do well with shell scripts and tools. It's also a lot cleaner and simpler using a real data structure, instead of forcing everything into pipes and temporary files.

Note: Your comment of "instead of reading entire files into memory the way perl does" shows your ignorance. Perl is an immensely flexible tool, and it gives you the ability to process files line-by-line, stream-style, or by reading the entire file into memory. Both methods are trivial, and having the choice means you can use whichever method is appropriate for the task at hand (your comment suggests that reading the whole file is somehow "wrong", but for many tasks it's a faster and cleaner method).

> A basic problem: Perl allows them to hack away all day and write hideous code that ensures they will never get fired. Due to their laziness the script will be undocumented, lack basic error checking, will have myriads of bugs and often fail, but no one except them will be able to fix it in a reasonable time frame.

Can you provide me with a link to any non-toy programming language for which this isn't the case? I've seen beautiful code in a lot of languages, and I've seen god-awful ugly code in a lot more. I don't think I've ever found a language that doesn't have some ugly code written in it, though.

> This is where you will be upset and think i am really unjust and a troll: I'm stating that Perl supports this behavior like no other language. (except maybe brainfuck ;) )

Well, when you offer up a statement that applies to essentially every programming language in existence, and then suggest that it only really applies to Perl, I can see where they might get that impression. A programming language is just a programming language. It's programmers that write it, and a poor programming can, and will, write piss-poor code in any language.

> My basic statement about Perl: It is possible to write readable, tested and maintainable code in Perl. BUT it is hard if not impossible with just the base language. It is by far easier to get it wrong then to get it right in Perl for the newcomer or average programmer.

No offense, but that's just flat out silly. First of, it's not at all hard to write readable, tested, and maintainable Perl in the "base" language.

Beyond that however, saying "just the base" language is very misleading and shows either ignorance or malice. Perl, by design, maintains a moderate "core". It doesn't ship with every module included. That doesn't make it hard to access additional functionality (such as Moose, Test::More, and thousands of others). That's a simple design decision, and isn't good or bad, it's simply a matter of trace-offs.

By your logic then, C is a horrible language, because it's almost impossible to write "readable, tested and maintainable" code with the base language, right? I mean, it has no object oriented functionality, no testing framework, and a very minimal standard library. What were they thinking? How is anyone supposed to get work done with C?

Oh, right. They get the libraries they need, and get stuff done. Just like in Perl. Only, in C you don't get CPAN to take 99% of the effort of finding and installing libraries out of the equation.

I'm a sysadmin who does development on the side.

When I start writing something, I think about how big I expect it to be. If it's expected to be 50 lines or less, then it's bash for general scripts, and awk for text filtering. If it's expected to be more than 50 lines, I go with Perl. That goes regardless of platform (as it's already available on every *nix platform I use, and Strawberry or ActiveState makes Perl easy to add on Windows).

Well said.

Sometimes a new tool will come along that truly is a huge improvement on previous tools. But, when those previous tools are "classics", it's pretty rare that the "new" tool is truly that much of an improvement.

There's a reason that these things (bash, sed, awk, perl, SQL, Unix/Linux, etc) are still popular and still going. It's because they're time tested, they're well known, and they work.

Agreed. Ruby is very popular in a few smallish circles. It's still essentially unknown pretty much everywhere that isn't a small web-based startup.

Yeah, I'm gonna have to completely disagree with you here.

I'm a sysadmin that does a decent amount of automation and scripting work. Almost all of that is done in Perl. Among the other guys on my team, everyone uses Perl, except for one person who uses Python.

We had one person who came into the team as a Ruby fan. Within 6 months of working with us, she'd become a Perl fan. She told me she'd passed on Perl and gone to Ruby because she'd heard bad things about Perl. After seeing it in use and checking it out a little closer, she realized that almost everything she'd heard "bad" was outdated, incorrect, or overstated.

Outside of my team, I know lots of people who use Perl, a decent number of people who use Python, and a very small number of people who actually use Ruby. Yeah, there's a few high-profile apps in it, and yeah, Ruby on Rails got it a lot of attention for quick and dirty web apps, but it has a long way to go before it'll reach anywhere near Perl (or even Python) is.

I hate PHP. Personally, I just don't like the language. However, it's still incredibly popular in the web world.

As for the rest? Ruby on Rails was super hot a year or so ago, because it was a new concept in simplicity for certain types of web apps. However, Perl and Python both have comparable frameworks that are just as good now, and in the minds of a lot of people, better. Rails does have a bit of a reputation for limited scalability, compared to Perl and Python solutions.

Realistically, the scalability of your application will be limited by your database design and application architecture to a far greater extent than the language you use. In all but a few special cases, Perl, Python, Ruby, and eve PHP will be fast enough, assuming you don't create bottlenecks with the application design.

Personally, I would go with Perl. I like the language, I love the rapid advances and direction it's taken in the past couple of years, and I think Moose and Catalyst are awesome. However, it sounds like this is for something of a startup, so the language you write the app in should be whichever one the developer writing it is most comfortable with. You want them to be at maximum productivity, and that'll happen with their preferred language. Find the right person, then pick the language.

Careful with that assumption. In my experience on a recent project, finding Perl developers was a good bit easier than finding Python developers. Generally, though, I think both are pretty prevalent.

The only problem I've had with Perl programmers is that a lot of the more casual Perl programmers (those who aren't exclusively Perl) tend to not keep up with the (significant and important) advances in Perl from the last 2-3 years.

I think it's worth it for a very small number of people. They note that a top school will cost you $50k per year in tuition. If you figure 2 years for an MBA, that's $100k. If you invested that for 30 years at 5% interest, it comes out to $432k. Very close to the difference in lifetime earnings between a Bachelor's degree, $2.7 million, and an MBA, $3.2 million (all numbers are from article).

I also think an MBA has become a bit diluted. Lots of people have them, and that's reduced the wow factor. Heck, having an MBA is even the butt of jokes (http://www.youtube.com/watch?v=NcoDV0dhWPA). Now, I'm not saying an MBA is bad, but I don't think it has the same prestige that it did 10, 15, or 20 years ago. There are definitely still some industries and some people who view them in very high regard.

I don't think it's worth getting an MBA "just because". Analyze the industry you work in and your career goals, and decide based on that. For most people, however, I think you might be better off getting the knowledge on your own (something like Josh Kaufman's Personal MBA concept (http://personalmba.com/manifesto/)).