Re: [Gnu-arch-users] Nit

[Andrew Suffield]

On Tue, Oct 21, 2003 at 08:13:29PM -0700, Dustin Sallings wrote:
> >>>I have never even encountered a program where this was not true, let
> >>>alone written one.
> >>
> >>    Are you familiar with signal 13?  That's what your application
> >>receives when its standard out goes to a pipe and the pipe closes.  
> >>The
> >>default behavior is to have your program abort when it's unable to
> >>produce any more output.
> >
> >Behaviour which is fortunately easy to turn off. What I said remains
> >true, no matter how many historical features of unix you point out
> >that make it inconvinient.
> 
>       Oh come on.  You either haven't seen it, or it's historical and in 
> every application that hasn't specifically disabled it.

I've seen it, and I've seen several applications that haven't disabled
it, and it's been undesireable in every case, which is what I
said. Where's your point?

> >>    Are you suggesting that it's OK to abort if you're no longer able to
> >>write output to a consumer process, but not OK to abort if you're no
> >>longer able to write output to a filesystem?
> >
> >Why are you not reading what I have written?
> >
> >ENOSPC is not a fatal error. It is a temporary error. It is not
> >appropriate to abort when it occurs, regardless of whether you are
> >writing to a pipe or to a file.
> 
>       I have seen very few applications, if any, that consider ENOSPC a 
> temporary error.  I have a lot of programs that write to disk.  That's 
> their job.  If there is no space, they cannot do their job.  What are 
> they supposed to instead?

Wait for more space, usually.

>       Does tla call up Tom and ask him to come over to my house and free 
>       up disk space when it can't do a commit?

tla is unusual in this respect; it performs a single atomic operation.

>       If you're talking about logging, though...  In many of my 
> applications, it is extremely undesirable for the application to 
> proceed without logging what it's doing for accounting reasons.  If it 
> can't log it, I can't audit it and I shouldn't do it.

Which is why you buffer the data and wait for space.

> >>>>Then you're not a perl programmer. QED.
> >>>
> >>>Ask a perl programmer to write it for you.
> >>
> >>    Well that sounds like an intelligent solution.  I'm talking about
> >>    ways to make it easier for everyone to write reliable software and 
> >>you're
> >>suggesting someone else should do who knows all the secrets of a
> >>particular language.  Got it.
> >
> >Please be serious. It is not possible for "everyone" to write reliable
> >software. Only programmers skilled in using the tools available are
> >capable of writing reliable software.
> >
> >You are clearly unexperienced in using perl; you should not expect to
> >get the same degree of flexibility that a serious perl programmer
> >would.
> 
>       My last company had on average one hundred programmers working on 
> about two million lines of perl.  I was the guy they called in to solve 
> the ``hard problems.''  I did all the kinds of stupid hacks like I 
> consider Fatal to be.  I've seen just about everything that can go 
> wrong in a perl application and fixed it.

And yet you don't know how to acquire a list of all the perl
primatives? Or generate it on the fly? Oh dear. You are the sort of
person who gives perl a bad name. A skilled perl programmer would
produce things like that without having to think about them.

>       The point isn't who's the better perl programmer, it's how can we 
>       make tools that make it easier for people to write more reliable code.

No, that is not the only goal. Raising an exception on every error
might accomplish this, but it would have other disadvantages that are
unnecessary. Hence, perl does not do this - particularly since that
exact result can be generated fairly easily.

> If 
> the most obvious and easiest way to solve a problem isn't the most 
> reliable, it's not going to be the most common.  Experience is 
> important here, of course, but saying stuff like, ``Ask a perl 
> programmer to write it for you,'' when the only way they have to make 
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> functions safe is to know every function that is unsafe is certainly 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> not helping.

Straw man. You just don't know how to do it properly (and I have
better things to do than to write the code for you).

> >>>>  To say that 0 should not ever be a valid result from a function
> >>>>  seems a little odd.
> >>>
> >>>Definitely not a perl programmer.
> 
>       [yet another inconsistency in the perl core functions was here]
> 
> >I didn't say there were no exceptions. I said they were very few in
> >number. I also said they were trivial to wrap.
> 
>       Right, by writing more code.  If Fatal were implemented properly, I 
> wouldn't have to know all of these exceptions to perl's consistency.

Apples and oranges. You're complaining that Fatal, a module written to
perform task X, does not perform task Y.

> >Please respond to things I actually said, not to things you would like
> >to think I said.
> 
>       That statement is a little revisionist.  You're telling me I'm not a 
> perl programmer because I think that 0 is a perfectly valid result from 
> a function.  I provide examples and you say I'm not responding to 
> things you said.  There clearly is a communication gap here.

That's not what you said. Here's what you said:

> >>>>  To say that 0 should not ever be a valid result from a function
> >>>>  seems a little odd.

I did not say that 0 should not ever be a valid result from a function.

Please refrain from constructing more straw men.

> >>    I got it from my perldoc:
> >>
> >>       mktime  Convert date/time info to a calendar time.
> >>
> >>               Synopsis:
> >>
> >>                       mktime(sec, min, hour, mday, mon, year, wday =
> >>0, yday = 0, isdst = 0)
> >
> >Well, I got:
> >
> >No documentation for perl function `mktime' found
> 
>       It's part of the POSIX module.

So it's not a perl function at all, it's a C function. Don't expect C
functions to behave like perl functions.

The whole point of POSIX is to be the thinnest reasonale wrapper
possible around a bunch of C functions. It is very rarely necessary to
use it; an experienced perl programmer should always check twice
before calling a function from POSIX, because there's probably a perl
version that's preferable.

> >Nobody who is remotely used to using java is going to expect
> >well-written java code, especially from third parties.
> 
>       That answer is a bit rhetorical and probably just as true without 
> specifying a language.

Yes, that was my point, which you have "conviniently" deleted from the
quoted text.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature