4 ms·

Excellent and succinct article on the use of "Decision Tables". This is a fundamental technique in Software Development but is rarely taught/known nowadays. Se

Excellent and succinct article on the use of "Decision Tables". This is a fundamental technique in Software Development but is rarely taught/known nowadays. See also : 1) Hillel Wayne - https://www.hillelwayne.com/post/decision-tables/ https://www.hillelwayne.com/post/decision-tables/ and https://www.hillelwayne.com/post/decision-table-patterns/ https://www.hillelwayne.com/post/decision-table-patterns/ 2) Parnas Tables : A Practical Formalism (pdf) - https://cs.uwaterloo.ca/~jmatlee/Talks/Parnas01.pdf https://cs.uwaterloo.ca/~jmatlee/Talks/Parnas01.pdf 3) Tabular Expressions and their Relational Semantics (pdf) - http://www.cas.mcmaster.ca/~wassyng/FIJanWas.pdf http://www.cas.mcmaster.ca/~wassyng/FIJanWas.pdf

082349872349872 3y ago
Considering that defining functions by sets of pattern matched clauses is a thing in more and more languages, it's rarely known for some values of "rarely".
- rramadass 3y ago
  The article is not just about using decision tables at the code level but as a design methodology right from requirements stage.
- AdieuToLogic 3y ago
  A key difference between pattern matching and decision tables is the intrinsic flexibility of the latter at the expense of simplicity the former provides. Whereas pattern matching most often encodes branching statically by what is explicitly encoded, decision tables allow for runtime branching based on workflow context. Both have their strengths and weaknesses and, IMHO, the choice as to which to use is situational. Another related technique which employs a bit of both of these approaches is the Visitor pattern[0]. 0 - https://en.wikipedia.org/wiki/Visitor_pattern https://en.wikipedia.org/wiki/Visitor_pattern
gopher_space 3y ago
> but is rarely taught/known nowadays If you don't need to codec through English there isn't much of a point. It's easy to work with ctrl-v'd spreadsheet formulas and hard to create a written narrative around them.
- rramadass 3y ago
  > If you don't need to code through English there isn't much of a point. Disagree. The intent is to think through and write down the requirements unambiguously from problem domain so that it can be mapped easily to solution domain.
  - gopher_space 3y ago
    You've misquoted me, but I should have written it like CODEC. I agree on intent, and probably agree on usefulness, but I think my point was more that this is an older process from a time before instant and direct communication. I see it as introducing a layer of thought that doesn't need to exist if I can just ask someone from the source domain to send me their notes and walk me through them. We're probably using the same data format by now. Again, I'm not saying the method isn't useful or appropriate, just that you won't see it as often now thanks to easier communication.
    - rramadass 3y ago
      > You've misquoted me, but I should have written it like CODEC. My mistake, i thought you meant "code" where you wrote "codec". > my point was more that this is an older process from a time before instant and direct communication. I see it as introducing a layer of thought that doesn't need to exist if I can just ask someone from the source domain to send me their notes and walk me through them. Not quite true. No amount of instant/direct communication can help in removing ambiguity from "normal" Human communication. You need to have a method which enforces rigour and precision in the communication technique. That's what Decision Tables and other formal/mathematical methods help you with.
AdieuToLogic 3y ago
And "Decision Tables" often lead one into the wonderful world of Finite State Machines[0], another fundamental concept "rarely taught/known nowadays." The applicability of both in many problem domains remains a source of pleasant surprise to me to this day. 0 - https://en.wikipedia.org/wiki/Finite-state_machine https://en.wikipedia.org/wiki/Finite-state_machine
- 082349872349872 3y ago
  As a non-CS major who had encountered finite state machines in my early teens, it boggles my mind to consider that nowadays someone could successfully get through a CS curriculum without them. (a trie ain't nothing but a degenerate state machine) On second thought, this is a wonderful hypothesis, because it would explain so much about the modern software environment...
  - 3abiton 3y ago
    What makes them essential? Never have I encountered them
    - zby 3y ago
      They are the Turing Machine without the (infinite) tape. What is your favourite abstraction of computer?
      - egormakarov 3y ago
        About 100kb of carefully crafted yaml configs
    - thebruce87m 3y ago
      They are used extensively in embedded software. A device will be in one of several states - running, sleep, configuration, log download and so on. Each state is a C function (for me). I normally have entry/exit functions for each state too so that you set up/tear down the hardware needed for each. As you add more states, you do not need to edit the existing states - well only the bits where you need to transition to the new state. This makes it much easier to maintain and reason about. Each subsystem can be its own state machine too.

082349872349872 3y ago

Considering that defining functions by sets of pattern matched clauses is a thing in more and more languages, it's rarely known for some values of "rarely".

rramadass 3y ago
The article is not just about using decision tables at the code level but as a design methodology right from requirements stage.
AdieuToLogic 3y ago
A key difference between pattern matching and decision tables is the intrinsic flexibility of the latter at the expense of simplicity the former provides. Whereas pattern matching most often encodes branching statically by what is explicitly encoded, decision tables allow for runtime branching based on workflow context. Both have their strengths and weaknesses and, IMHO, the choice as to which to use is situational. Another related technique which employs a bit of both of these approaches is the Visitor pattern[0]. 0 - https://en.wikipedia.org/wiki/Visitor_pattern https://en.wikipedia.org/wiki/Visitor_pattern

gopher_space 3y ago

> but is rarely taught/known nowadays If you don't need to codec through English there isn't much of a point. It's easy to work with ctrl-v'd spreadsheet formulas and hard to create a written narrative around them.

rramadass 3y ago
> If you don't need to code through English there isn't much of a point. Disagree. The intent is to think through and write down the requirements unambiguously from problem domain so that it can be mapped easily to solution domain.
- gopher_space 3y ago
  You've misquoted me, but I should have written it like CODEC. I agree on intent, and probably agree on usefulness, but I think my point was more that this is an older process from a time before instant and direct communication. I see it as introducing a layer of thought that doesn't need to exist if I can just ask someone from the source domain to send me their notes and walk me through them. We're probably using the same data format by now. Again, I'm not saying the method isn't useful or appropriate, just that you won't see it as often now thanks to easier communication.
  - rramadass 3y ago
    > You've misquoted me, but I should have written it like CODEC. My mistake, i thought you meant "code" where you wrote "codec". > my point was more that this is an older process from a time before instant and direct communication. I see it as introducing a layer of thought that doesn't need to exist if I can just ask someone from the source domain to send me their notes and walk me through them. Not quite true. No amount of instant/direct communication can help in removing ambiguity from "normal" Human communication. You need to have a method which enforces rigour and precision in the communication technique. That's what Decision Tables and other formal/mathematical methods help you with.

AdieuToLogic 3y ago

And "Decision Tables" often lead one into the wonderful world of Finite State Machines[0], another fundamental concept "rarely taught/known nowadays." The applicability of both in many problem domains remains a source of pleasant surprise to me to this day. 0 - https://en.wikipedia.org/wiki/Finite-state_machine https://en.wikipedia.org/wiki/Finite-state_machine

082349872349872 3y ago
As a non-CS major who had encountered finite state machines in my early teens, it boggles my mind to consider that nowadays someone could successfully get through a CS curriculum without them. (a trie ain't nothing but a degenerate state machine) On second thought, this is a wonderful hypothesis, because it would explain so much about the modern software environment...
- 3abiton 3y ago
  What makes them essential? Never have I encountered them
  - zby 3y ago
    They are the Turing Machine without the (infinite) tape. What is your favourite abstraction of computer?
    - egormakarov 3y ago
      About 100kb of carefully crafted yaml configs
  - thebruce87m 3y ago
    They are used extensively in embedded software. A device will be in one of several states - running, sleep, configuration, log download and so on. Each state is a C function (for me). I normally have entry/exit functions for each state too so that you set up/tear down the hardware needed for each. As you add more states, you do not need to edit the existing states - well only the bits where you need to transition to the new state. This makes it much easier to maintain and reason about. Each subsystem can be its own state machine too.