My (s/Nine/Ten) Reasons, why I decided to port my code to Logtalk


Here are my ten key reasons why i decided to port my code to Logtalk, with swi prolog as my base language – and, its a key learning experience as well:

  1. I want to stay in Prolog and the Relational Programming paradigm, but need more language support in engineering my code.

  2. I noticed that the, more or less flat space, of my swi-prolog code, when it came to handling multiple parallel version, became unmanagable – instead of reworking code into modules, it makes more sense to me to use a fuller OO approach.

  3. the object paradigm in logtalk, is unlike imperative OO, in the same fundamental sense, that OO languages today are not declarative. There is no notion of encapsulated state, instead state is inherently dynamic and relational.

Its like developing a logic theory centered around objects; and so far, it helps me, think, and structure, the code in ways that were not easily possible before – hopefully, making it much more understandable, maintainable, evolvable, and version-comparable, for me and (hopefully, in the future) others.

  1. Parameteric objects are a key help in making predicates more succinct, by reducing the need for common arguments across “family” of predicates.

  2. logtalk code increases portability, in case such a need arises in the future

  3. it comes out of the box with robust multithreading and an event broadcasting system that will save me much effort later on.

  4. its a pre-processed language – so a lot of the dynamic overhead (such as dynamic binding) is avoided (unlike, say, in C++) – while enabling object hierarchies – as or if needed – currently, i am working mostly object based.

  5. it can work directly with prolog facts as well – creating light weight access to facts, and not necessarily requiring fuller object machinery it offers - parameterized objects are very helpful here as well.

  6. it has advanced features such as Expected, Options, etc. that are not (directly) available in swi-Prolog, allowing to create railway-oriented programs more naturally …

  7. Logtalk inlines certain expressions automatically (e.g. binary operations) – which is not yet implemented (as far as i know) in swi-prolog