Hacker News Reader

Comment by tsujp | Hacker News Reader

Declarative programming is something that helps deal with weird edge cases like this right? I'm learning Elixir currently and the subtle semantics around the 'traditional' assignment operator (=) are quite cool. It means you can ditch most if blocks and provide a list of pattern-matchable functions (matched on their arity) to define logic which helps deal with edge cases a little better.

I'm curious how such a declarative paradigm _may_ help with the wacky usage of software old mate Mr. Null endeavours in. No one paradigm solves all problems I feel but perhaps some allow us to harvest some low hanging fruit for free?

View on HN

I don’t see how a string “null” would break anything besides a very stupidly written program (e.g., one which tries to eval() the input) or an ordinary program written in a very stupid language (e.g., one which tries to coerce strings to other types—PHP, is that you?).

I’m a big fan of pattern matching (especially statically verified pattern matching so sorry elixir), but I don’t see how it would help here.

Even PHP finds null==“null” to be false.

And at least you get to strongly compare by adding an extra = (e.g., ===, !==). I just wish the extra character (i.e., the not-as-default versions) weakened instead, like a tilde.

But yes, all strings are truthy. Except an empty string! And maybe some little-used nullish characters? Doubtful, but...

> But yes, all strings are truthy. Except an empty string! And maybe some little-used nullish characters? Doubtful, but...

Or "0"

But not in PHP 8

They changed a lot of the weirder string conversion stuff in PHP 8, but I'm pretty sure "0" is still falsy.

http://sandbox.onlinephpfunctions.com/code/d6df91536669985a6...

Set it to PHP 8 and click "Execute code," then set it to PHP 7 and Execute again. They give the same result, which is that "0" is falsy in both versions.

Because there was this period of time where the prevailing wisdom was "be liberal in what you accept, and conservative in what you emit" to enable computer systems to handle a wider array of cases. Some people still adhere to it.

I don't. If I want to extend a system that's currently in English to also accept Arabic or Farsi / Persian, you better believe I'm sanitizing that input carefully. Otherwise I'm opening up my application to zero width non-joiners[0] and all sorts of random fingerprinting for my English speaking users. I know it's a pain, but I'd rather just do it right.

[0] https://www.zachaysan.com/zero

Yes, implicit type casting is the work of the devil. Even the limited case in C is a popular source of trouble, never mind implicitly casting between strings and other types. Similar case with SQL's "NULL".

Reply on news.ycombinator.com