5 ms·

The Billion Dollar Mistake lives on. Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't) To

The Billion Dollar Mistake lives on. Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't) To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.

the_mitsuhiko 3y ago
> The Billion Dollar Mistake lives on. I disagree. There is a big difference between configuration language formats and programming languages. > To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound. I would agree, but in that case you now often need a secondary key to "turn something off" which is often not done.
- lexicality 3y ago
  > There is a big difference between configuration language formats and programming languages. You're right! But in my opinion the difference is that a configuration file should have a default state that could be written to disk and loaded with no change in behaviour. eg you can set `feature = "on"` or `feature = "off"` and if you don't set either it's the same as writing `feature = "off"`. Having a secret third thing of `feature = null` should be outlawed and I'm glad TOML doesn't encourage it
  - the_mitsuhiko 3y ago
    There is a secret third thing called "feature not in file" and most TOML implementation encourage it as "key not in file" is typically returned as `null` or `None`. That's how so many TOML files in practice end up with all these secret values. It's also particularly odd in lists where I have seen `["foo", "bar", {}]` show up in the real world with `{}` being used as a replacement value for null.
    - lexicality 3y ago
      In my experience (Python and Rust) missing keys are errors, not silently converted to None: In [1]: example = {"foo": None} In [2]: print(example["foo"]) None In [3]: print(example["bar"]) --------------------------------------------------------------------------- KeyError Traceback (most recent call last) Cell In[3], line 1 ----> 1 print(example["bar"]) KeyError: 'bar' In [4]: print(example.get("bar", "sensible default")) sensible default If configuration values were arbitrarily nullable I would either need to deal with the possibility of nulls ending up anywhere in my program (back to The Billion Dollar Mistake) or have to have checks on parsing to say which fields are nullable or not. I acknowledge people have done silly things regarding missing keys already - but I think they should be discouraged from continuing to do so, not enabled.
      - donaldstufft 3y ago
        How is checking for null any different than checking for the right type in general in TOML?
      - rascul 3y ago
        > In my experience (Python and Rust) missing keys are errors, not silently converted to None: In Rust it's possible to deserialize to an Option. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b6e808c8e6a0d2ec197aabe7012ab315 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- arp242 3y ago
  > There is a big difference between configuration language formats and programming languages. In general: I agree. But configuration formats (including TOML) also need to map well to programming languages, so you can't seem them as entirely separate. One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.
  - the_mitsuhiko 3y ago
    > One argument against Null is that it doesn't elegantly map to a data structure in all programming languages. TOML has plenty of constructs that don't map well to many languages. Plenty of language implementations do not know how to work with the datetime type, some TOML implementations barf on objects in lists. In some TOML implementations you also end up with nulls showing up when certain empty table constructs are used.
    - arp242 3y ago
      Making it map to every single language is always going to be hard, but most (mainstream) languages come with support for these kind of things in the language itself or standard library. That's not a good reason to add more though. It also pushes the complexity the complexity to the people using TOML in their programs, rather than the people writing TOML parsers: in some languages like Python or JavaScript you can "just" use a string and it's nullable, but in other languages you have to muck about with pointers, special types, options, etc.
    - kibwen 3y ago
      > Plenty of language implementations do not know how to work with the datetime type Right, and IMO datetime was a mistake to include in TOML.
afiori 3y ago
CSS has two magic values that would be useful in many configuration scenarios: - unset: ignore values of this property - initial: use the default value These would be useful e.g. with overrides. I agree that nulls in a config files are often not a good idea because it is not clear how they are going to be interpreted. PS: Css also has inherit that could mean "use the local default" while initial could mean use system default.
- lexicality 3y ago
  Unfortunately that's not what `unset` does and I feel like the confusion it causes and the complication it adds to any CSS parser suggests it's a bad idea!
  - afiori 3y ago
    lol, I guess this might be an argument against null
  - marcosdumay 3y ago
    Still, initial and inherit are good things to have. They are about as useful in a configuration language, where the cascading logic also applies.
bazoom42 3y ago
> The Billion Dollar Mistake lives on. If you are referring to Tony Hoare, the “billion dollar mistake” was not the existence of nulls per se, but that all references were nullable, with no support in the type system to distinguish between nullable and non-nullable references.

the_mitsuhiko 3y ago

> The Billion Dollar Mistake lives on. I disagree. There is a big difference between configuration language formats and programming languages. > To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound. I would agree, but in that case you now often need a secondary key to "turn something off" which is often not done.

lexicality 3y ago
> There is a big difference between configuration language formats and programming languages. You're right! But in my opinion the difference is that a configuration file should have a default state that could be written to disk and loaded with no change in behaviour. eg you can set `feature = "on"` or `feature = "off"` and if you don't set either it's the same as writing `feature = "off"`. Having a secret third thing of `feature = null` should be outlawed and I'm glad TOML doesn't encourage it
- the_mitsuhiko 3y ago
  There is a secret third thing called "feature not in file" and most TOML implementation encourage it as "key not in file" is typically returned as `null` or `None`. That's how so many TOML files in practice end up with all these secret values. It's also particularly odd in lists where I have seen `["foo", "bar", {}]` show up in the real world with `{}` being used as a replacement value for null.
  - lexicality 3y ago
    In my experience (Python and Rust) missing keys are errors, not silently converted to None: In [1]: example = {"foo": None} In [2]: print(example["foo"]) None In [3]: print(example["bar"]) --------------------------------------------------------------------------- KeyError Traceback (most recent call last) Cell In[3], line 1 ----> 1 print(example["bar"]) KeyError: 'bar' In [4]: print(example.get("bar", "sensible default")) sensible default If configuration values were arbitrarily nullable I would either need to deal with the possibility of nulls ending up anywhere in my program (back to The Billion Dollar Mistake) or have to have checks on parsing to say which fields are nullable or not. I acknowledge people have done silly things regarding missing keys already - but I think they should be discouraged from continuing to do so, not enabled.
    - donaldstufft 3y ago
      How is checking for null any different than checking for the right type in general in TOML?
    - rascul 3y ago
      > In my experience (Python and Rust) missing keys are errors, not silently converted to None: In Rust it's possible to deserialize to an Option. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b6e808c8e6a0d2ec197aabe7012ab315 https://play.rust-lang.org/?version=stable&mode=debug&editio...
arp242 3y ago
> There is a big difference between configuration language formats and programming languages. In general: I agree. But configuration formats (including TOML) also need to map well to programming languages, so you can't seem them as entirely separate. One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.
- the_mitsuhiko 3y ago
  > One argument against Null is that it doesn't elegantly map to a data structure in all programming languages. TOML has plenty of constructs that don't map well to many languages. Plenty of language implementations do not know how to work with the datetime type, some TOML implementations barf on objects in lists. In some TOML implementations you also end up with nulls showing up when certain empty table constructs are used.
  - arp242 3y ago
    Making it map to every single language is always going to be hard, but most (mainstream) languages come with support for these kind of things in the language itself or standard library. That's not a good reason to add more though. It also pushes the complexity the complexity to the people using TOML in their programs, rather than the people writing TOML parsers: in some languages like Python or JavaScript you can "just" use a string and it's nullable, but in other languages you have to muck about with pointers, special types, options, etc.
  - kibwen 3y ago
    > Plenty of language implementations do not know how to work with the datetime type Right, and IMO datetime was a mistake to include in TOML.

afiori 3y ago

CSS has two magic values that would be useful in many configuration scenarios: - unset: ignore values of this property - initial: use the default value These would be useful e.g. with overrides. I agree that nulls in a config files are often not a good idea because it is not clear how they are going to be interpreted. PS: Css also has inherit that could mean "use the local default" while initial could mean use system default.

lexicality 3y ago
Unfortunately that's not what `unset` does and I feel like the confusion it causes and the complication it adds to any CSS parser suggests it's a bad idea!
- afiori 3y ago
  lol, I guess this might be an argument against null
- marcosdumay 3y ago
  Still, initial and inherit are good things to have. They are about as useful in a configuration language, where the cascading logic also applies.

bazoom42 3y ago

> The Billion Dollar Mistake lives on. If you are referring to Tony Hoare, the “billion dollar mistake” was not the existence of nulls per se, but that all references were nullable, with no support in the type system to distinguish between nullable and non-nullable references.