Why I hate Perl (discussion)

Replies are listed 'Best First'.
Re (tilly) 1: Why I hate Perl (discussion) by tilly (Archbishop) on May 16, 2001 at 22:46 UTC
I assume that the above has to do with your questions at at Icky Gross and Disgusting @INC Kludges. (code, discussion) and Cross-developing in 5.005 and 5.6 (code). And the presentation that you mentioned in chatter last night. Well as I suggested in both my responses, I think you dug your own pit there. Don't blame your screw-ups on other people. Now you may think that everyone should be using the latest and greatest. Well I know you are wrong. Systems are developed using whatever you have available, and migrating to a new system is something that should be done with care. A sysadmin who goes about changing the production environment without a change plan is a sysadmin who is more of a liability than they are worth. For a random instance, take a look at Re: regex (\G) vs. (^\G). You may rant and rave about not using deprecated features all you want. But /(^\|\G)foo/m is not the same as /\Gfoo/m, and the difference is not supposed to be a deprecated feature. In fact I don't know at the moment whether I have code that will be hit like this when I go to do that upgrade. Nor is that a problem with me this is a bug in Perl, pure and simple. But every major release of every system is going to have bugs like that. Which is why you have to give people the chance to test their code and fix it when new versions come out. No matter how responsible I am - and believe me I try - you have to plan for Murphy. And now a personal note. You have several posts where you brag about how good you are, how you have nothing left to learn from the stuff that is being said around here, yada, yada, yada. Well I don't believe it. I am constantly learning from stuff around here. merlyn likewise says that he learns. Are you saying that you have less to learn than we do? Judging from your posts and your code, I certainly see things that you need to learn. If you are not learning them, it is not for any lack of material to learn or potential for outside input. And lesson number one that I hope you learn is that it is your job to cooperate and work with the outside world, and not vice versa. Furthermore when things go wrong, don't start blaming and ranting. Whether or not you can find an appropriate target for blame, and whether or not that labelling is appropriate, it is generally a useless thing to do. Instead ask yourself, What could I have done differently up front that would make this mess less likely to happen, or less damaging if it did? Is that a change that I can reasonably make? It may not be as satisfying to do that. But it is going to get better results. And what, after all, did you want to do?	[reply]
Re: Re (tilly) 1: Why I hate Perl (discussion) by cforde (Monk) on May 17, 2001 at 00:53 UTC
A sysadmin who goes about changing the production environment without a change plan is a sysadmin who is more of a liability than they are worth. That might sound like an insult, but it is a hard fact. A sysadmin's primary job is it provide a <emphasis>stable</emphasis> environment for the users of that environment. Given a stable environment other things can be done like running production applications that make the business money. That's the whole point of the exercise anyway. Isn't it? Before making changes on a production system they need to be tested on a <emphasis>test</emphasis> system that closely mirrors production. That way when they go into production you know what to expect and can plan for it. In any case, you need to have a backout plan, yes even for the test system, in case things go south. It seems to me that much of your grief comes from a lack of planning. Expecting to be able to upgrade software, any software, and expect everything to continue to work the way they always have is foolhardy. Newer isn't better until it has been proven so. Have fun, Carl Forde	[reply]
Re (tilly) 1: Why I hate Perl (discussion) by deprecated (Priest) on May 17, 2001 at 03:32 UTC
The word you're looking for is Cocky. So maybe you didnt use it because you didnt want to be that harsh, or perhaps (as I hope is the case) you didnt use it because you and I are on pretty friendly terms. Maybe it seems like a little too much of a word to put on a thread that was clearly intended to be pros e, and to be discussion. Well... Youre damn right, Cocky. I have had an interesting day watching the --'s and ++'s roll in. The post is at a positive rep, but I have lost as many XP as there ar e rep. At a 1/3 chance of a loss, that means I have gotten in the neighborhood of 24 --'s and the same number of ++'s. Gosh, I feel lik e princepawn. So maybe, everyone, pull up a chair and check your egos at the door. I'll happily explain why I'm Right And You're Not (tm). I'll explain the scenario, and then add qualifications so you all know that I am not just blowing smoke up the collective ass of the mo nastery. So lets assume a large company has a not very large division. This division is concerned with a large website, which handles a large vo lume of traffic. Lets also say that there are 2 dba's, 2 unix admins, and 2 software developers. For the sake of discussion, everyone i n question is using Solaris -- although the organization also has a slew of Windows boxes. For some reason, the dba's hate the software developers. For some equally obscure reason, the software developers hate the dba's. This situation has gotten so out of hand that I was brought in as a consultant to fix some of the problems we've been having between so ftware developers, software testers, and database administrators. Everybody thinks everyone else is at fault for a huge number of probl ems. Namely, the software sucks. It does what it is supposed to do, but is fragile, and static. You touch it, it breaks. footpad, whose reply to my above node will reply to (if I find the time) separately, makes the excellent comment about administrators unwilling to install modules with CPAN.pm. Well, that is where this particular journey into Dilbertsville begins. I have developed code the likes of which have simply never been seen at this company. It uses warnings and strict. It uses modules rath er than reinventing every wheel in the book. It doesnt make system, qx, ``, open PROG, "foo\|" calls. Its all perl. I am met with sidewa ys looks when I suggest that something is easily fixed with perl because -- even though this is a perl development department -- the pe rl scripts around are causing problems. Theyre fragile, they need human help, and so on. You've all seen stuff like this before and if you havent, youre lucky. So, when I started writing code that required the module Mail::POP3Client and also the HTML::* modules, I realized that before it was moved from my perl install in my home directory to the development server (mind you this is pre-dev code), that I would have to have modules on the dev server. So I sent the unix guys an email asking for about 12 modules. This morning, I came in to the first meeting of the day, which was "Why the database sucks in a nutshell." Basically, the database is r eturning errors in a manner that the perl scripts dont like. The users then see errors that arent very explanatory, and they would like that to cease. For complicated reasons, it seems easier to fix the database than to fix perl (does perl seem to you like something tha t is un-easy to fix? me, neither!!). At this meeting, I learn that "you broke perl on the dev server. X section of the website is DOWN." Well, apart from the fact that I di d not actually touch perl (remember, I'm not root here), I found it preposterous that installing perl modules would break anything. The yre simply not an issue unless you use them. So after the meeting, I went to go talk to the unix guys. Apparently what has happened is that perl has been upgraded from 5.0053 to 5. 6.1. Now knowing what the problem is, I went over to the SW guys and asked what the problem was. "Well, the new perl handles data differentl y when youre passing variables." (thats a direct quote!) I explained that I thought this was probably not correct, and sat down to look at the code. The first thing I did was fix two typos. This could have been avoided entirely by simply using strict and warnings. Do they care? No. The second thing I did was point out that, no, you're not supposed to invoke a module that way. You need to: `use CGI qw{ :standard };` [download] if you want the standard stuff out of CGI. I'm not going to go into detail with the rest of this code. What I will tell you is it was h opelessly <!- FUCKED!!!!!!!!!! FUCKED!!!!!!!!!!!!!!!!!!!!!!!!! -> broken. I could not get either of the SW people to explain to me what the problem was, nor could I get them to reproduce it. My next suggestion was "well, just switch your shebang to `#!/usr/local/bin/perl5.003`. Fat chance. The fact here, though, i s we have at LEAST five other installs of perl all in separate places, all with their own correctly named binary in /usr/local/bin. If your code requires 5.0053, USE THE CORRECT BINARY! The admin, bless his heart, went and made the symlink in /usr/local/bin/perl back to /usr/local/bin/perl5.0053, and informed me that sh ould I want to use 5.6.1 that it was there and correctly named. Now, We have a name for this. When a user comes to me (as an admin) and says "my blah is broken" where "blah" is the name of the progra m that they feel is the center of their existence, I attempt to figure out what the problem is. I go and look around at permissions, lo gs and the like. When a user comes to me and says "you broke my blah", I tend to get a little pissed. If I then go looking and find tha t they are doing some egregiously WRONG and STUPID things, we use this great (if mean) word. BDU Yeah. Brain Dead User. You <!- FUCKED UP !!! -> are having a problem, and youre blaming it on something else, because it couldnt possib ly be you. And you know what, software developers can be BDU's. So, lets get back to my original post. I think that while my point wasnt subtle, it took a little bit of time for your average user to read it and understand I was not in fac t saying I hate perl. Would I be here if I hated perl? <!- give me a fucking break. -> I think one of the things we overlook when we fi nd somebody who hates perl is that they indeed may have a good reason for it. Maybe you asked them to install a module, and then whined that they broke perl when YOU could have been a more responsible programmer. Maybe they had a bad experience with the world's worst co de (I am convinced that I am dealing with that code now, but I'm sure many of us have horror stories.). Now, tilly, friend, lets look at what you added as a personal note here. I'm being rather cocky. Well, the fact of the matter here is I have got experience and I am a good perl coder. I do pretty good work. I've also been coding in perl for a while. I have been doing perl professionally for almost two years, and coding in it about four. I have not however said that "I am x good perl coder" where x is a quantity above what you think it should be. I have said that what I need to learn to progress as a perl coder I am not finding here. In fact this is true. In order to be a better perl programmer, I need experience. MeowChow correctly asserts that my code reflects a background that I think many of the monks here simply dont have. We see a lot of m onks with no C knowledge, and certainly no shell background. My code is different -- but it works. It may not be the most perfect algor ithmically, but often times I <!- dont give a fucking shit. not a fucking shit. -> am not aiming for a mathematical beauty. My skills l ie in diagnosing problems and proposing fixes for them. Randal has mentioned that my code is sometimes ugly. I'll be the first to admit that. But I have a firm grasp of perl's syntax and mechanisms. What I am learning now, which is making me a better perl programmer (and I dare say a worse !perl programmer), is from experience. Tryi ng to find ways to blend readability with stability and efficiency are teaching me new tricks. So dont insinuate I am claiming to be the be-all and end-all of perl programmers. I think you would agree that I have at least a reason able facility for spotting <!- SHITTY -> poorly written code. In fact my employer thinks so, and that is what I am getting paid for. A wholesale audit of a site that just doesnt work when put under pressure. So I maintain here that I am right. and I was right. and maybe, possibly, people didnt think before they sent --'s my way. its also qui te possible that I <!- just shouldnt give a shit. -> shouldnt worry. princepawn doesnt, and I dare say he is the better man for it. I like what he has to say, and I think people unfairly jump the gun on him. Any unix admin in their right mind, working this site, would shudder at the thought of these perl developers running loose on their ser vers. Yes, thats a soapbox. Yes, I'm stepping down. brother dep. -- Laziness, Impatience, Hubris, and Generosity.	[reply] [d/l] [select]
(dws)Re: Re (tilly) 1: Why I hate Perl (discussion) by dws (Chancellor) on May 17, 2001 at 09:32 UTC
What you've described is a people problem, not a technical one. For whatever set of reasons, the organization has descended into being a "blaming" culture. The technical aspects are just symptoms. Exchange Perl for Java, and it'd be "same song, second verse". If it's easier for people to stand around and point fingers at each other than it is for them to work together, look towards what's incenting (and what's not punishing) that behavior. Chances are good that a substantial part of the cause is higher up the organizational food chain than you've been looking at (or can see). There may be a protracted executive turf war going on. People aren't incented to work together because that might mean less blame for one exec to heap upon another. People aren't punished for pointing fingers because that's exactly what the execs are doing. If it's been going on, unresolved, for quite a while, most of the good developers will have moved on, and you might consider doing the same.	[reply]
Re: (dws) 2: Why I hate Perl (discussion) by deprecated (Priest) on May 17, 2001 at 14:11 UTC
(Ovid) Re: Why I hate Perl (discussion) by Ovid (Cardinal) on May 16, 2001 at 20:13 UTC
You bring up a point that many programmers fail to grasp: we're a team. A few members of the team, in no particular order: Programmers System administrators Database administrators Janitors Secretaries Sales representatives ... many, many more... Hubris can be one of the cardinal virtues of programmers, but they misunderstand. Hubris can be defined as excessive pride, but in the case of programming, it should be defined as "the quality that makes you write (and maintain) programs that other people won't want to say bad things about." Lamentably, too many programmers are arrogant enough to think that they are the most important element. Our office manager handles much of the paperwork for me. I have never had to bill a client here. Our sales rep is excellent and is pulling in quality contracts for us. We have a cleaning lady who comes in weekly and makes my life much easier (and knows better than to rearrange my files). Without them, and many others, I wouldn't have my job. It's a team effort and everyone needs to understand how they can rely on the others (and that means trusting the others). Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply]
Re: Why I hate Perl (discussion) by Masem (Monsignor) on May 16, 2001 at 20:59 UTC
One of the problems that you're describing is the fact that the programmers B&M when you install a new perl version over the old one, and you wonder why they aren't using the latest and greatest in features and avoiding those that have gone by the wayside. This attitude makes the sysadmin look like a jerk. A sysadmin must be able to communicate with the users of a system, not only to inform them of upgrades and changes, but to also listen to users who need certain features. Just because you know the root password does not allow you to act like you are their manager. At nearly every site I've been at with shared machines, the sysadmins would announce major changes to software at least 2 weeks in advance if not sooner (with several reminders in between). If the software was a minor change, it would usually be installed right over the existing one, while major changes would involve shuffling directories and scripts from the sysadmin end to make sure that both the old and new versions were usable. In cases where old versions had to be dropped (as supposed any more than 2 major revisions of software is a pain), the users were given several months of time to prepare, and in rare cases, the old version was installed on a specific low-use machine for those users that could not abandon it. In nearly all cases, there was also a way to access the cutting-edge versions of programs as well, but you had to ask the right people. But as with the old versions as well as these versions, the sysadmin flatly stated that no tech support will be available beyond standard problems. And to the best of my knowledge, the sysadmins worst complaints were that people didn't know what pine's "Reply to All?" meant, and why it was on by default (in reality it wasn't, but users always hit 'y' anyway for this). In addition, this doesn't just apply to perl. C, C++, Java, and major applications all have similar possible problems with new features and outdated functions. Perl might be a faster moving target than those, but the same ideas still apply: the sysadmin must be in communication with their users at all times in order to do an effective job, instead of acting like a god that does magical things when they feel like it. Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain	[reply]
Re: Re: Why I hate Perl (discussion) by poqui (Deacon) on Oct 26, 2001 at 00:39 UTC
To me, a lowly developer, the complaint that 'Developers B&M when I upgrade perl and it breaks their code...' should never occur. Change Management system are put into place just for this situation. Mr. Sysadmin decides that there should be an upgrade from Gofer 1 to Gofer 2. He should be submitting a Change Request to the Change Management Committee, comprised of Sys Admins, sys engineers, and developers. His request is reviewed and Ms. Developer says, "Wait! You can't change that yet, it will break all my code!!!" So a schedule and or a project plan is put into operation to either justify the upgrade and prepare the code for such, or to deter the Sysadmin from performing the upgrade until the reasons for it outweigh the reasons against it. "That that is, is... for what is that but that? and is but is?" Shakespeare, Twelfth Night, Act IV, Scene 2 "Yet THAT which is not neither is nor is not That which is!" Frater Perdurabo (pseud. Aleister Crowley), Liber CCCXXXIII, The Book of Lies	[reply]
Re: Why I hate Perl (discussion) by footpad (Abbot) on May 17, 2001 at 01:00 UTC
Preface: The following isn't personal, dep. Your node just happened to tread very heavily on a very sore toe right now and what follows may seem inflammatory. It isn't meant that way. Please read generally when you think I'm getting personal. I agree with your sentiment that everyone needs to be responsible for making sure they're doing the right things, for using the most idiomatic approaches available, and for learning as much as possible as the tools they're working with. However, I think you may be overstepping things a bit by not acknowledging your part of the process. As a SysAdmin, it's your job to help ensure that the developers have the information available and to help make certain they know how to obtain the information they need. One of the most frustrating things I'm going through right involves a set of unknown network admins who are clearly ignoring the advice and tips I'm trying to give them. I've built this very simple file-upload/email script and very carefully tested on my server before submitting it for production. It uses CGI.pm, MIME::Lite, and a few other CPAN modules. As one might expect, these modules weren't installed on the target server. Now, I'm not certain how familiar you are with MIME::Lite, but it requires a lot of modules itself. While MIME::Lite is now installed, I've had to physically request each module it depends on. Why? Because the admins on that server either don't know or refuse to use the CPAN module. I've tried to be as helpful as I can, sending diplomatically worded instructions for using `perl -MCPAN -e "install MIME::Lite"` to install MIME::Lite. I know these instructions are being passed on to the Admins in question...yet, they insist on installing things by hand. How do I know they're doing this? Because CPAN.pm automaticaly detects and installs dependent modules. If they'd installed MIME::Lite using -MCPAN, I wouldn't have to request the dependent modules; they'd already be there. I don't know why they're doing this. But I suspect it's because they don't think a lowly software developer is smart enough to take the time to find a community like the Monastery, to learn basic Unix skills, to understand enough about their job to provide useful suggestions (including recommended permissions and file locations). In other words, they've copped an attitude because I'm not part of their club. If that's what happened with the folks that I have to deal with, then I find that unprofessional and inexcusable. What does this have to do with you? Haven't you copped an attitude of your own? You're right; it is my job not to cast blame inappropriately and to take responsibility for my code. However, it's your job (as Tilly, Ovid, Masem, et al) have suggested, to take the time to review what the developers have given you, to provide good (and complete) answers when asked, and to prompt for additional information when you think there are questions that aren't being asked. Furthermore, it's your job to foster a spirit of teamwork in your organization. If you do not have a "team ethic" in place and you wish one existed, it's your responsibility to start one. Start by setting aside the advocacy. Some people know and like Unix, others know and live with Windows. Cope. This is business, not religion. Consider spending time with your software developers. Ask them what their frustrations are. Ask if there's anything you can do to make their work easier. Do this often enough, they'll start learning and--through your example--responding in kind. It does work; I've seen it happen. On the other hand, if you cop a superior attitude, your co-workers will start avoiding you. They'll start thinking you're incompetent and they'll start thinking you're an intolerable jerk. I don't really care if you like Perl, but I do care when you make asinine (and unfounded) assumptions about me, my skills, or my potential. We're all part of the same team, which means each of our efforts are directed toward getting the job done, typically for profit. So stop wasting your company's money by bemoaning the lack of cooperation. Instead, take control of the situation...initiate change. Consider software developers as colleagues and start treating them like people. I freely confess that I don't know Unix very well. However, I can learn it and am slowly learning it. I'm having to fumble my way in the dark because I don't have people (outside the Monastery) that I can use as mentors. I can read all I want, but books rarely cover real world scenarios. Man pages are fine, but many are either poorly written or so detailed that those missing the basic education get lost in the details. I'd happily work with a NetAdmin to learn this stuff--if I could find one that's civil enough to give me the time of day. Also, FOLLOW UP. If you find that a problem was caused by a mistake in the code, then diplomatically report that back to the developer in a kind way, one that doesn't start with "You stupid jerk." And, yes, my "script" uses strict, -w, and -T. Give me enough of a break to know what I don't, to accept my limitations, and to ask questions that, while basic to you, are important for me. Furthermore, give me enough of a break to be able to learn what I need to do a good job. If I make a mistake and you find it, I want you to tell me--preferably without rancor, antagonism, or oneupmanship. We're all working toward the sames goals, helping the project, team, and/or company/organization succeed. --f	[reply] [d/l]
Re (2): Why I hate Perl (discussion) by deprecated (Priest) on May 17, 2001 at 19:44 UTC
It looks like we're arguing the same things here footpad. I'm glad to hear that because, well, this thread is pretty tiring. I guess people who are familiar with my recent postings (like tilly) would know that I am NOT an admin at this site, but I have been at the past. So what I'm experiencing now is empathy and sympathy for the SysAdmins because the developers here are... well... I would say awful, but I like them as people. Perhaps misguided is a better term. My job at this site has to been come in and provide new dialogue between the testers and the developers, and audit code that is broken. In the course of that, I wind up writing new code. Which just reinforces how much "good code" (as you and I write) is better than "bad code" (which I see more of every day). I've gotten a few private /msg's from people who did not understand the context of the root node of this thread. I had assumed that people were familiar with my ongoing exploits. For the full story, please see my most recent threads. I will perhaps update this node later to include links to particular nodes. I am exhausted (and unfortunately developed a cold) at the moment. dep. -- Laziness, Impatience, Hubris, and Generosity.	[reply]
Re: Why I hate Perl (discussion) by coreolyn (Parson) on May 16, 2001 at 21:16 UTC
I don't see one Java application that doesn't ship with it's own JDK, I don't see why doing the same with Perl wouldn't be benificial to an applications stability, ease of migration, and maintenance. To resolve issues on development servers here I keep the systems perl separate from the users. I install various Perl flavors beneath /home/perl. (i.e /home/perl/5.6.0/bin/perl, etc)This makes management cleaner for both the sysadmins and the developers. Now that Sun is maintaining it's own Perl distribution (as of 2.8) I don't want to find some patch that plays havoc on the dev enviornments. Also this argument reminds be of an a coder's complaint I heard recently "The only problem with developing user interfaces is the user". But ya know Joe, There's more than one way to do it and there's nothing you can do about it :) coreolyn	[reply]
Re: Why I hate Perl (discussion) by nysus (Parson) on May 16, 2001 at 21:17 UTC
An "everybody and everything sucks" attitude is not very professional and accomplishes nothing. My best recommendation to you is to pick up How to Win Friends and Influence People. Seriously. No joke. $PM = "Perl Monk's"; $MCF = "Most Clueless Friar"; $nysus = $PM . $MCF;	[reply]
Re: Why I hate Perl (discussion) by Mungbeans (Pilgrim) on May 17, 2001 at 17:02 UTC
This is a problem with your co-workers and the environment. Your developers are well known (in Scotland at least) as jobs-worth, i.e. 'that's more than my jobs worth'. Aka unprofessional, selfish gits. First step - take a break. The people here aren't your enemy. Neither are your co-workers. Neither is perl. Kick a ball around to blow off some team, go for a run - SOMETHING!!! Second step - gather some examples and evidence of bad code. Gather some examples of good coding standards from successful perl using companies. Go to your management and make your case: Our perl scripts need mucho maintenance because they are not modularised We are constantly reinventing the wheel - this is costing us money with no good reason Our scripts are not robust We have an adverserial culture where no one is prepared to take responsibility. We're supposed to be working as a team but because we aren't, we're spending more time infighting than fixing problems You can't change your fellow coders if they don't want to change. You can change management if you make a reasoned case showing clear, tangible �� savings. They may even thank you. Your co-workers won't but maybe they will find new jobs. Good luck, I've been in the same boat and it really sucks.	[reply]
Re: Why I hate Perl (discussion) by muzakfetch (Scribe) on May 19, 2001 at 00:32 UTC
After reading all of the above and being a friend of deprecated, I have decided to post a small rant. Judging by the knee-jerk reactions (early on) and the more recent follow-ups, I am inclined to say that maybe we're not all fully reading what we're responding too. Possibly not listening to our fellow monks' rants. I am a system administrator, by profession. I primarily work with unix based machines, but I also deal with other platforms as well. What is said is true, there is more then one way to do it. Many system's admins take different approaches, often times what I would consider lazy approaches, and some take approaches that are much to difficult and time consuming to maintain. Now mix in (dare I say) whiny programmers who each have their own style of writing, who have their own preconcieved ideas about "the way things should be" and at their last job, "It was always like that". Are you seeing my point? So lets understand both sides of the coin, my job is to keep that server running 24/7 downtime is NOT an option for me. Just because perl is still 5.6.0 even though you requested 5.6.1, doesnt mean I am not interested :-) Enough. Brother Tyler aka muzakfetch	[reply]
Re: Why I hate Perl (discussion) by harangzsolt33 (Chaplain) on Feb 08, 2021 at 01:29 UTC
I love Perl. I am not a sysadmin. I am a handyman. I just happen to know computer programming, and it's been my hobby since age 12. I also repair computers and maintain a handful of websites. I consider myself an advanced Windows user, but I want to transition to Linux in the future. I learned Perl, because it is like a Swiss army knife. Learning this single language not only allows me to write server-side scripts, but it also allows me to write scripts for Linux (and Windows of course. I currently use TinyPerl 5.8 on Windows.) It seems to me that your problem is not really with perl but with people which includes yourself. First of all, you point the finger at everybody else except you. That's problem #1. Secondly, you dislike the fact that everybody is different, which is perfectly natural if you live in a free country. If you live in a Communist country, everybody is the same, and nobody is allowed to be different. If you're in a company and it happens to have a toxic work environment, then please don't take out your anger on perl programmers, because that's exactly what your post sounded like. You need to take a break, or if it doesn't help, then perhaps get another job.	[reply]
Re^2: Why I hate Perl (discussion) by marto (Cardinal) on Feb 08, 2021 at 11:14 UTC
Replying to a 20 year old post from a Solaris admin (<snark>who are notorious for inflicting pain on users</snark>) is at best ill advised. Support groups exist for those who still have to work under Solaris. For the admins, there is no help. Regarding the long dead 'TinyPerl', the responses from chromatic in this thread should be of interest to you.	[reply]
Re^3: Why I hate Perl discussions by LanX (Saint) on Feb 08, 2021 at 14:37 UTC
And there is a typo in the title. Fixed it ... Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re: Why I hate Perl (discussion) by stevieb (Canon) on Feb 08, 2021 at 22:20 UTC
"So you see, I hate perl. I hate software developers. I really wish you would all grow up and learn how to be the professionals we pay for." All I see is hatred. Perhaps having an open mind along with a willingness to discuss with your teams and management on how the personnel issues could be rectified may better your outlook. You don't have a Perl or systems problem, you have a personnel, policy/prodecure and personal attitude problem. Embrace the difficulties, document the issues, and bring them to light. At least that's what I did in my two decades as a global network engineer and systems engineer/administrator, all the while being a software developer. Discuss with the development manager and team leads the ideas you have to streamline processes instead of just grunting about them privately on an Internet Perl forum. Make an attempt to fix things internally. Be the quality systems admin that you're being paid to be.	[reply]
Re^2: Why I hate Perl (discussion) by marto (Cardinal) on Feb 08, 2021 at 22:23 UTC
"Discuss with the development manager" 20 years ago...	[reply]
Re: Why I hate Perl (discussion) by Anonymous Monk on Sep 11, 2008 at 07:55 UTC
Oh my, I hate perl too :) But developers are one who gives you tools to play with. So show little respect to them :)	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

Why I hate Perl (discussion)

BDU