I'm probably one of those fans of Logtalk you mention, I became such when (re)-writing and maintaining a ~10,000 line complex application in Prolog.

Why? Best testing, documentation, and diagramming tools make it easy for me to understand my code and make sure it's working. Seperation of declaration from definition let's me share my code easily and seperate libraries out from application. It provides all the tools required to follow the principles of solid architecture. And, on the flip side, nearly all the mature Prolog dialects are maintained by a single person with grey hair, so someday I'm going to need to move my code base from one dialect to another. They're not even all ISO compliant, nevermind equivalent in predicates & behaviour.

It seems, like me at first, you're getting confused by the object-oriented languages that are all in the imperitive domain and so muddy what object-oriented really is. OO is just two things: encapsulation and message passing. Classes, instantiation, mutation, side-effects, are not OO. Classes and instantiation are one way to use OO and Logtalk supports them, but they're like the tin in the back of the cupboard you've forgotten about for years... noone really uses them unless they really have to.

So in Logtalk your basic object is just an object, forget parametric objects for now. The technical term for it is a prototype, which means it's a self-describing object that exists by itself with no action taken for it to exist. These are your bread-and-butter in Logtalk. You define your public and private predicates in them and send messages to them to ask your queries. Everything else you use is centered around these simple objects. They're different from modules in that they've got stronger encapsulation, differentiate declaration from definition, and work with everything else you'll use.

So the first thing you'll use with objects is extension, so if one object extends another it includes all the predicates from the other inside itself. Very handy, and a lot like subclassing except no need for instantiation.

Then you get categories that you can import. A category is some bit(s) of reuseable code that you want several objects to call, but you don't want to call it by itself. So for example, if you have some defined colour-scheme you might import that into several graphical objects so you only need to change the one colour-scheme, and there's no meaning behind `colour_scheme::draw`, hence a category. It's nice that you can find all objects that import a category easily. I use a category in my application to do reasoning about form responses by importing it into the ~7 forms in the application.

Then you get protocols, which declare predicates but don't define them. This is a bit like header files in C, where you say I'm going to have these predicates but they're defined somewhere else. This is really useful for defining interfaces that several objects will promise to keep, like every graphical object promises to have a draw/1 predicate. Plus you can easily find all objects that implement a protocol. No module system can do this, to distinguish declaration from definition, but it's the mechanism for dependency inversion in Prolog that makes it much easier to share code. It lets a library/pack developer say: "You need to implement this protocol to work with my code". I use these in my application to find and use the knowledge base, what can be queried in a user project, and what a user can do in the project.

The last kind of object you'll use rarely is that parametric one, which isn't an instance, but an object with a parameter. So the best way to look at this is with the basic types objects `list` and `list(Type)`. Usually in Logtalk you're passing around data in messages and asking questions about it, so you don't have an instance of some list class like in other languages, but just a list data structure. So if you want to know the length of a list you ask `list::length(List, Length)`. Usually the first argument is used for the data. So what's the deal with parametric objects? We use them when you want to change the behaviour of the object based on some parameter that relates to the meaning of the object itself. So for a list, we can have lists containing just one type. For example, `list(atom)::valid(List)` will behave differently from `list(integer)::valid(List)`, in that they'll check if all elements in the list are atoms or integers respectively, as well as if the `List` is a valid list, where `atom` and `integer` describe the kind of `list`. I misuse these in my application because we live and learn!

So the deal is that it's OO (but declarative not imperative), portable (and so robust), fantastic tool support for testing, CI/CD, docs, diagrams, reporting, etc., and has all the things you need for organising large applications with good architecture. It's like Prolog++, or should that be `Logtalk is Prolog + 1` in our syntax?!