• (nodebb)

    What is AAYFN?

  • A.N.O Nymos (unregistered)

    Always Abbreviate Your Function Names. Mouse-over texts are such a wonderful invention 😇

  • (nodebb)

    Ah! Thanks. Couldn’t see that on mobile.

  • Darren (unregistered)

    Rather than 'Not specified', isn't the correct idiom to use 'File not found'?

  • Michael P (unregistered)

    Why would anyone object to Boolean-ly typed code? It's better than stringly typed code, right?

  • Officer Johnny Holzkopf (unregistered)

    Instead of nv being the "null value", what about "no value", as in, "O don't know, I have no opinion about wether this is true or false"? Would give the program a bit of personality, quite refreshing in the age of articial intelligets...

  • (nodebb)

    Now a Lisp entirely implemented using C++ templates, that would be something interesting. We could even call it CLisp!

    Mandatory <sarcasm> tag for those who need it. I hate C++ template programming. It's an abuse of the language and the compiler.

  • MRAB (unregistered) in reply to y6ird

    The text says "AAYFN(always abbreviate your function names)". No hovering needed! :-)

  • Hmmmm (unregistered)

    self.ship(it)

  • (nodebb)

    --Instead of nv being the "null value", what about "no value"-- or maybe ICNCNDTBVOTPV (I can neither confirm nor deny the Boolean value of that property) ?

  • Randal L. Schwartz (github)

    Matz was clearly a fan of both Smalltalk and Perl, and while both of those were my favorite language at one point or another, I never caught on to Ruby. At least I successfully avoided that other Perl-inspired language, PHP. Now I'm working mostly in Dart, which can point at Smalltalk for a lot of the core features.

  • Kotarak (unregistered)

    The other day, I had a similar problem in Python: How are values interpreted in a boolean context?

    I'm a Clojure guy. false and nil are falsey, everything else is trueish. Shiny uses a similar approch in its req() function. False, None and "" are considered falsey in this context. So far so good. Now I do various shenanigans which ultimately result in a polars data frame, which should be plotted or displayed to the user. The value is either None, if for example not all required inputs are properly set, or a (possibly empty) DataFrame. So shiny.req(data_frame()) should do the trick. Alas, it doesn't. Why? Because some idiot decided, that users are stupid and using a DataFrame in a boolean context is worth an exception because "the boolean value of a data frame is ambiguous". No. It is not. A data frame is neither False nor None. Hence it is trueish.

    And because you can obviously modify Python's behaviour for standard issues to throw unwarranted exceptions, I had to roll my own def req(*args, **kwargs): shiny.req(*map(lambda x: isinstance(x, polars.DataFrame) or x, args), **kwargs) sigh

  • (nodebb)

    OK, "Pretty-print a Boolean" sounds a perfectly valid function. And allowing alternative text may be unusual, but makes sense - you might want "True/False" in one place and "Yes/No" in another. But why would you not just pass in the value that you want pretty-printed? If you really need to find it by name first, it would make more sense for the caller to do that and pass the value to this function.

  • (nodebb)

    nv is obviously FILE_NOT_FOUND.

  • (nodebb) in reply to Kotarak

    That's why I have a rule whenever I'm writing coding conventions that you can never use anything other than a boolean in a boolean context. Never rely on truthiness; always be explicit about what you're checking for.

  • Kotarak (unregistered) in reply to Dragnslcr

    Well, a lot of languages treat nil, NULL or None as false, which is quite useful, because it treats the common case as default und reduces boiler plate. (This is also something Python gets wrong all the time. The language of stupid and useless defaults.) Only if you ever want to distinguish boolean false from nil you have to be specific, which you want in maybe 0.0000001% of the time.

    The problem is two-fold: 1) Python allows to modify this behaviour. So anybody can pull the rug under you. WTF? and 2) the implementor of the polars.DataFrame chose to do so (WTF?) and the reason for it was the presumed stupidity of the user (WTF?), who obvisouly cannot be trusted with the above. Finally, instead of just giving a warning (which would be annoying, because libraries shouldn't print stuff), he decided to throw an exception for perfectly normal behaviour. W?T?F?

  • (nodebb) in reply to SteelCamel2

    I can't help but imagine this function being called as part of a large "case-type" statement as an attempt at internationalization. And, of course, the entire mess copied/pasted everywhere a binary out was desired.

Leave a comment on “AAYFN”

Log In or post as a guest

Replying to comment #701902:

Log Out

« Return to Article