4 ms·

Boolean values are inherently a sign of an insufficient data model. Booleans carry no inherent meaning. They don't tell you where they came from or provide any

Boolean values are inherently a sign of an insufficient data model. Booleans carry no inherent meaning. They don't tell you where they came from or provide any context about what operations or data they are guarding. If your language lets you declare your own algebraic data types, there's no need to lean on a built-in Boolean type. You can create types that actually carry all the information you need so that pattern matching provides provenance and data only in the branches that need them. Robert Harper discusses the idea in some detail here: https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ https://existentialtype.wordpress.com/2011/03/15/boolean-bli...

mrkeen 4y ago
> Boolean values are inherently a sign of an insufficient data model. Booleans carry no inherent meaning. Would you say the same about Ints or Strings?
- mjburgess 4y ago
  They're saying you should be able to define your own The domain of int/str is infinite so there's less sense in redefining a number system for every property you want to model For small finite domains it makes sense to define your own in terms of the problem domain In this sense all two-valued types are bools
- HelloNurse 4y ago
  Practical language-agnostic example: a database for a business where some VARCHAR(34) columns are IBAN codes and others are messages to be displayed on a 2 by 17 characters LCD screen. They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model. For instance, it should be possible to turn an IBAN into a device screen message but not the opposite, but you can't do it if they are all "strings"; and the two types have different value constraints while a generic VARCHAR has none.
  - mrkeen 4y ago
    > They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model. About bools: that's my problem with this. If-statements now operate on anything, instead of just bools. And I don't think that makes sense, unless cheese. About strings: It's great you can statically differentiate between their types. But if strings don't exist, it makes it a little hard to write WHERE clauses.
charcircuit 4y ago
Pattern matching is just syntatic sugar over using booleans and extracting values from data types. This is an exaggerated problem with a cherry picked solution. See what happens when the condition is if a number > 100. Are you expected to convert the integer into a church encoded integer and then write 100 S types? Are you expected to adopt a language with refined or dependent types? Adding a ton of abstractions to fix a problem doesn't mean you now don't have an even bigger problem.
- chowells 4y ago
  Why do you care if a number is greater than 100? That has to actually mean something to you. What does it actually mean? Is it a validation error? Is it a warning trigger? Why not have a data type that actually expresses that meaning? Wait, are you hung up on implementation nonsense? Sure, there's a low-level operation that returns a 0 or 1 that you convert into your actually-meaningful data type. But that doesn't need to have a surface language boolean type that's privileged by the language design. And that's what's important here - language design. People write programs in a language, not compiled code. The model the language provides is of critical importance. It's how the users of the language think and how they communicate with each other. And this isn't abstraction. Boolean is the abstraction. It throws away all but a single bit of information. This is creating data types with semantics that carry far more than that single bit. It's making your code less abstract.
  - charcircuit 4y ago
    >Why do you care if a number is greater than 100? You could make a battle royal game well where people start taking damage when they are 100 units away from the center of the map. >Why not have a data type that actually expresses that meaning? It would add unneccessary complexity. >Wait, are you hung up on implementation nonsense? The base of what it being abstracted over is not nonsense. >But that doesn't need to have a surface language boolean type that's privileged by the language design. If exposing booleans lets people write simpler code then it makes sense to expose it instead of forcing complexity onto everything. >Boolean is the abstraction. No, booleans are a concept that the processor understands. Zero is false and nonzero is true. The processor has instructions like like logical and that can operate on these booleans. Branches can happen based off a bit in the status register. A bit has two states which maps to true and false. Booleans are a fundamental concept that is being built upon. The processor has a limited number of data types that it understands. Creating new data types is creating abstractions because those data types do not actually exist. You are simply hiding an actual data type in the new one you are creating.

mrkeen 4y ago

> Boolean values are inherently a sign of an insufficient data model. Booleans carry no inherent meaning. Would you say the same about Ints or Strings?

mjburgess 4y ago
They're saying you should be able to define your own The domain of int/str is infinite so there's less sense in redefining a number system for every property you want to model For small finite domains it makes sense to define your own in terms of the problem domain In this sense all two-valued types are bools
HelloNurse 4y ago
Practical language-agnostic example: a database for a business where some VARCHAR(34) columns are IBAN codes and others are messages to be displayed on a 2 by 17 characters LCD screen. They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model. For instance, it should be possible to turn an IBAN into a device screen message but not the opposite, but you can't do it if they are all "strings"; and the two types have different value constraints while a generic VARCHAR has none.
- mrkeen 4y ago
  > They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model. About bools: that's my problem with this. If-statements now operate on anything, instead of just bools. And I don't think that makes sense, unless cheese. About strings: It's great you can statically differentiate between their types. But if strings don't exist, it makes it a little hard to write WHERE clauses.

charcircuit 4y ago

Pattern matching is just syntatic sugar over using booleans and extracting values from data types. This is an exaggerated problem with a cherry picked solution. See what happens when the condition is if a number > 100. Are you expected to convert the integer into a church encoded integer and then write 100 S types? Are you expected to adopt a language with refined or dependent types? Adding a ton of abstractions to fix a problem doesn't mean you now don't have an even bigger problem.

chowells 4y ago
Why do you care if a number is greater than 100? That has to actually mean something to you. What does it actually mean? Is it a validation error? Is it a warning trigger? Why not have a data type that actually expresses that meaning? Wait, are you hung up on implementation nonsense? Sure, there's a low-level operation that returns a 0 or 1 that you convert into your actually-meaningful data type. But that doesn't need to have a surface language boolean type that's privileged by the language design. And that's what's important here - language design. People write programs in a language, not compiled code. The model the language provides is of critical importance. It's how the users of the language think and how they communicate with each other. And this isn't abstraction. Boolean is the abstraction. It throws away all but a single bit of information. This is creating data types with semantics that carry far more than that single bit. It's making your code less abstract.
- charcircuit 4y ago
  >Why do you care if a number is greater than 100? You could make a battle royal game well where people start taking damage when they are 100 units away from the center of the map. >Why not have a data type that actually expresses that meaning? It would add unneccessary complexity. >Wait, are you hung up on implementation nonsense? The base of what it being abstracted over is not nonsense. >But that doesn't need to have a surface language boolean type that's privileged by the language design. If exposing booleans lets people write simpler code then it makes sense to expose it instead of forcing complexity onto everything. >Boolean is the abstraction. No, booleans are a concept that the processor understands. Zero is false and nonzero is true. The processor has instructions like like logical and that can operate on these booleans. Branches can happen based off a bit in the status register. A bit has two states which maps to true and false. Booleans are a fundamental concept that is being built upon. The processor has a limited number of data types that it understands. Creating new data types is creating abstractions because those data types do not actually exist. You are simply hiding an actual data type in the new one you are creating.