3 ms·
I've worked mostly in enterprise software the past 24 years, and current and prior job have been in security companies. This is far from academia, and I've nev
by nwatson 10y ago
I've worked mostly in enterprise software the past 24 years, and current and prior job have been in security companies. This is far from academia, and I've never seen Prolog or other logic-based approaches mentioned, or even LISP-ey or other AI-ish languages / approaches for the most part. There are places, though, where it would have been useful ... example ...
In my immediately prior job I had to deal with some convoluted XML standards called OVAL and XCCDF (from the same general folks that bring you the term "CVE" for computer vulnerabilities) that express "rules" for gathering data from systems and analyzing the data to determine whether the remote system conformed to security best practices. I wish those developing the standards had dealt before with Prolog because the rules and engine could so much more easily have been split into (a) a Prolog-based rule engine; and (b) a low-level telemetry component to gather data from the remote system(s). The XML-based "reproduction" of a subset of Prolog was very limited, not very expressive, and artificially constrained a rule writer to not be able to deal effectively with many conditions you'd naturally want to check for. Also, to extend this standard to look beyond the scope of a single machine will be very hard -- people these days naturally want to evaluate conditions across an entire group of related machines, cloud accounts, containers, VMs, etc. There's no way XCCDF or OVAL will deal effectively with that any time soon, whereas Prolog + telemetry would have addressed that very easily.
We licensed a very good engine for dealing with the XCCDF/OVAL execution (look up "jOVAL"). However I think wistfully back to the first days at that startup and think that with a good computing foundation our lives could have been so much easier. The company was a ... mess ... in other ways and will visit Mr. Joyboy soon https://www.youtube.com/watch?v=-edybFkBiO4 https://www.youtube.com/watch?v=-edybFkBiO4 .
(Hmmm, Prolog + XCCDF turned up something interesting since I last checked a long time ago: http://www.academia.edu/20069871/SCAP_based_configuration_analytics_for_comprehensive_compliance_checking http://www.academia.edu/20069871/SCAP_based_configuration_an...)
- tannhaeuser 10y agoInteresting. More often than as the primary product or deliverable of a project, I've personally used Prolog for development support, such as for combinatorial test case generation, parsers and DSLs, metadata stores and code generators, and also as a theorem prover of sorts/decision procedure for properties of process models. I always thought Prolog really shines in these roles. I also often wondered why folks spend big time on "rules engines" (glorified RETE forward-chaining engines) but don't consider Prolog, it being an ISO-standard language with multiple mature implementations.
- naasking 10y agoI think the focus on RETE is due to the implicit efficiency advantages of the more restricted execution model. Unification and backtracking aren't always friendly or easily optimized.
- nickpsecurity 10y agoIn addition to naasking, I'll also say that it might be intuitive to people used to describing business rules and processes as a series of conditional steps. Maps more naturally to forward chaining. I mean, it's basically If-Then rules almost anyone is familiar with. Other style requires a bit of change in thinking.
- mark_l_watson 10y agoRate is optimized for very large rules sets, but performs poorly with large working data memories.