Not ( Having a Computer Science Background )
The FileMaker developer community seems to consist of people with quite a wide range of backgrounds, much more so than is the case with developers from other programming languages and software development platforms. I suspect this is a consequence of the rapid application development (RAD) nature of the platform and its lower learning curve. This makes it possible for individuals to change course in their careers once they serendipitously encounter FileMaker and see how easy and fun software development can be.
This diversity of backgrounds is a strength of the FileMaker platform, but one of the consequences is that many of the developers come to FileMaker without much formal computer science training.
This blog post is intended to provide one small, tiny lesson that I recall from one of my computer science classes (taken long ago). The "lesson" has to do with Boolean algebra which describes the rules for how Boolean operators (AND, OR, NOT) are evaluated.
One of my colleagues, someone who has taken up FileMaker development just a few months ago, recently asked me the following question:
De Morgan's Laws
To find out the answer, we have to learn about De Morgan's laws. There are two of them:
- not (A or B) = not A and not B
- not (A and B) = not A or not B
With this knowledge under our belt, we can now rewrite the original expression as:
not ( A or B or C or D )
The "Hide object when" calculation
There are occasions when it's easier to think about when something should be false instead of when it should be true. An example of this is the "Hide object when" FileMaker calculation. For me, it's much easier to think about when an object should be displayed instead of when it should be hidden.
The De Morgan's laws are very useful in these situations. For instance, suppose we have the following expression for when an object should be shown:
( not A or not B ) and ( not C or not D ) // display object
I can negate this so that it can be used in the "Hide object when" calculation.
not ( ( not A or not B ) and ( not C or not D ) ) // hide object = not ( not A or not B ) or not ( not C or not D ) = ( A and B ) or ( C and D )
Of course, we could have just kept it as this:
not ( ( not A or not B ) and ( not C or not D ) ) // hide object
I tend to go with whichever one I think will be easier to understand later on, in case I (or some other developer) have to return to this calculation down the road.