Modern Angelspeak Bullheaven Poem by Alexandre Nodopaka

Introduction: Two winged coworkers have a friendly debate about their PC software
glitches. The problem is that from its beginnings eons ago, angel-talk has evolved
considerably. The conversation is caught in progress.

First Angel: : In short: Do you think it's good style for a method that is normally expected
to return a string to return /undef/ in some cases? Like in %s\n', $os-name(long = 1) :
%*[x] printf x xkl (0) detest. tmp @printf?

Second Angel: In particular: The Sys: : Info: : OS module has a /'name() object method.
It's normally expected to return the operating system's name /printf/ Op Sys to {why}
printf at /tmp/test tmp @: : : printf.

First Angel: The problem is that on certain linuxes, the name() method returns /undef/,
which causes the above example code to output something like this:
Use of the un-initialized value in /printf/ at /tmp/test. pl line 20.

Second Angel: I'm of the opinion that, in general, returning /undef/ isn't a great idea.
For subroutines, I think it's fairly terrible due to a caller's possible scalar or list context,
which is unknown to the subroutine author and certainly of his control.

First Angel: My coworkers say that it's up to the end-user to check for a valid string
being returned. I say that there's nothing in the docs which says that /undef/ might
sometimes be emitted and that it would be more polite to have it return the output

Second Angel: I disagree, the output must be input as in /'uname/ -o -r' or 'unknown' or whatever. It sets up the expectation that a string will be returned, and then forces you to deal with a possible /undef/ {why} printf at /tmp/test. defdef {why not} unprintf

First Angel: Where else might there be errors waiting to be checked for? Also, this
comes from code that was shipped by Arch-Archangel St. Peter to a customer outside of
the known heavenly sphere of electronic influence.

Second Angel: /Bullheaven/! ! !