Re: Re: Re: Re: Perl etiquette

First off, I'm hardly a "kid". Secondly, You've described the anti-me. I have the least tolerance for broken code as anyone in my organization, and "hammering out code" is the antithesis of everythign I stand for. I'm a design nut.

You used the tired "a bad programmer can screw up in every language" argument. Yes, very true... however the problem today is that new programming constructs (massive OO applications, EJB, SOAP) make it appealing and politically correct to do some very unmaintainable things. I've seen it happen. What's more, these practices are often encouraged without guarding the dangerous of over-indulgance. Some of these constructs allow interoperability between average level programmers in an organization (as is the case with massive OO), but there is a price. Sprawl. Chaos. Anti-Design in the long term. Perhaps not so in Perl as many of the Enterprise Class applications. "Enterprise Class" is usually implies "Massive OO construct with tons of exception handling", but these are also the inefficient error-prone beasts that consume 500MB of RAM. Attention to detail is lost when error checking is broad-based, and design is lost due to sprawl enabled by the lack of fine grained control and understanding.

I am not merely ranting on try/catch, but the concept of fine-grained versus coarse-grained error recovery. Your rebuttal to mine had some very excellent points, but the "kid" part wasn't one of them. Let's not judge based on percieved experience. Nixon* had plenty of experience. * = previous read "Nikon". That would have been funny.

Comment on Re: Re: Re: Re: Perl etiquette - eval

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Perl etiquette - eval by tilly (Archbishop) on Jan 19, 2004 at 05:31 UTC
I'm sorry for offending you by suggesting that you might be called a kid. If you read carefully, I didn't say that you were a kid, and in fact all that I know is that you describe yourself as a "young punk" and never meant to suggest otherwise. Also your impression of what I mean by "kid" might differ from mine. I tend to think of anyone below 25 as "kids". As for describing you or anti-you, I have tried to describe neither. I have attempted to describe programming reality. Bugs are an inevitable fact of life. There are different strategies for dealing with them. The one strategy that I guarantee won't work is to believe that you can plan on consistently not making any given mistake. This isn't a question of tolerance or intolerance towards bugs. It is a statement of human limitations. Yet this is exactly the strategy that many try to make work. About Enterprise Class applications. Mostly that means software created by and for bureaucracies. The development process involved inevitably guarantees a lot of poor trade-offs. The basic problem is fundamental to social organization, and not to any given development technique. On fine-grained vs course-grained error recovery. Again it depends. I have seen people create complex error systems which become impractical nightmares to work with. I've also seen errors which are so uninformative that nothing useful happens. Personally I lean towards a coarse-grained error system that gives you detailed information. See the comments on useful error messages in perlstyle. Add in a stacktrace with Carp. It only works with a certain range of applications, but that has proved to be of the ones that I have had to deal with. OTOH fine-grained error systems are things that can be nice if your error system actually anticipates your actual problems. Of course that generally requires a level of advance planning that can easily go wrong. Managing complexity only sometimes means mirroring the complexity to be managed.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: Perl etiquette - eval
by tilly (Archbishop) on Jan 19, 2004 at 05:31 UTC

As for describing you or anti-you, I have tried to describe neither. I have attempted to describe programming reality. Bugs are an inevitable fact of life. There are different strategies for dealing with them. The one strategy that I guarantee won't work is to believe that you can plan on consistently not making any given mistake. This isn't a question of tolerance or intolerance towards bugs. It is a statement of human limitations. Yet this is exactly the strategy that many try to make work.

About Enterprise Class applications. Mostly that means software created by and for bureaucracies. The development process involved inevitably guarantees a lot of poor trade-offs. The basic problem is fundamental to social organization, and not to any given development technique.

On fine-grained vs course-grained error recovery. Again it depends. I have seen people create complex error systems which become impractical nightmares to work with. I've also seen errors which are so uninformative that nothing useful happens.

Personally I lean towards a coarse-grained error system that gives you detailed information. See the comments on useful error messages in perlstyle. Add in a stacktrace with Carp. It only works with a certain range of applications, but that has proved to be of the ones that I have had to deal with.

OTOH fine-grained error systems are things that can be nice if your error system actually anticipates your actual problems. Of course that generally requires a level of advance planning that can easily go wrong. Managing complexity only sometimes means mirroring the complexity to be managed.

[reply]