# A general comment on Prolog programming **URL:** \ **Category:** General\ **Created:** [July 2, 2019, 6:31pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901 "2019-07-02T18:31:09Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![prodog](https://avatars.discourse-cdn.com/v4/letter/p/57b2e6/32.png) [@prodog](https://swi-prolog.discourse.group/u/prodog)\ **Post date:** [July 2, 2019, 6:31pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/1 "2019-07-02T18:31:09Z")
I’m taking a break from coding for a bit and I felt like sharing some thoughts about Prolog programming in general. None of this is to be taken too seriously. It’s just for some lively discourse. **Prolog is my favorite language. SWI-Prolog is my favorite (by far) implementation of it.** But I must confess I have to concentrate **a lot harder** when writing Prolog code than in a procedural language (my primary job). But everything has its trade-offs and what I find as a reward for that more intense level of concentration and exactness, is that debugging the code I’ve written is **a lot, lot easier** than in a procedural language. It’s as if Prolog forces you to get your thinking correct. Than after a short burst of cleaning up a few (truly) minor syntax errors, and a slew of `singleton variable` errors, which are also very easy to correct, the code frequently runs fine the first time! This is a true delight given the opposite experience I have when debugging a procedural program. That experience usually consists of wading through tons of nested function calls and trying to disentangle improperly coupled algorithms or data structures or flat out logic errors; each of which causes an unpleasant round of alterations in the code that frequently ripple upwards and downwards the code hierarchy, with the not so infrequent _painful mass refactoring_ session. What has the experience been for the rest of you, especially those whose primary coding job is in a procedural language? What is it about Prolog that you feel promotes this unique experience? ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [July 3, 2019, 2:16pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/2 "2019-07-03T14:16:58Z")
Thanks for sharing. The need to concentrate a lot harder should largely go away over time 🙂 Pieter Adriaans used to run a business called Sylogics which did most of their early work in SWI-Prolog. Sylogics was the first sponsor of the project which resulted in the first garbage collector 🙂 At some point the business got big and C++ got a hype and became the leading language. Pieter has stated several times that a big difference was that Prolog projects rarely exceeded the estimated time, while C++ programs often did. That is the good news. Lack of typing and proper refactoring tools can make refactoring a hell and while it may be less often required it still cannot always be avoided. ---
**Author:** ![prodog](https://avatars.discourse-cdn.com/v4/letter/p/57b2e6/32.png) [@prodog](https://swi-prolog.discourse.group/u/prodog)\ **Post date:** [July 3, 2019, 3:27pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/3 "2019-07-03T15:27:56Z")
> [@jan](#): > > Prolog projects rarely exceeded the estimated time, while C++ programs often did. Love that quote! 🙂 ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [July 3, 2019, 4:55pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/4 "2019-07-03T16:55:21Z")
> [@jan](#): > > Pieter has stated several times that a big difference was that Prolog projects rarely exceeded the estimated time, while C++ programs often did. I am curious, what would explain this … why where estimates better in line when coding was done in Prolog … Dan ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [July 3, 2019, 5:18pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/5 "2019-07-03T17:18:28Z")
We can probably only speculate on that. AFAIK there is not much research done on language comparison as to what it means for a normal development and maintenance phase. That is why it remains mostly belief or religion ☹ ---
**Author:** ![dklyons81](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/dklyons81/32/29_2.png) [@dklyons81](https://swi-prolog.discourse.group/u/dklyons81)\ **Post date:** [July 3, 2019, 5:28pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/6 "2019-07-03T17:28:01Z")
I’m an amateur, probably intermediate level Prolog programmer, so take it with a grain of salt. I find it easier to represent many problems in Prolog. There is a beautiful fluidity between representation of data and the computation. It took a long time to get here, but now that I have an adequate mental model of Prolog’s execution and I don’t get surprised too often, I find I can leverage it pretty easily. You get the benefits of homoiconicity for creating inner DSLs (DCGs, library(aggregate), etc.) without having to stab your eyes out (Lisp). Often it feels like just adequately describing the relationships between things in your problem is enough, the solution magically falls out. I think this is what you mean by concentrating: in Java you start a project and you can write dozens of lines of code before you have even really started to think about your problem. In Prolog, you have a blank page, you must begin by thinking about how you’re going to represent things and their relationships. Often you find that your understanding of those relationships is incomplete. Prolog forces you to reckon with that early. Sometimes you see a few lines of Prolog that make you aware that it is possible to be clever or funny or have a really deep insight and make Prolog do so much of the work that there’s almost nothing left for you to do. `...//0` is a good example in the `evil` pack, that weird 8 queens solution that was discussed on Stack Overflow last month is another. I am still frequently surprised by things you can do in a page or less of Prolog. Somehow it has continued to be magical to me and often brightens my day. SWI in particular is wonderful because it “just works,” comes with a lot of cool toys (I haven’t learned how to use half the stuff in the standard library yet) and has excellent ergonomics (colorful TTY, output simplifications). We all owe Jan et. al. a huge debt for this amazing project, I can’t imagine what life would be like without it. ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [July 3, 2019, 5:41pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/7 "2019-07-03T17:41:36Z")
Nice … Yes, i think, i experienced the relational thinking as well. I am recently, also, curious about Mercury and what its approaches to (algebraic?) types and modes might do to thinking about problems. Dan ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [July 3, 2019, 6:05pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/8 "2019-07-03T18:05:52Z")
Early on, there was some work on program comprehension (Soloway, comes to my mind), > **[Mental models and software maintenance](https://www.academia.edu/4681947/Mental_models_and_software_maintenance)** > > Mental models and software maintenance (and a more recent paper doing fMRI studies to identify cognitive efforts during development: [https://peitek.com/ICSE18\_DS\_Peitek.pdf](https://peitek.com/ICSE18_DS_Peitek.pdf)) Perhaps, it is indeed the gap between specification and implementation, that is much more narrow in Prolog – and hence the cognitive overhead in jumping between top-down and bottom-up interpretations is narrower. In the end of the day, where is most programming time spent – in internal cognitive “comprehension loops” 🙂 Dan ---
**Author:** ![prodog](https://avatars.discourse-cdn.com/v4/letter/p/57b2e6/32.png) [@prodog](https://swi-prolog.discourse.group/u/prodog)\ **Post date:** [July 3, 2019, 7:38pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/9 "2019-07-03T19:38:55Z")
> [@dklyons81](#): > > SWI in particular is wonderful because it “just works,” comes with a lot of cool toys (I haven’t learned how to use half the stuff in the standard library yet) and has excellent ergonomics (colorful TTY, output simplifications). We all owe Jan et. al. a huge debt for this amazing project, I can’t imagine what life would be like without it. Agreed! And don’t forget the indispensable graphical debugger. I tried living with plain text “box debuggers” in the past and well, it was painful. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [July 5, 2019, 6:33pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/10 "2019-07-05T18:33:58Z")
For debugging Prolog – when I find a defective predicate, it’s often easier to simply delete it and rewrite it from scratch. But I might be abnormal … my favourite debugging tools are portray/1, print\_term/3, and library(rdet). [And my editor is emacs.] ---
**Author:** ![prodog](https://avatars.discourse-cdn.com/v4/letter/p/57b2e6/32.png) [@prodog](https://swi-prolog.discourse.group/u/prodog)\ **Post date:** [July 5, 2019, 9:21pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/11 "2019-07-05T21:21:45Z")
> [@peter.ludemann](#): > > portray/1 All the time, or only for some complex term you want formatted in a particular way? What does _rdet_ do? I don’t see it in the reference manual listing: [https://www.swi-prolog.org/search?for=library](https://www.swi-prolog.org/search?for=library) ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [July 5, 2019, 9:42pm UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/12 "2019-07-05T21:42:45Z")
> [@prodog](#): > > [portray/1] All the time, or only for some complex term you want formatted in a particular way? For complex and large terms (some of my terms have thousands of elements, but the default depth settings for terms don’t do what I want). ```prolog user:portray(Term) :- %% in the following, format/2 is used because %% print_message(warning, E) gives an infinite recursion. E = error(_, _), % avoid trapping abort, timeout, etc. catch(my_portray(Term), E, format('EXCEPTION:portray(~q)', [Term])). ``` > [@prodog](#): > > What does _rdet_ do? [https://www.swi-prolog.org/pack/list?p=rdet](https://www.swi-prolog.org/pack/list?p=rdet) > **[GitHub - rla/rdet: Runtime determinacy checker for SWI-Prolog](https://github.com/rla/rdet)** > > Runtime determinacy checker for SWI-Prolog. Contribute to rla/rdet development by creating an account on GitHub. But what I _really_ want (and have been too lazy to write) is something that catches both failure and non-determinicity. ---
**Author:** ![emacstheviking](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/emacstheviking/32/228_2.png) [@emacstheviking](https://swi-prolog.discourse.group/u/emacstheviking)\ **Post date:** [April 4, 2020, 8:02am UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/13 "2020-04-04T08:02:41Z")
You summed it up for me perfectly! ---
**Author:** ![dtonhofer](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/dtonhofer/32/902_2.png) [@dtonhofer](https://swi-prolog.discourse.group/u/dtonhofer)\ **Post date:** [April 5, 2020, 10:09am UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/14 "2020-04-05T10:09:21Z")
_For debugging Prolog – when I find a defective predicate, it’s often easier to simply delete it and rewrite it from scratch._ Yes, this. Sadly also often the case even in imperative programming languages even though what they actually _do_ in a given amount of code is not particularly exciting. - **Imperative Languages** : Model datastructures, create them (possibly delete them if you don’t have a GC), and modify them, step by step. Interactive computation (as opposed to algorithms with no I/O) is natural. - **Functional Languages** : Model datastructures, create new ones from existing ones, one reduction at a time. Interactive computation is done by “oracle functions” that perform I/O. - **Prolog-style Logic Programming** : Model datastructures by constraining their relationships, then letting the Prolog Processor search for the ones that fulfill the constraints. Interactive computation is done by “oracle predicates” that perform I/O. (The latter to be resolved at some point by starting to model the problem with linear logic I suppose.) - **Curry-style Functional-Logic Programming**. I don’t know. ---
**Author:** ![dtonhofer](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/dtonhofer/32/902_2.png) [@dtonhofer](https://swi-prolog.discourse.group/u/dtonhofer)\ **Post date:** [April 5, 2020, 11:09am UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/15 "2020-04-05T11:09:55Z")
That sounds like something in line with what can be found in [IEEE Software](https://en.wikipedia.org/wiki/IEEE_Software). They could use some Logic Programming content. Nothing since … '95? That’s a conspiracy. ![IEEE Software Prolog citations](https://global.discourse-cdn.com/free1/uploads/swiprolog/original/1X/0681b53a2a925ddc62d49ee561e19db8ab3e5cc5.png) These covers of '19 give the general tone: ![2019 IEEE Software Covers Small](https://global.discourse-cdn.com/free1/uploads/swiprolog/original/1X/c153c953316af930b74d39a5ca6f3dd0e5d26a60.png) ---
**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://swi-prolog.discourse.group/u/EricGT)\ **Post date:** [April 5, 2020, 11:15am UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/16 "2020-04-05T11:15:39Z")
Please try to refrain from posting images that are stored on Discourse unless necessary. The agreement for using Discourse comes with a limited amount of space and images don’t always have a high signal to memory ratio. 🙂 ---
**Author:** ![dtonhofer](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/dtonhofer/32/902_2.png) [@dtonhofer](https://swi-prolog.discourse.group/u/dtonhofer)\ **Post date:** [April 5, 2020, 11:28am UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/17 "2020-04-05T11:28:01Z")
Oh okay. What are they doing with their shingled disks? Let me clean this up… … DONE! Links go to imgur instead. ---
**Author:** ![pmoura](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/pmoura/32/11_2.png) [@pmoura](https://swi-prolog.discourse.group/u/pmoura)\ **Post date:** [April 5, 2020, 11:40am UTC](https://swi-prolog.discourse.group/t/a-general-comment-on-prolog-programming/901/18 "2020-04-05T11:40:54Z")
> [@dtonhofer](#): > > That sounds like something in line with what can be found in [IEEE Software](https://en.wikipedia.org/wiki/IEEE_Software). They could use some Logic Programming content. Nothing since … '95? That’s a conspiracy. You’re not far from the true. Several years ago there was a coordinated attempt to strikeout logic programming from official CS curricula guidelines from IEEE and ACM.