3 ms·

I have learned some prolog, and I really enjoyed it. The only problem I encountered is that I had a hard time moving to real world practical uses of the languag

I have learned some prolog, and I really enjoyed it. The only problem I encountered is that I had a hard time moving to real world practical uses of the language. I enjoyed the language for the exercises I had in my learning resources, but I never found a problem I could use it for myself.

Jtsummers 7y ago
Potential use-case for you: I prototyped (but did not fully implement, no management support) test case generation using Prolog. In our case, it was (grossly simplified) a messaging system with a well-defined protocol running in an embedded device. When some message was sent, we anticipated a response back within some time window with some content based on what was initially sent (NB: This is only one of many potential scenarios). Let's say that some complex computation is happening on the remote end, based on the series of messages transmitted you eventually expect a response that will be the result of computation on those inputs. You could manually calculate what that response should be, which fundamentally limits how many test cases you can generate and potentially leads to biased tests (assumptions of system behavior or design by the testers), or you can do it automatically. In our case, Prolog (or something like it) could be used to model the system and generate arbitrary test cases for us. It acts as the oracle (if you're familiar with property-based testing, this is where I was heading with my effort). You can now use Prolog to generate arbitrary input sequences with a known output (depending on the fidelity of your model to the spec) and generate test sequences for your system and compare the output. And if your Prolog model is sufficiently developed, it can also be used for other development/testing efforts. If you get some response, what series of inputs may have produced it (this may be computationally infeasible, but maybe you know or can assume some of the inputs to constrain the search space). Or if your manual testing (throwing bodies at the problem) results in unexpected behavior, you can check what the model produces using the recorded inputs. Perhaps your system performs correctly, but the tester or user's mental model was incorrect. Or perhaps they found an actual implementation error. A nice thing about using Prolog, vice using a second "reference" implementation in a more traditional language like C++, is that the Prolog model is often much simpler than the full system being developed, whereas (for us) a reference implementation would've been of comparable size. In our case, it could be the difference between 10k lines of code versus 100k lines of code. The downside of this Prolog approach is performance, a C++ reference implementation may be able to run in real-time (or close enough) and could be directly substituted for the unit under test to verify other aspects of the test rig or system. Or, in a multi-system test, a reference implementation could be used in place of "real" remote systems (due to cost or other constraints).
- ptsneves 7y ago
  This sounds awesome. One of the weaknesses of Test driven development always seemed to me, that ultimately a human may not be very good finding the edge cases to test. After all if he was very good then he would account for them on the code at first try. Do you have a blog post or some example code where this approach is documented. This seems genius.
  - Jtsummers 7y ago
    I do not have a blog or demo code (this was 6 or 7 years ago now). They eventually made something like this for generating tests using a SQL database and custom logic in C#. To get the idea (which I barely knew of at the time), look into property-based testing. I really liked this book: https://pragprog.com/book/fhproper/property-based-testing-with-proper-erlang-and-elixir https://pragprog.com/book/fhproper/property-based-testing-wi... It does a lot of the things I was thinking about but doesn’t build the whole system model like I wanted (and was tractable for our problem domain, it isn’t for all).

Jtsummers 7y ago

Potential use-case for you: I prototyped (but did not fully implement, no management support) test case generation using Prolog. In our case, it was (grossly simplified) a messaging system with a well-defined protocol running in an embedded device. When some message was sent, we anticipated a response back within some time window with some content based on what was initially sent (NB: This is only one of many potential scenarios). Let's say that some complex computation is happening on the remote end, based on the series of messages transmitted you eventually expect a response that will be the result of computation on those inputs. You could manually calculate what that response should be, which fundamentally limits how many test cases you can generate and potentially leads to biased tests (assumptions of system behavior or design by the testers), or you can do it automatically. In our case, Prolog (or something like it) could be used to model the system and generate arbitrary test cases for us. It acts as the oracle (if you're familiar with property-based testing, this is where I was heading with my effort). You can now use Prolog to generate arbitrary input sequences with a known output (depending on the fidelity of your model to the spec) and generate test sequences for your system and compare the output. And if your Prolog model is sufficiently developed, it can also be used for other development/testing efforts. If you get some response, what series of inputs may have produced it (this may be computationally infeasible, but maybe you know or can assume some of the inputs to constrain the search space). Or if your manual testing (throwing bodies at the problem) results in unexpected behavior, you can check what the model produces using the recorded inputs. Perhaps your system performs correctly, but the tester or user's mental model was incorrect. Or perhaps they found an actual implementation error. A nice thing about using Prolog, vice using a second "reference" implementation in a more traditional language like C++, is that the Prolog model is often much simpler than the full system being developed, whereas (for us) a reference implementation would've been of comparable size. In our case, it could be the difference between 10k lines of code versus 100k lines of code. The downside of this Prolog approach is performance, a C++ reference implementation may be able to run in real-time (or close enough) and could be directly substituted for the unit under test to verify other aspects of the test rig or system. Or, in a multi-system test, a reference implementation could be used in place of "real" remote systems (due to cost or other constraints).

ptsneves 7y ago
This sounds awesome. One of the weaknesses of Test driven development always seemed to me, that ultimately a human may not be very good finding the edge cases to test. After all if he was very good then he would account for them on the code at first try. Do you have a blog post or some example code where this approach is documented. This seems genius.
- Jtsummers 7y ago
  I do not have a blog or demo code (this was 6 or 7 years ago now). They eventually made something like this for generating tests using a SQL database and custom logic in C#. To get the idea (which I barely knew of at the time), look into property-based testing. I really liked this book: https://pragprog.com/book/fhproper/property-based-testing-with-proper-erlang-and-elixir https://pragprog.com/book/fhproper/property-based-testing-wi... It does a lot of the things I was thinking about but doesn’t build the whole system model like I wanted (and was tractable for our problem domain, it isn’t for all).