Thank you so much for sharing information about the LogicBiz V.2.0 project!
I use SWI-Prolog in my daily work, so it’s especially valuable to me to see this wonderful language being used to create serious commercial products. The very idea of building the first offline POS system in Prolog sounds very bold and innovative.
Of course, without access to the source code, it’s difficult to fully understand the work done and the implementation details. However, even what you describe—the integration with SQLCipher, the performance, the architecture—inspires immense respect.
The most important thing I took away from your post is the joyful realization that I’m not alone. It’s gratifying to know that there are like-minded people who not only use Prolog in production but also achieve impressive results with it. This gives me strength and confidence that I’ve chosen the right path.
I wish you continued development of the project and continued success! It will be very interesting to follow the news.
Thank you so much for your kind words and encouragement! It genuinely means a lot to hear this from someone who uses SWI-Prolog in their daily production work.
To be completely honest, this project started out of pure passion and a lifelong fascination with predicate logic. Seeing the core engine successfully handle millions of rows with such high efficiency using declarative paradigms has been an incredibly rewarding journey.
While the source code is currently kept private as I focus on preparing the system for local small retail deployments, I am very glad that the architectural concepts and benchmarks resonated with you. Knowing that there are fellow developers out there pushing the boundaries of Prolog in the real world gives me great confidence as well.
Thank you again for the wonderful support. I wish you continued success in your daily work with SWI-Prolog!
(P.S. Please excuse any awkward phrasing, as I do not speak English and am using an AI assistant to translate my thoughts.)
Thank you so much for your honest and heartfelt reply! It makes me twice as happy to know that your project comes from pure passion—because that’s exactly where the best tools are born.
And what a coincidence! I also use Prolog in retail, though on a smaller scale. My own daily tool is a converter that collects sales data from fiscal cash registers (KSO) and transforms them into a unified format for upload into an ERP system. It’s not as grand as your engine, but it works reliably every single day—and that alone feels like a small victory for declarative logic in the real world.
Your story inspires me to think bigger. Knowing that someone else is quietly pushing Prolog forward in production—and in retail, no less—makes me feel less alone in this niche.
I completely understand your decision to keep the source private for now, especially while preparing for local deployments. When the time comes, I would be very curious to hear more about your architectural choices (if you ever feel like sharing non-confidential details).
And please don’t worry about your English—mine comes through a translator too, as I don’t speak it either. Perhaps that makes our conversation even more genuine
Wishing you strength and joy in bringing your system to life in small shops. Keep going—you’re doing something truly valuable.
Thank you so much for your heartwarming and supportive reply! It is genuinely inspiring to connect with another developer who leverages Prolog for production systems in the retail sector.
To give you a clearer picture of my system’s architecture without breaking encapsulation, I ran a cross-reference analysis using Prolog XREF and generated a dependency graph.
The entire ecosystem is composed of roughly 19,000 lines of declarative code. As you can see from the breakdown below, “retail_brain.pl” acts as the central orchestration engine that binds all peripheral modules together:
DATABASE.PL: 1,181 lines
RETAIL_AUDIT.PL: 1,078 lines
RETAIL_BRAIN.PL: 5,929 lines
RETAIL_DISPLAY.PL: 497 lines
RETAIL_FUNCTIONAL_AUDIT.PL: 255 lines
RETAIL_MANIFESTO.PL: 464 lines
RETAIL_POS.PL: 1,154 lines
RETAIL_PRINT.PL: 793 lines
RETAIL_SECURITY.PL: 460 lines
RETAIL_SERVER.PL: 6,217 lines
Total Codebase: ~19,028 lines
Even though my predicate names and internal structures are written in Indonesian, keeping a strict separation of concerns across these modules makes the application highly predictable and solid for daily retail operations.
I have just written and uploaded a comprehensive breakdown of the core engine predicates and module interfaces in my repository. You can read the full documentation directly here:
I would love to hear your thoughts on this modular layout or how you handle dependency separation in your own Prolog tools!
I have to be honest — when I hear about a single module with 6000 lines, my first thought is: this is a strong candidate for refactoring. Not because it’s “wrong”, but because maintainability suffers. Reading, reasoning about side effects, debugging, and even testing become exponentially harder beyond ~1000 lines, regardless of whether the code is written by a human or generated by an AI.
I say this with respect, because I know you are building something complex. But in my retail Prolog projects, I’ve learned that small, focused modules with clear interfaces save far more time than they cost to create. AI can help with the refactoring too, by the way — it’s not an obstacle, it’s a tool.
If performance is the concern, I’d be genuinely curious to hear how you handle that with such large units. Maybe I’m missing something.
In any case, this is just my two cents. I’m glad we can have this kind of discussion across languages and tools.
