Re: print LIST vs print join "", LIST
From: Anno Siegel (anno4000_at_lublin.zrz.tu-berlin.de)
Date: 04/19/04
- Next message: Michel Rodriguez: "Re: Is there something better than this?"
- Previous message: kenny: "Re: I cann't scale gif with correctly with perlmagick."
- In reply to: Tassilo v. Parseval: "Re: print LIST vs print join "", LIST"
- Next in thread: Uri Guttman: "Re: print LIST vs print join "", LIST"
- Reply: Uri Guttman: "Re: print LIST vs print join "", LIST"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 19 Apr 2004 09:33:59 GMT
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach Anno Siegel:
>
> > Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote in
> comp.lang.perl.misc:
> >> Also sprach Anno Siegel:
> >>
> >> > Here we come back to Uri's argument, but not for efficiency reasons but
> >> > on the general principle of "Print rarely, print late". If a piece of
> >> > code prints something, you can't take it back, and you have to bend over
> >> > backwards to make the printout invisible if you don't want it. So don't
> >> > do it, delay the decision to print to the latest possible time. The
> >> > same goes for warnings (of course) and dying in general-purpose subs.
> >> >
> >> > "Die rarely, die late" is a recommendable principle too.
> >>
> >> Incidentally, a couple of hours ago I browsed through
> >> http://www.extremeperl.org/, a book about Extreme Programming in Perl.
> >>
> >> On reading a corresponding paragraph, it reminded me of XP's principle
> >> of dying as early as possible. So there appear to be at least two
> >> schools of dying now.
> >
> > What is "XP's principle of dying early"? Does "XP" mean what I think it
> > does? And that's supposed to be an argument? :)
>
> XP being Extreme Programming. Say, Anno, you didn't really think that it
> might have been something Redmondish? ;-)
Oh. Okay, sorry :) Extreme Programming didn't come to mind.
> Meanwhile, I have found the exact spot where I picked up this statement
> for everyone to check:
>
> http://www.extremeperl.org/bk/coding-style
>
> Grep for 'fails fast'.
I have taken a look. I wouldn't necessarily conclude from that remark
that "failing fast" is a tenet of Extreme Programming. It simply states
the old argument that it is better to die than to risk doing damage.
In the particular case I tend to agree. The function that "fails
fast" here is the plan() function of Test.pm, whose only purpose is
to prepare for a number of tests to be run. In that capacity, deciding
not to run the tests when the plan is in error is entirely reasonable.
If someone really wants to run plan() for some other purpose, they can
wrap eval() around it.
> > Seriously, I know that dying early is sometimes promoted, arguing that
> > it is useless and potentially harmful to carry on after something
> > essential went wrong. However, whether it's useless to continue is
> > for the user to decide, there may be alternatives outside the scope
> > of the program that dies (and the programmer who wrote the "die").
> >
> > This view reflects a bit the program-centric view that a coder
> > necessarily assumes while working on a problem. "When *this* fails, we
> > can't do anything for the user. Better bail out." Indeed, it does
> > save the user the effort of checking for errors and thus is a service
> > for the user, or can been seen as such.
>
> I was rather thinking of libraries than programs. If you have a
> function/method that is supposed to do destructive I/O and it is passed
> garbage, it is certainly better to abort immediately than carrying on.
> Otherwise it might happen that the function does half of the I/O and
> then eventually dies leaving things in an inconsistent state.
To elaborate, when I say "die late" i don't mean to return an incomplete
or defective result with no indication. "Die late" implies that the
user *can* decide to die later, meaning that there must be an error
indicator. So the user can avoid the possible damage, but the
responsibility is his.
Someone could have decided to let system calls in Perl die in case of
errors, instead of returning a boolean success indicator. That would
save clpm a lot of admonitions that begin with "Always, yes *always*...",
reminding people of the responsibility they fail to take. We would also
see a whole lot of "eval { open(...) }; if ( $@ ) { ... }". I like it
the way it is.
> > But doing too much is a design error when it takes a responsibility
> > from the user they would rather keep, and premature dying belongs in
> > this category. Programmers who design on-the-fly are particularly
> > prone to this error. I know this from undisclosed sources :)
>
> I am always in favour of design on-the-fly. I still have vivid memories
> of the kind of planning-hoops I had to go through at university. There
> was one lab in particular, where we had to program a rather largish Java
> application involving a GUI. It all began with writing boring
> requirement specifications that were afterwards modelled into UML. As I
> recall it, the class diagram I came up with did impress mostly everyone.
> However, it turned out to be unimplementable in Swing because it assumed
> an event-model that simply didn't exist in this widget set.
>
> So I had to change everything. In the end, I secretly changed my UML
> diagrams to fit my final program and hoped that no one would notice
> (they didn't, of course). Had I designed the thing on-the-fly, the
> result would have been very similar without the many hours of overhead
> needed to create an UML diagram that no one cared about or wanted to
> see.
I don't have a formal education in CS, and anecdotes like this tend to
ease my regret about that. From afar I have watched some diagramming
techniques come and go (flowcharts were discarded in the 70s, Nassi-
Shneiderman in th 80s). UML seems to be an OO equivalent -- I haven't
looked closer yet. They have always been put forward as a planning
tool, and there has always been a tendency to use them as an analysis
tool, i.e. draw the diagram for an already written program to understand
its structure.
What happened to you seems quite typical. What use is a perfect plan
when it turns out that there is no reasonable implementation under
practical constraints.
> So I prefer the much more practical XP approach which essentially says:
> "Implement the first thing that works and that you can think of and then
> refactor". Perl is a wonderful language for that.
Indeed. However, it doesn't hurt to become aware of the pitfalls *this*
approach has. One of them is cramming too much functionality into a routine
you're writing, just because it's a good occasion (and also because the
ways the routine will be used aren't quite clear yet). Programmers like to
implement, it's the designer's job to decide what it worth implementing.
When the designer and the coder are the same person, at the same time,
that job becomes harder.
Anno
- Next message: Michel Rodriguez: "Re: Is there something better than this?"
- Previous message: kenny: "Re: I cann't scale gif with correctly with perlmagick."
- In reply to: Tassilo v. Parseval: "Re: print LIST vs print join "", LIST"
- Next in thread: Uri Guttman: "Re: print LIST vs print join "", LIST"
- Reply: Uri Guttman: "Re: print LIST vs print join "", LIST"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
