Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: Sub-initiate needs help getting started

by agentv (Friar)
on Aug 26, 2003 at 05:48 UTC ( #286588=note: print w/replies, xml ) Need Help??


in reply to Re: Sub-initiate needs help getting started
in thread Sub-initiate needs help getting started

...do not despair Lori713 in the face of this discouraging (and somewhat misguided) advice.

It is not useful to conclude, "He drives without a seatbelt, therefore he must be a terrible and careless driver." And it is similarly unhelpful to conclude (without seeing any code) that the code is worthless and unmaintainable on the basis of a few superficial points of dogma.

Don't get me wrong. I think that everyone learning or writing their own code from scratch should make a point of using strict and -w for everything they create. But my experience with production projects is that you should not feel stopped from proceeding if you cannot retrofit those civilities onto an existing code base. There are more important tests that you can conduct.

But go ahead guys. Keep on declaring any code that does not meet your personal standards for cleanliness or elegance to be "worthless" and watch the number of IT managers who refuse to let Perl anywhere near their shop grow. (It's already a depressingly large number of them already.) The cliche' of a consultant who leaves behind a legacy of ugly and maintainable code is a pervasive one. And part of that legend is created by weak and dogmatic programmers who know how to write things from scratch, but quiver in the face of complex code written by someone else whose thought process works differently.

And there's good reason for this. It's easier to pronounce code to be "worthless" than it is to admit, "I don't understand how this works."

So don't be discouraged Lori. And as other advice here indicates, you should simply take small parts of the problem and examine them one at a time. As you work with the system, you'll begin to see what it does, and what you can do with it in the future.

You've already identified several things that are important about your Perl parts of the problem. Use the seatbelt where you are creating new things by using -w and strict in your own code. Learn how to test your code from the command-line.

In addition, begin now to learn how your web server operates. Become familiar with the configuration files (or other configuration systems) and with the log files that are created. Sometimes those log files are going to contain the clues about what went wrong with your system.

Most of all relax. What you have to do can be done (in fact, you will do it) and you have already taken an important step by joining this community and becoming part of the conversation.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

  • Comment on Re: Re: Sub-initiate needs help getting started

Replies are listed 'Best First'.
Re: Re: Re: Sub-initiate needs help getting started
by bobn (Chaplain) on Aug 26, 2003 at 06:57 UTC

    But go ahead guys. Keep on declaring any code that does not meet your personal standards for cleanliness or elegance to be "worthless" and watch the number of IT managers who refuse to let Perl anywhere near their shop grow.

    1. The desire to rewrite rather than modify is not limited to perl programmers.

    2. Shit code is shit code. Good code is good code. I know. I've written both. And one of the main differences is that when it comes time to make changes and add features, the shit code is sheer agony and the good code is surprisingly easy.

    If the new reports are only trivially different from the existing reports, the OP might be able to tweak the program to meet the needs. Some parts of the program may be salvagable.

    But a system that is contained within one 8000 line file with few or no comments, doc, no warnings and no strict, and lots of global variables named in the form g_xxx is almost certain to be shit code. It is hard to imagine anyone who cared writing anything decent that matched this description.

    But it probably is a mistake to condemn it without seeing it. Lori, you might want to try and get some help with this. This is one place. Another might be at a meeting of your local Perl Mongers group. http://pm.org.

    The advice given above about learning how your webserver works is excellent, especially the log files, especially the error logs because anything you output to STDERR (eg warn 'something') ends up there instead of in the webpage.

    --Bob Niederman, http://bob-n.com

    All code given here is UNTESTED unless otherwise stated.

      But a system that is contained within one 8000 line file with few or no comments, doc, no warnings and no strict, and lots of global variables named in the form g_xxx is almost certain to be shit code. It is hard to imagine anyone who cared writing anything decent that matched this description.

      ...I'm inclined to agree mostly with this. But I still consider it to be mostly superficial evidence. In aggregate, I'd expect it to be a code base of which I'd be wary myself, but from just the facts we have, it could be that the code is well written enough that comments would be superficial (the chances are slim, but it's possible), and that it's laid out well enough to provide its own documentation. I can certainly write code that well, and I know that many of you think that you can too.

      The use of -w and strict was not nearly so universally expected as recently as 5 years ago. And I'd be willing to be that this code has evolved over a fair amount of time. This doesn't sound like a two-month hack. (Unfortunately, it sounds more like a 4 or 5 year hack.)

      The 8000 line thing looks pretty grim to me, but my reaction to the global variable thing was to say to myself, "Good, at least he used a naming convention for those."

      But here's my main point. I believe in clean, readable code every bit as much as the next person. In fact, I proclaim whenever I teach, that "Vinny's Second Law of Programming" is "Thou shalt make it readable!"

      Inevitably this invites the question, "The what is the first law?" To this I reply, "The most elegant code is the code that's finished."

      So if given the choice of working with a body of code that is not to my taste, or rebuilding everything from scratch, I will choose to use the existing code unless it is truly impossible. The more competent I am, the more broken the target code can be for me still to succeed.

      Given the stated time parameters for this problem, rebuilding from scratch does not seem to be an option at all. On the other hand, assimilating horrid obfuscated navel-lint code doesn't seem to be a great option either. But there's no reason to despair yet.

      ...All the world looks like -well- all the world, when your hammer is Perl.
      ---v

Re: Re: Re: Sub-initiate needs help getting started
by dash2 (Hermit) on Aug 27, 2003 at 17:21 UTC
    Nonsense.

    First of all, the reason that managers are often turned off Perl is nothing to do with "dogmatic programmers". It is much more to do with incompetent programmers who don't use strict or -w, and who, partly for these reasons, do write unreadable code.

    It is possible that this consultant was a genius who doesn't need a seatbelt (see Paradigm Shift - Don't use strict for a famous example). But the 99% likelihood is that he was an idiot who didn't know how to use a seatbelt - especially if his code has a lot of globals, which is normally a sign of bad design.

    Finally, hard-to-understand code is almost always bad code. (There are exceptions, like tightly optimized loops, or JAPHs.) And for a consultant, this is doubly true: if you've left a lot of code that other people find difficult to use, then you're doing a crummy job - no matter how brilliant your code may be, your first priority was to help the people you worked for. Beginning programmers often think that if they don't understand something, it must be very clever, deep code. Usually the best code is very easy to read, almost like pseudocode.

    I think this is a tough job, but kudos to Lori713 for taking it on.
    A massive flamewar beneath your chosen depth has not been shown here

      ...I agree mostly with your points.

      I would have to quibble with the premise that "the 99% likelihood is that he was an idiot." I'd say that there is a very high probability that this was a consultant who learned Perl on his own and didn't benefit from the sort of peer community that can be found here. I'd say that there's a high liklihood that the code is actually difficult to understand. (Although we've seen no direct evidence of this.) But I'd stop well short of presuming that someone else is an idiot without something a little more concrete.

      I am 100% with you (on the other hand) behind the principles that a successful program communicates to other programmers as well as to the machine that it controls. And I agree wholeheartedly that readable code is usually more error-free and robust, not to mention extensible and maintainable.

      But I am certain that I've seen the "second consultant" effect in many shops where the new guy proclaims the previous guy's work to be crap and insists that it all has to be thrown out. And I've seen it happen for slim reasons, dogmatic reasons, or simple ego reasons.

      And I have earned my chops on this. I've encountered, and successfully worked with, code that was probably criminally negligent. And you may hate it, but if you're a good engineer, you try to make it work anyway. That was the point I was trying to make. Sometimes you just have to take what you've got and go with that.

      ...All the world looks like -well- all the world, when your hammer is Perl.
      ---v

        I've encountered, and successfully worked with, code that was probably criminally negligent.

        Funny you should say that. I'm doing it right now... sigh. Yes, that's part of life. But there's no reason to pretend that rubbish isn't rubbish.

        A massive flamewar beneath your chosen depth has not been shown here

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2018-11-14 00:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My code is most likely broken because:
















    Results (160 votes). Check out past polls.

    Notices?