3 ms·

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 't

by tsujp 6y ago

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?

throwaway894345 6y ago
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.
- rgj 6y ago
  Even PHP finds null==“null” to be false.
  - hunter2_ 6y ago
    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...
    - zerocrates 6y ago
      > But yes, all strings are truthy. Except an empty string! And maybe some little-used nullish characters? Doubtful, but... Or "0"
      - timw4mail 6y ago
        But not in PHP 8
        zerocrates 6y ago
        They changed a lot of the weirder string conversion stuff in PHP 8, but I'm pretty sure "0" is still falsy.
        hunter2_ 6y ago
        http://sandbox.onlinephpfunctions.com/code/d6df91536669985a6502c2aeb2362722005e608d 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.
- 3pt14159 6y ago
  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 https://www.zachaysan.com/zero
- _0ffh 6y ago
  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".

by tsujp 6y ago

throwaway894345 6y ago

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.

rgj 6y ago
Even PHP finds null==“null” to be false.
- hunter2_ 6y ago
  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...
  - zerocrates 6y ago
    > But yes, all strings are truthy. Except an empty string! And maybe some little-used nullish characters? Doubtful, but... Or "0"
    - timw4mail 6y ago
      But not in PHP 8
      - zerocrates 6y ago
        They changed a lot of the weirder string conversion stuff in PHP 8, but I'm pretty sure "0" is still falsy.
      - hunter2_ 6y ago
        http://sandbox.onlinephpfunctions.com/code/d6df91536669985a6502c2aeb2362722005e608d 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.
3pt14159 6y ago
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 https://www.zachaysan.com/zero
_0ffh 6y ago
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".