Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
SO has quite a few questions using the word "truthiness" to mean the truth value of an expression, when evaluated as a boolean, regardless of its original type. It's very useful in dynamic languages.
So my question is, is this a real term, and if so were we using it before Stephen Colbert made it popular? Or did we just adopt it afterward? In that case, what is the correct term with the definition I gave above?
There's a lot of debate over truthiness.
Merriam-Webster defines it as:
Oxford Dictionaries Online defines it as:
noun
[mass noun] informal
the quality of seeming or being felt to be true, even if not necessarily true.Origin:
early 19th century (in the sense 'truthfulness'): coined in the modern sense by the US humorist Stephen Colbert
It was used a little bit on Usenet prior to Stephen Colbert, but usually explained as soon as used, such as "the quality of stating concepts or facts one wishes or believes to be true, rather than concepts or facts known to be true".
Back to programming. Regardless of the origin, this modern sense of "truth from the gut, even if not true" is clearly incorrect most of the time when discussing Boolean logic and truth tables: this if statement is definitely true, and that while statement is false until (i > k). My gut feeling doesn't come into it.
If you're using truthiness in programming, most likely you're using the rare 19th century meaning of truthfulness, and it would be both clearer (and arguably more correct) to use truthfulness or simply truth.
Of course, English changes as usage changes, and some people have started to use truthiness to mean truth in programming. However, I would advise against truthiness to avoid any ambiguity of meaning ("real absolute truth" vs. "my gut feeling of truth, regardless of the facts").
It's a term that is known and acceptable within certain circles (for example JavaScript Boolean comparisons). As such, it is a "real" term. By virtue of being used it becomes legitimate.
All such terms come from somewhere - they don't pop into the world fully formed and with an established meanings (for example - software bugs didn't have the meaning they have now when electronic computers just started existing).
Whether it is academically accepted - that's a different matter. As far as I know there is no formal term for this fuzzy meaning of boolean values..
It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs' — as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached. Sounds very similar to modern software bugs to me.
I regard truthy as a legitimate term in use over JavaScript evaluation. Douglas Crockford's book on JavaScript - 'JavaScript the Good Parts' defines the terms that JavaScript 'if' evaluates as true to be 'truthy'. Equally he defines the terms that JavaScript evaluates to false as 'falsy'. He also uses the term to highlight the way that the '==' evaluation works in JavaScript (which is different to the way that many JavaScript users seem to believe it works).
From Crockford's The Elements of JavaScript Style
The == operator should not be used for comparing values with true because it does type coercion. If our intent is to determine if d.w.sv.checked is the boolean value true, then we must use the === operator. If we only care that a value is truthy (and not falsy) then it is better to not use an equality operator at all.
For example, because of type coercion., 1 == true is true, but 1 === true is false. The == operator can hide type errors.
In this context the term is both legitimate and useful.
As a further illustration of true and false in this context these cases are illustrative.
'' == '0' // false 0 == '' // true 0 == '0' // true false == 'false' // false false == '0' // true false == undefined // false false == null // false null == undefined // true ' \t\r\n ' == 0 // true
[] is evaluated to false when used as a boolean, etc.
0, None, [], and so on.
Truthiness has been a word long before Stephen Colbert has used it. I could swear I've seen it in logic/AI papers, and in some physics papers, too, but can't seem to find a reference to one that predates Stephen Colbert's show.
Truthiness is a legitimate and well defined term in Clojure, where it refers to the property of a value being considered true in a conditional statement.
So the conditional function below will only be called if value is "truthy"
(if value
(some-conditional-function))
The only non-truthy values are false and nil, everything else is considered truthy.
I believe the philosophical justification for this is that nil can be taken to mean "does not exist", so the conditional statement is able to test for existence of a value.
Many other languages also have a similar concept of values that will be considered as true in a conditional context, so in conclusion I would argue that yes, truthiness should be regarded as a legitimate programming term when it is used in this way.
"Truthiness" is something I make sure I understand when I'm picking up a new language, as they all deal with it differently. In my home-base first language of Perl, the string "0" is false. In many languages, that is a string that has content and is therefore true. In some languages the empty string "" is false, and in some it's true.
Understanding the choices that the language designers made about truthiness tells you a lot about their thinking, and starts to dip you into the conceptual universe of the language.
Whether we spelled it "truthiness" or used some other term (I think the header for that chapter in the Camel Book is "What Is Truth?"), programmers had a grip on varying values of the absolute thing called "true and false" long before Colbert came along and pointed out the bending of "true" in the public discourse.
Let me ask you back: what is a "real term"?
Any word humans use is "real" when used by multiple people meaning the (more or less) same thing. All languages are constantly evolving, and so is programmer's language.
For example, in Ruby, the rspec testing framework nowadays prefers xyz.should be_truthy instead of xyz.should be_true. Or xyz.should be_falsey instead of xyz.should be_false. Of course, instead of the latter they could have picked xyz.should be_wrong. But they didn't, so we can also ask if "falseyness" is a term.
Now it is. Kind off. At least in the communities who use these terms. Don't ask your lawyer or doctor. :)
If you're meant to ask "does the general public intuitively know what Truthiness is", then the answer is probably "no".
I've written a system that would determine the (mathematical) chance of a boolean statement being true, given partial data. I.e. we could determine that there was a 73% chance of X being true, if we didn't have sufficient data yet to establish firmly that X was true. "Truthiness" would be a perfectly valid way to describe such a percentage belief in X.
