in reply to Re2: Parallel structures are NOT maintainable
in thread using references as keys in a hash.

Let me put that last point another way. My programming services cost more per week than a top-of-the-line linux server. People like merlyn and others cost at least twice that. Is it worth it to you for me to spend 40 hours figuring out how to save a meg of RAM?

Huh? Where did that come from? Fourty hours to find and fix a single small issue? If I spent an entire five-hour shift fixing some little thing like that, I'd feel like I didn't get anything done that day. In a thirty-hour work week, I could rewrite the application from scratch and have time left over to unstick printers, bug the APCC tech support people about our ongoing PowerChute issue, teach an Introduction to the Internet class to a group of senior citizens, reboot my coworkers' Windows systems for them as necessary ("I restarted it. It should be better now."), run a couple of custom reports for my boss (and write one-off Perl scripts to turn them into meaningful data), and redo the stylesheets for the cgi scripts in question just because I felt like it.

Either we're talking about programs so different in size that it's not remotely meaningful to talk about them in the same conversation (as I suspected when I read your previous message upthread), or else one of is seriously mispaid (since I don't make anything like the kind of wage you are talking about).

I said that for complex situations the nested structures are better, but it seems to me that deeply complex programs are the only kind you are willing to concede might ever exist. Take a deep breath; some of us do simple stuff sometimes.


sub H{$_=shift;while($_){$c=0;while(s/^2//){$c++;}s/^4//;$ v.=(' ','|','_',"\n",'\\','/')[$c]}$v}sub A{$_=shift;while ($_){$d=hex chop;for(1..4){$pl.=($d%2)?4:2;$d>>=1}}$pl}$H= "16f6da116f6db14b4b0906c4f324";print H(A($H)) # -- jonadab

Replies are listed 'Best First'.
Re: Re: Parallel structures are NOT maintainable
by dragonchild (Archbishop) on Feb 25, 2003 at 15:08 UTC
    Actually, it's both - I do work primarily on large and very-large systems. And, I am seriously overpaid by my current employer. :-)

    And it came from the fact that I have been told to "save a Meg of RAM, not matter what it took". *shrugs* Reminded me of the Dilbert cartoon where the little bald guy says "I'm going to write me a minivan this week!"

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      And it came from the fact that I have been told to "save a Meg of RAM, not matter what it took".

      Ah. Saving a meg of RAM is not a good reason to use parallel hashes for a complex problem, I can agree on that point. In fact, I've been known to save myself time by throwing an enormous partially-redundant hash at a problem thus consuming around a hundred megs of RAM where it would have been possible to use less than half that. Of course, that script only has to run once a year, so it isn't worth optimising -- which I think is really what this discussion came to be about: knowing when something is worth doing and when it isn't.

      And don't let word get back to your employer that you are overpaid :-)


      sub H{$_=shift;while($_){$c=0;while(s/^2//){$c++;}s/^4//;$ v.=(' ','|','_',"\n",'\\','/')[$c]}$v}sub A{$_=shift;while ($_){$d=hex chop;for(1..4){$pl.=($d%2)?4:2;$d>>=1}}$pl}$H= "16f6da116f6db14b4b0906c4f324";print H(A($H)) # -- jonadab