2 added 381 characters in body
source | link

Even if the language definition specified your and and or keywords rather than the more mathy |, ||, &, and && keywords introduced by the C language folks at Bell Labs (Brian Kernighan and Dennis Ritchie of blessed memory), we'd still need more detail than and and or can give us.

 if ( expensive_function (a) && another_expensive_function (b) ) {}

skips evaluating the second expensive function if the first one comes back false. That's also important because it lets us write safe code.

 if ( a != 0 && 1.0 / a > 0.3) {} 

would sometimes throw div-by-zero if a is zero if we used & in place of &&.

But

 if ( expensive_function (a) & another_expensive_function (b) ) {}

always evaluates them both functions. The distinction is important if the second function has any side-effects (like printf() for example).

Other languages have different ways of spelling && and &. But the distinction between the two still exists. E.g. in VB.net, AndAlso functions as && does in c-like languages.

SQL gets away with using AND and OR because it's a declarative language, not procedural. It's almost, but not quite, a side-effect-free language. So SQL query planners can decide which parts of anded / ored queries must be evaluated, without we programmers telling them.

Even if the language definition specified your and and or keywords rather than the more mathy |, ||, &, and && keywords introduced by the C language folks at Bell Labs (Brian Kernighan and Dennis Ritchie of blessed memory), we'd still need more detail than and and or can give us.

 if ( expensive_function (a) && another_expensive_function (b) ) {}

skips evaluating the second expensive function if the first one comes back false. But

 if ( expensive_function (a) & another_expensive_function (b) ) {}

always evaluates them both. The distinction is important if the second function has any side-effects (like printf() for example).

SQL gets away with using AND and OR because it's a declarative language, not procedural. It's almost, but not quite, a side-effect-free language. So SQL query planners can decide which parts of anded / ored queries must be evaluated, without we programmers telling them.

Even if the language definition specified your and and or keywords rather than the more mathy |, ||, &, and && keywords introduced by the C language folks at Bell Labs (Brian Kernighan and Dennis Ritchie of blessed memory), we'd still need more detail than and and or can give us.

 if ( expensive_function (a) && another_expensive_function (b) ) {}

skips evaluating the second expensive function if the first one comes back false. That's also important because it lets us write safe code.

 if ( a != 0 && 1.0 / a > 0.3) {} 

would sometimes throw div-by-zero if a is zero if we used & in place of &&.

But

 if ( expensive_function (a) & another_expensive_function (b) ) {}

always evaluates both functions. The distinction is important if the second function has any side-effects (like printf() for example).

Other languages have different ways of spelling && and &. But the distinction between the two still exists. E.g. in VB.net, AndAlso functions as && does in c-like languages.

SQL gets away with using AND and OR because it's a declarative language, not procedural. It's almost, but not quite, a side-effect-free language. So SQL query planners can decide which parts of anded / ored queries must be evaluated, without we programmers telling them.

1
source | link

Even if the language definition specified your and and or keywords rather than the more mathy |, ||, &, and && keywords introduced by the C language folks at Bell Labs (Brian Kernighan and Dennis Ritchie of blessed memory), we'd still need more detail than and and or can give us.

 if ( expensive_function (a) && another_expensive_function (b) ) {}

skips evaluating the second expensive function if the first one comes back false. But

 if ( expensive_function (a) & another_expensive_function (b) ) {}

always evaluates them both. The distinction is important if the second function has any side-effects (like printf() for example).

SQL gets away with using AND and OR because it's a declarative language, not procedural. It's almost, but not quite, a side-effect-free language. So SQL query planners can decide which parts of anded / ored queries must be evaluated, without we programmers telling them.