Why not Logtalk?

Logtalk materializes a number of design choices that may not be ideal for some Prolog programming scenarios.

Increased startup times

Starting a Logtalk application requires loading both the chosen backend Prolog system and the Logtalk compiler and runtime. This necessarily increases the time it takes to start an application. This may be an issue where very fast startup times are required (of course, this is only meaningful if the applications themselves are small compared with the size of the Logtalk compiler and runtime). Note, however, that the Logtalk compiler and runtime can be precompiled by some Prolog systems for faster loading thus minimizing startup time (e.g. SWI-Prolog supports a Quick Load Format, QLF). The same solution when available can be applied to a Logtalk application.

Compatibility with Prolog native developer tools

Although Logtalk provides a complete set of developer tools, it only supports selected native Prolog developer tools (see https://github.com/LogtalkDotOrg/logtalk3/wiki/Developer-Tools for details). Complex applications may require using both Logtalk and Prolog tools, demanding that the programmer learns how to be productive with a larger number of tools.

Dynamic binding performance

Logtalk applications making heavy use of dynamic binding may require a backend Prolog compiler with good predicate clause indexing for best performance.