3 ms·

Sounds like the kind of business logic where Prolog would really shine.

reginaldo 15y ago
Yes. Sometimes I think a good way to organize an enterprise system would be to make a trivial CRUD "layer" (no validations there) and then write a bunch of Prolog-clause-like rules. The rules would be the big and interesting part of the system, of course. The system would have to be intelligent enough so that, for performance reasons, after input, only the rules that could possibly affect the input would be run. But then in my modest experience these systems are so complex that sometimes for a simple new input you have to validate a whole bunch of things. I currently develop health care related software here in Brazil. Total chaos. Once I was talking to a doctor, and he said engineers think mostly about the patterns but doctors think mostly about the exceptions. I think the same applies to business. The doctor in question of course liked our system but had a huge list of feature requests (to treat exceptions).
gaius 15y ago
It was written in Smalltalk.
- masklinn 15y ago
  C3 was indeed, but payroll systems have been written in pretty much every language under the sun, I'm guessing chollida1 was talking generalities (and the mess described in the article is the kind of stuff you find in every payroll system)
  - chollida1 15y ago
    > I'm guessing chollida1 was talking generalities I was yes.
Duff 15y ago
Totally. I used to write event handling rules for the Tivoli Enterprise Console, which used a Prolog dialect and a godawful DSL based on prolog. I had a ton of fun doing it... basically you had to write rules to normalize SMTP traps from various vendors, and take action based on them. Network vendors did all sorts of bizarre things -- one ATM would periodically send a "Interface Down" event, with an attribute set that meant that the "Down" event actually meant up! The hard part was actually doing anything with the events. The regime in charge of my division had a deep seated fear of automatic actions, even actions as simple as opening a trouble ticket.

Yes. Sometimes I think a good way to organize an enterprise system would be to make a trivial CRUD "layer" (no validations there) and then write a bunch of Prolog-clause-like rules. The rules would be the big and interesting part of the system, of course. The system would have to be intelligent enough so that, for performance reasons, after input, only the rules that could possibly affect the input would be run. But then in my modest experience these systems are so complex that sometimes for a simple new input you have to validate a whole bunch of things. I currently develop health care related software here in Brazil. Total chaos. Once I was talking to a doctor, and he said engineers think mostly about the patterns but doctors think mostly about the exceptions. I think the same applies to business. The doctor in question of course liked our system but had a huge list of feature requests (to treat exceptions).

gaius 15y ago

It was written in Smalltalk.

masklinn 15y ago
C3 was indeed, but payroll systems have been written in pretty much every language under the sun, I'm guessing chollida1 was talking generalities (and the mess described in the article is the kind of stuff you find in every payroll system)
- chollida1 15y ago
  > I'm guessing chollida1 was talking generalities I was yes.

Duff 15y ago

Totally. I used to write event handling rules for the Tivoli Enterprise Console, which used a Prolog dialect and a godawful DSL based on prolog. I had a ton of fun doing it... basically you had to write rules to normalize SMTP traps from various vendors, and take action based on them. Network vendors did all sorts of bizarre things -- one ATM would periodically send a "Interface Down" event, with an attribute set that meant that the "Down" event actually meant up! The hard part was actually doing anything with the events. The regime in charge of my division had a deep seated fear of automatic actions, even actions as simple as opening a trouble ticket.