Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Why I hate Perl (discussion)

by deprecated (Priest)
on May 16, 2001 at 19:48 UTC ( #80933=perlmeditation: print w/replies, xml ) Need Help??

My name is Joe. I'm a Solaris admin. I have decided to sit down and get out my feelings and explain to you perl users why I so despise this language of yours.

I have a large heterogeneous network of computers. We have macs, suns, and pc's all around. We have exchange servers, print servers, calendar servers, internal proprietary application servers, database servers, a storage area network, a wan link to maintain, and all manner of other things that I wont mention just now.

We also have software developers.

Software developers are the worst. If I could manage this network without developers, I surely would. Why, every single one of them has a different way of doing things. Every single one wants this shell or that editor. It's not just as simple as having the vi that comes with Solaris -- or even better, Notepad that comes with windows. No, they want vim, or Emacs, or nedit, or Ugh!!...

Then they want their specific flavor of programming language. Perl. It's not just enough that they want to develop in perl -- perl is NOT a programming language! Perl in fact is a scripting language used for extracting and reporting from log files. Like nuclear awk and sed. It was just never intended to run web applications, command databases, and send e-mails. No sir.

So my developers, bless their hearts, write perl 'programs'. Worse, they developed a culture about it. They like perl. They refuse to think that perl could be the cause of any of their problems. It's Oracle, they say. It's the server. It's the bandwidth. Its Netscape or IIS or Apache. Never perl.

They not only get accustomed to having their own environment -- one that is exactly as tab-completion, syntax-highlighting, right-paren finding as they want -- but they extrapolate that and expect EVERYTHING to work the way they want. They learned perl back when people thought of it as just an afterthought to Awk. They dont keep up on when things change. They dont even monitor sites like this one here.

So what really irritates me is when they blame me for things they are stupid and careless enough to do. They blame me for upgrading to perl 5.6.1, which really should be done. Features are deprecated, syntax is different, new wording is planned, and they expect to continue to use the code they have been using since perl 4. Well that isn't the way it works. And don't come to me, guys and gals, when your perl breaks because you did something stupid. If I upgrade to perl 5.6.1, and your scripts break, its because YOU are using incorrect syntax. YOU arent using -w and strict.

Phooey to you, and to perl. Perl is nothing but problems. Software developers create problems. They occupy my day with gripes and whines about why their software doesnt work, or why their scripts are now broken. If you must be one of these software-developer-flies-in-my-ointment, be responsible. We're all hackers here. I dont leave perl where you dont expect it:

# so you can use: #!/usr/local/bin/perl # and dont have to use: #!/joe/hates/perl/programmers/so/use/this/perl
You have to meet me half way. We work in the same building. We spend eight hours a day together, five days a week, fifty weeks a year. We went to the same schools, and we both call ourselves IT professionals. But how professional is it for you to code so irresponsibly? How professional is it for you to not know unix to the degree that you have to ask me for a symlink so you can use the programming language you purport to be an expert in?

As fellow slaves to the One True Operating System, you owe it to me to learn how to use unix. You owe it to me to take care of your own code. You owe it to me to not use deprecated syntax and features. You owe it to me to use -w and strict, so that I dont come over and fix your catastrophic problem (which you attributed to me) by changing:

my $qery = new CGI; # to... my $query = new CGI;
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. I'll even go as far as to say that neither of us will have a job if you guys dont shape up your act. Our bosses hate both of us. They think I'm an intolerable jerk, and they think you're incompetent. But if you write your code responsibly, and use the resources available, EVERYTHING will be more stable -- the servers AND your applications.

My name is Joe, and I am the representation of all the people out there who hate perl. Listen up, or we're all in trouble.

<!- so maybe I'll get a ton of --'s for this. maybe i'll get a ton of ++'s for this. I dont care. See, I've been a unix admin for longer than I've been a perl programmer. and now I have a unique perspective into why some of the software here sucks. these unix guys are totally competent. these programmers are also totally competent. but the programmers are set in their ways. my job as a programmer is to be flexible to my environment, just as the unix admin has to be able to have an IRIX or AIX system around. They cant just throw up their hands and say ack!! this sucks!! this is what our developers are doing. I hope you guys read this and learn something from it. I'm a unix admin, and I've got my eyes on all of you. I'm going to tell you when youre doing something stupid even though im a perl programmer and I love the language and the community. Because you guys are not holding up your end of the deal. You need to be professional about this. you need to be flexible and you need to move and grow with the times. ->

brother joe.

--
Laziness, Impatience, Hubris, and Generosity.

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?

      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

      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 };
      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.

        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.

(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.

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
      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
Re: Why I hate Perl (discussion)
by footpad (Monsignor) 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

      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.

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
Re: Why I hate Perl (discussion)
by nysus (Vicar) 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;

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.

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
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 :)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://80933]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2019-04-18 16:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I am most likely to install a new module from CPAN if:
















    Results (103 votes). Check out past polls.

    Notices?
    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!