Re: [Gnu-arch-users] Nit

[Andrew Suffield]

On Tue, Oct 21, 2003 at 10:49:11PM -0700, Dustin Sallings wrote:
> >>>>  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.
> >>
> >>    Can you cite an application (other than something you've written,
> >>apparently) where this actually happens?
> >
> >Not off the top of my head, I'd have to go check a few things to find
> >one without this bug. It's distressingly common.
> 
>       That's cool.  I'm really interested in this.  Everything I've tried 
>       so far has failed quickly when disk space ran out.

Stephen got a few, and it didn't seem to take him very long.

> >>    You'd be part of the way there if you narrowed its reaction down to
> >>only one of the two values perl considers false.
> >
> >Once again you are showing your inexperience. There are three false
> >values in perl.
> 
>       Hah.  I expected that.  I'd actually go with more than that.  For 
> example:
> 
>       undef: false
>       "": false
>       0: false

These are the false values.

>       0.0: false

This evaluates to the number 0, and is therefore false.

>       "0": false

This evaluates to the number 0, and is therefore false.

>       "0.0": true (huh?)

This evaluates to the string "0.0", which is not the number 0 or the
string "", and is therefore true.

This is really trivial stuff. It's in chapter 1 of the camel. You
really should have known it, especially that last one (which is a
FAQ).

> >>The rest is dealing
> >>with individual functions and their perception of failure.
> >
> >Trivial.
> 
>       Well, yeah, just involves reading the docs for all of the things and 
> producing hand-made wrappers to deal with inconsistencies.  It's not a 
> lot of mental work, just tedious.

Maybe 10 minutes work.

> >>>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.
> >>
> >>    You make it sound as if you sat through the meeting where they, um,
> >>``designed'' the error reporting for perl.
> >
> >You make it sound as if there were not several large and heavy books
> >describing how and *why* perl works the way it does, or as if the
> >design decisions behind perl were not one of the *most common*
> >subjects of lectures by Larry Wall.
> 
>       I recognize that name, isn't he the guy who said, ``Perl is worse 
>       than Python because people wanted it worse.''  ?

That sounds like Larry Wall. There's a deeper meaning there, which
should be obvious to anybody who has read the camel (it's a criticism
of Python, to give you a hint).

Where's your point?

> >>    That's fine, I don't want the code...even if you don't ``have to
> >>    think about [it].''
> >
> >Do you often spend this much time complaining about the lack of a
> >module which you don't even want?
> 
>       I'm not complaining about the lack of a module, I'm describing why I 
> believe it's a stupid hack.  You're saying I'm wrong because it's 
> ``trivial'' to add enough stuff to it to get it doing what it's 
> documented as doing regardless of inconsistent built-in functions.

It does precisely what it is documented as doing. Stop making things
up. It's just not documented as doing what you want - that's a job for
a different module (and this is a logical division of modules).

Do you regularly complain that 99% of a project is a stupid hack
because it doesn't do what you would like it to do without the other
1%?

> >>    Fatal, a module that was written to ``replace functions with
> >>equivalents which succeed or die,'' does not work for certain core
> >>functions, to be specific.
> >
> >And nor was it intended to. The reason for its existance is pretty
> >obvious to me, since I've spent more than 30 seconds (nearly five
> >minutes, I'd estimate) thinking about how to go about making all the
> >primitives throw exceptions on error.
> 
>       This is the part I don't get.  Why would it not be intended to do 
>       what it's documented to do?

Again, it is not documented as doing this.

> >>>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.
> >>
> >>    Yes, as is clearly stated in the POSIX perldoc...somewhere between
> >>    the parts where it says it gave them ``perl-ish interfaces'' and 
> >>``It's a
> >>great source of wisdom.''
> >
> >No it isn't. What are you talking about?
> 
>       This is another example about how I'm a bad perl programmer because 
>       I don't know some secret knowledge and instead go by what's in the 
> documentation.

No single text will convey all the things you need to know about any
given subject. There are several good books about perl that will get
you started, notably including the camel.

I deliberately said "experienced". Some things only come with
experience, and a good feeling for the right approach to a problem is
one of them.

> >>You have absolutely no cause for complaint about library modules which
> >>don't throw exceptions, because that happens in every language,
> >>especially java; it's up to the library author to decide whether to
> >>use exceptions or not.
> >
> >It is the paragraph to which you were originally replying.
> 
>       Sorry, I didn't realize you were going that far back there.  I will 
> agree that Other People's Code is often ugly.  However, I don't see a 
> justification for ``especially java.''  In my experience, third-party 
> java libs can be bad, but they aren't usually that inconsistent from 
> the rest of the language.  It takes work to avoid exceptions in java.  

I think you mean "It takes work not to pass on exceptions from things
you call". It takes no work at all not to throw any of your own.

>       Probably the #1 feature of java is the vast availability of good 
> libraries, though.

Funny how there's somebody willing to say that about every language,
and at least as many people stating the opposite as the reason why
they can't afford to use the language in question.

Java is plagued with bad programmers, more so than most
languages. Only php, perl and C++ have comparable numbers of bad
programmers using them (and perl and C++ get out here because creating
libraries is moderately difficult, so the bad programmers don't do it
as much as they otherwise would). As a result it has a huge range of
lousy libraries.

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

signature.asc
Description: Digital signature