In the Help section "Variables, Types and Operators" the operators for variables are mixed with operators/comparators for conditions, although these are completely different subjects. Keywords like "=<> AND OR NOT" are not supported in expressions of variables.
I would strongly suggest a separate section for conditions, where these operators and comparators are documented.
PB Help: Condition operators/comparators
@Trond, @Andre:
It would be very interesting to know what kind of solution Fred favours:
(1) Allow mixing of value expressions and condition expressions.
IMHO this is very bad programming style, because these are completely different issues.
(2) Strict separation of value expressions and condition expressions.
This means that a condition expression requires a function like Is(ConditionExpression) to produce a value, which then can be used in value expressions.
Example: X * Is(A = b Or C < d)
It would be very interesting to know what kind of solution Fred favours:
(1) Allow mixing of value expressions and condition expressions.
IMHO this is very bad programming style, because these are completely different issues.
(2) Strict separation of value expressions and condition expressions.
This means that a condition expression requires a function like Is(ConditionExpression) to produce a value, which then can be used in value expressions.
Example: X * Is(A = b Or C < d)
Horst.
He will allow a mix of all kinds of operators. In my opinion there is nothing bad to that since there is no real difference between the kinds of operators:
All operators take two operands. (We forget the unary operators.)
All operators returns something.
All operators returns something different from other operators.
All operators returns the same every time they are given the same arguments.
That's all there is to it in my head. Sure, And returns something different from +, but + also returns something different from *.
All operators take two operands. (We forget the unary operators.)
All operators returns something.
All operators returns something different from other operators.
All operators returns the same every time they are given the same arguments.
That's all there is to it in my head. Sure, And returns something different from +, but + also returns something different from *.
To me this is a philosophical issue rather than a coding issue. A programming language is dealing with concepts, not just with compiler algorithms.Trond wrote:He will allow a mix of all kinds of operators. In my opinion there is nothing bad to that since there is no real difference between the kinds of operators...
A condition is true or false, which has nothing to do with values, until a value is produced based on the compiler's assignments for true and false (which could be 100 and 0, for example).
Horst.
Well, since there's no boolean types in PB, true is 1 and false is 0. Of course this is also often true in languages with boolean types, but there is a subtle difference I think.
In my opinion it is also dangerous to think of everything as concepts. Many program bugs are due to subtle differences between an abstraction of how a feature works and how it actually works.
As a very simply example of this, take the spell checker in Microsoft Word. Some people think that the spell checker checks for spelling errors, and therefore they do not throughly check for spelling errors themselves after using the spellchecker in Word. Now this could have been avoided if they instead thought about the spell checker not as a program that checks the spelling but as a program that runs through a list of words and checks if your word is in the list. With the latter interpretation it is much easier to comprehend that the spell checker could fail - what if your word is not in the list?
Yes, that wasn't a perfect example as the spell checker also has some rules, but you get the idea: most abstractions hides details, and most bugs are caused by lack of attention to details.
In my opinion it is also dangerous to think of everything as concepts. Many program bugs are due to subtle differences between an abstraction of how a feature works and how it actually works.
As a very simply example of this, take the spell checker in Microsoft Word. Some people think that the spell checker checks for spelling errors, and therefore they do not throughly check for spelling errors themselves after using the spellchecker in Word. Now this could have been avoided if they instead thought about the spell checker not as a program that checks the spelling but as a program that runs through a list of words and checks if your word is in the list. With the latter interpretation it is much easier to comprehend that the spell checker could fail - what if your word is not in the list?
Yes, that wasn't a perfect example as the spell checker also has some rules, but you get the idea: most abstractions hides details, and most bugs are caused by lack of attention to details.