[HN Gopher] Ask HN: What's Prolog like in 2024?
___________________________________________________________________
Ask HN: What's Prolog like in 2024?
Hi, i am a compsci student that stumbled upon prolog and logic
programming during my studies. While i have seen the basics of
vanilla prolog (atoms, predicates, cuts, lists and all that jazz)
and a godawful implementation of an agent communication system that
works on SICStus prolog. I would like to know more because i think
that this language might be a powerhouse in per se. Since my
studies are quite basic in this regards i would like to expand my
knowledge on it and kind of specialize myself both in this world
and another world (ontologies :D) that i really enjoy. What's
prolog like in 2024? what are you wonderful people doing with it?
thanks from a dumbass :D
Author : overclock351
Score : 398 points
Date : 2024-07-18 11:23 UTC (1 days ago)
| DamonHD wrote:
| Not quite what you asked for, but as someone using it quite a lot
| back in the late '80s during a CS&AI degree, Prolog has its
| interesting features and I'm glad I used it, but I haven't missed
| it since. I do like declarative stuff, eg CSS!, and that remains
| a good memory.
| overclock351 wrote:
| could you please expand on it? i would love to read more
| DamonHD wrote:
| Many many languages that you will encounter and use in live
| projects are primarily imperative, eg: C, C++, JavaScript.
| The describe the "how" and "in what order".
|
| While I was an undergrad I was exposed to Standard ML and
| Prolog, both of which were/are much more about declarative
| "what", though they could only practically interact with the
| actual world by side-effects and some imposed ordering (SML's
| 'ref', Prolog's cut).
|
| I am still waiting for some of the amazing stuff that was in
| SML to materialise in C++ and Java for example, less so
| anything from Prolog. For example, to search a state space I
| might use an off-the-shelf solver with good heuristics and an
| objective function written in something imperative rather
| than use Prolog.
|
| But it it really is over 30Y since I touched Prolog, so life
| in it may be very different now.
| overclock351 wrote:
| Pretty interesting stuff, thanks for sharing :D
| bux93 wrote:
| I'm not the commenter you're replying to, but in my case, I
| really enjoy the promise of "you write down the problem, not
| the solution".
|
| In an introductory prolog course you will soon find that when
| a prolog program is written to solve some problem like
| 'whats-the-next-chess-move' it's actually doing a depth first
| (and if you use the ! cut-operator, it will stop looking for
| any more solutions).
|
| But in principle, it's up to the interpreter/compiler to
| decide how to find solutions. In the same way that a C
| compiler might say "ah, you're doing tail-recursion, let me
| make a loop out of that", a prolog compiler might say "gee,
| this problem looks like it would be much more efficient to
| use simulated annealing to find some answers in a shorter
| time". That's perhaps a bit far-fetched, but a great example
| is Datalog which has solvers that parallelize the search. You
| don't write a parallel algorithm, it's just that a parallel
| algorithm is used to solve your problem.
|
| A specific feature I miss in other programming approaches is
| that if you can find the answer to the question "is A a child
| of B?", the very same code is also the function to find out
| all of A's children, or all of B's parents. No need to
| explicitly code a loop, or to create the inverse function.
| grose wrote:
| Speaking of CSS, :has() [https://developer.mozilla.org/en-
| US/docs/Web/CSS/:has] brings it closer to the glory of Prolog.
| I cannot wait to abuse it in avant-garde Logic-Driven-
| Development.
| tomstuart wrote:
| Definitive reference:
| https://www.urbanautomaton.com/blog/2015/08/10/the-pledge-to...
| overclock351 wrote:
| Looks fun :D, i think that if i ask my manager to build
| something out of Prolog i would probably get stab... i mean
| fired since most of us work in OOP. I would love to be that
| insane one asking for that :D.
| Avshalom wrote:
| You can use https://logtalk.org for oop in Prolog, use it on
| top of SWI and you have bidirectional bridges to Python an
| Java
|
| https://www.swi-prolog.org/FAQ/Python.md
|
| https://www.swi-
| prolog.org/pldoc/doc_for?object=section(%27p...
| chx wrote:
| > Prolog is not suitable for any problem domain, although this
| is more readily apparent for some domains than others.
|
| Fuckin' A.
| jjtheblunt wrote:
| what does that mean?
| marcosdumay wrote:
| It's an except from the article. Getting an explanation out
| of context is worthless.
| jjtheblunt wrote:
| Excerpt from what article? (edit: i see you're referring
| to the indented quote from the article, but i was asking
| what the "fuckin a." thing meant.)
| mkl wrote:
| https://www.urbandictionary.com/define.php?term=fucking%2
| 0a
| nickpeterson wrote:
| I only have one thing to say to this man, "hey! Quit stealing
| my moves!"
| DonHopkins wrote:
| If it's an official production system you want, then use OPS-5,
| not Prolog!
|
| https://en.wikipedia.org/wiki/OPS5
|
| >OPS5 is a rule-based or production system computer language,
| notable as the first such language to be used in a successful
| expert system, the R1/XCON system used to configure VAX
| computers.
|
| >The OPS (said to be short for "Official Production System")
| family was developed in the late 1970s by Charles Forgy while
| at Carnegie Mellon University. Allen Newell's research group in
| artificial intelligence had been working on production systems
| for some time, but Forgy's implementation, based on his Rete
| algorithm, was especially efficient, sufficiently so that it
| was possible to scale up to larger problems involving hundreds
| or thousands of rules.
| wduquette wrote:
| I used DEC's VAX OPS5 for a couple years about around 1990. I
| quite liked it, and the later versions had some really nice
| extensions over Forgy's original design.
|
| Then we discovered that our particular rule base could easily
| be ported into C using a sequence of nested if/thens that ran
| _much_ faster, and we stopped using OPS5. It was a great tool
| for doing the initial development, though.
| drmeister wrote:
| Dang, substitute Lisp for Prolog and this describes me.
| Seriously though - Prolog is an awesome tool to have in your
| toolbox. I've implemented Prolog-like logic programming
| solutions in several places in my 40+ years of programming.
| Like rules for assigning molecular mechanics force field atom
| types.
| infinite8s wrote:
| > Like rules for assigning molecular mechanics force field
| atom types.
|
| Can you describe a bit more how prolog helped you here?
| Thanks!
| Suppafly wrote:
| >Q: What if Prolog is not suitable for my employer's problem
| domain?
|
| >
|
| >Prolog is not suitable for any problem domain, although this
| is more readily apparent for some domains than others.
|
| At least they are honest about it LOL
| hendler wrote:
| Prolog itself is still developed and used in various settings
| (mostly swi-prolog?), but other languages and logic engines solve
| domain specific but similar problems better (rule engines, formal
| proof verifiers, etc). For exploratory work it can be useful.
|
| I have tried to use it in combination will LLMs unsuccessfully,
| partly because the domain was not specific enough. Otherwise you
| need a lot of real world knowledge and a large fact database.
|
| Logic engines for first order logic in RDF/OWL also have
| interesting logical inference abilities, like graphdbs.
|
| Any programming language can do "logic" and the work at MIT/CSAIL
| in probabilistic programming may turn out to be a better way to
| combine fuzzy logic and formal proofs.
|
| Not sure this answers your question, but maybe this points
| towards some interesting directions.
| overclock351 wrote:
| Any answer here is a good one since the question is soooo
| unspecific :D. My professor is a staunch advocate for RDF/OWL,
| inference engines and stuff like that (hence why i also
| mentioned ontologies :D).
|
| The thing is that i think that the language itself has so much
| untapped potential and the world that i dived into with my
| studies is so vast, so full of stuff that it left me kind of
| dazed to be fair!
|
| I got some papers in regards to knowledge representation (that
| to be fair i still have to read... exams and work got in the
| midst of all :/) but still it seems so... odd: when we were
| studying OOP in my bachelor we went over the usual examples
| that made you understand "this is not an imperative paradigm
| but there are object abstractions" while, in my studies, prolog
| and logic programming in general was seen as a tool of sorts
| for reaching an objective like "hey we have a MAS system, let's
| sprinkle some prolog in it for fun :D" (maybe i am exaggerating
| but it feels like this lol). I feel it can do much much more
| felixyz wrote:
| You are definitely on to something here. OOP has some common
| roots with formal ontologies and knowledge representation
| (not so much the programming languages, but object oriented
| modeling). OO fails at this for various reasons, whereas
| logic is tailored for this specific purpose. Check out ErgoAI
| (formerly Flora-2), it's the most advanced Prolog flavor for
| representing and reasoning over knowledge.
| https://github.com/ErgoAI
| overclock351 wrote:
| you guys are giving me so much to read thanks <3 i'll give
| this a check when i have some time out of exams/work. I
| will surely check ErgoAI
| mst wrote:
| If you want to see something truly fascinating, take apart
| https://logtalk.org/ - it implements an OO system for prolog
| which gives you all sorts of advantages (the least of which
| being a not-terrible way of getting namespaces).
|
| Reading "The Art of Prolog" and "The Craft of Prolog" was fun
| for me, as was learning how the Warren Abstract Machine
| works.
|
| (I am not at all a prolog expert, merely a programmer who
| happens to be fascinated by it, so this is all dabbling on my
| end but hopefully provides some stuff that's fun to learn for
| you as well)
| DonHopkins wrote:
| Hi! Are you Jim Hendler (or related to him), my Reagan-era AI
| professor from UMD?
|
| https://en.wikipedia.org/wiki/James_Hendler
|
| My Prolog programming assignment #4, a Prolog "nehcihsahA"
| detector (maternal uncle: a mother's brother, or any equivalent
| relative) seemed designed to make me hate Prolog with a
| passion, involving bending over backwards by defining
| ridiculous predicates like siblish, sibloid, relatoid, sistoid,
| brothoid, mothoid, and fathoid.
|
| https://www.donhopkins.com/home/code/nehcihsaha.prolog.txt
|
| I much more enjoyed the OPS-5 programming assignment #6, for
| which I made a worm simulation that hacked into Ollie North's
| Intimus-007s ("the ace of security paper shredders") in the
| White House basement, via Professor Hendler's Sun workstation
| dormouse, rms's account with password rms on prep, and Casper
| Weinberger's account on UMD's Vax 11/780 mimsy and NSA's
| PDP-11/70 tycho, connected via the NSA's MILNET IMP 57 at Fort
| Mead, then posted Ollie North's secret diary and notes it found
| in the paper shredder to talk.rumors via the UCB-Vax usenet
| gateway.
|
| https://www.donhopkins.com/home/code/crack-ollie.ops5.txt
|
| https://news.ycombinator.com/item?id=18376750
|
| >At the University of Maryland, our network access was through
| the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty
| obvious that UMD got their network access via NSA, because
| mimsy.umd.edu had a similar "*.57" IP address as dockmaster,
| tycho and coins. [...]
| derdi wrote:
| > My Prolog programming assignment #4, a Prolog "nehcihsahA"
| detector (maternal uncle: a mother's brother, or any
| equivalent relative) seemed designed to make me hate Prolog
| with a passion, involving bending over backwards by defining
| ridiculous predicates
|
| Your attempt at a solution definitely defines ridiculous
| predicates, but you should not blame that on your teacher or
| the language. For example, there is no way that defining "a
| mother's brother" would need to refer to a "same sex"
| predicate in any way. You took a wrong turn somewhere with
| your approach, but again it's neither the language nor your
| teacher that forced you down that path.
| xavxav wrote:
| There is still academic work on Prolog, and more broadly
| deductive / logic programming. If you are looking at things with
| a more industrial bent, I would look to Datalog which trades
| generality in Prolog for performance and predictability.
| Alternatively, you can go the other way and look at lambdaProlog
| which adds real abstractions / HOFs to Prolog.
|
| What I've seen in practice is that while Prolog may be good at
| _describing_ a solution, its performance is often too lackluster
| and brittle for actual deployment: it probably fits more as a
| prototyping language before you do a classic implementation of
| the solution in a more traditional language.
| a-french-anon wrote:
| No idea, but it might be worth looking into Mercury and
| {mini,micro}Kanren/core.logic as more practical iterations on it
| (either by adding things to Prolog or extracting the interesting
| to stuff to use in more general purpose languages).
| Avshalom wrote:
| At the end of the day "practical" means library support and
| community knowledge, by which measure Prolog and more
| specifically SWI and Sicstus are far more practical than any of
| the other logic languages or implementation options
| harperlee wrote:
| Well if your problem does not require a solution that's 100%
| written in prolog, then any relational/CLP system that can be
| hosted or work as a library is going to win in terms of
| library support and community knowledge, at solution level.
|
| So e.g. a core.logic solution can make extensive use of the
| jvm ecosystem.
| sprayk wrote:
| The most recent prolog news I've come across in recent years is
| some updates to SWIprolog (can't find a good link) and some talk
| of Scryer-prolog[0] which is a more recent implementation of
| Prolog in Rust.
|
| One interesting development recently is a load of research into,
| reverse engineering of and emulation of the 1986 Sega AI
| Computer[1], which used prolog under the hood for mostly
| educational software. Unfortunately it does not seem there is a
| way to actually write some prolog for the thing today :(
|
| [0] https://github.com/mthom/scryer-prolog
|
| [1] https://www.smspower.org/SegaAI/Index
| mtsfz2 wrote:
| There are certain (academic) problems for which Prolog is simply
| the best tool for the job, see e.g.,
| https://github.com/hbrouwer/dfs-tools
| moffkalast wrote:
| > (academic)
|
| Ah, for a second I thought someone just found a way to make
| Prolog useful for something. What a terrifying thought indeed,
| luckily the crisis has been averted, the natural order is
| restored and all is well.
| upghost wrote:
| Prolog has reached an exciting new milestone with Scryer prolog.
| It is the first highly performant open source iso-compliant
| Prolog.
|
| I would check out Markus Triska's work to have your mind blown:
|
| https://www.metalevel.at/prolog
|
| https://youtube.com/@thepowerofprolog
| overclock351 wrote:
| Do you have any papers comparing Scryer with other prolog
| systems (like SWI-prolog or SICStus prolog) performance-wise ?
| jodrellblank wrote:
| There are some benchmarks here of SWI Prolog's benchmark
| suite on diffrent Prolog systems by Jan Wielemaker the SWI
| Prolog author:
|
| https://swi-prolog.discourse.group/t/porting-the-swi-
| prolog-...
|
| He finds Scryer performs worse, which he does comment on, he
| also explains some tradeoffs and historic choices in SWI's
| design which affects its performance. I think I have seen the
| author of Scryer saying that's not surprising and Scryer is
| still building up core functionality where SWI has had 30+
| years to optimise, but I don't remember where I read that.
|
| SWI has a document explaining some strengths and weaknesses
| regarding performance: https://www.swi-
| prolog.org/pldoc/man?section=swiorother
|
| Edit: some discussion on Scryer previously on HN:
| https://news.ycombinator.com/item?id=28966133
| jfmc wrote:
| Another table (in the same thread) comparing more systems:
| https://swi-prolog.discourse.group/t/porting-the-swi-
| prolog-...
| b800h wrote:
| So SWI appears to be more performant, it has an open
| license, so as per the GGP's claim regarding Scryer in the
| post above, it must not be ISO-compliant?
| derdi wrote:
| Or maybe the GGP was wrong about performance?
|
| Some default settings in SWI are not ISO-compliant (for
| example, it uses a string type that does not exist in
| ISO). But these are minor things that won't usually trip
| you up when feeding it ISO code. You can set flags to get
| it to conform in the way you want. And you _should_ set
| flags whenever you want your ISO Prolog programs to be
| portable, because the standard is very lax and leaves a
| lot of things implementation-defined. But it specifies
| the flags to get implementations into the state you want.
| jodrellblank wrote:
| That's right; comedian Emo Phillips had a bit about it:
|
| "Once I saw this guy on a bridge about to jump. I said,
| "Don't do it!" He said, "Nobody understand me." I said,
| "What's so special about you?"
|
| He said, "I'm a computer guy." I said, "Me too! Desktop,
| tablet, console, smartphone?" He said "Desktop, mostly",
| I said "Me, too! Mac, Linux or Windows?" He said, "Any,
| I'm a programmer." I said, "Me, too! which style? OOP,
| Imperative, Functional, Logic, Array, Stack" He said,
| "Logic." I said, "Me, too! What subset? Answer Set
| Programming, Abductive Programming, Prolog, Datalog?" He
| said, "Prolog." I said, "Me, too! Conformant with the
| ISO/IEC 13211-1:1995 (core) standard term syntax for the
| period character or non-conformant extention decried by
| members of the ISO/IEC JTC1 SC22 WG17 working group?"
|
| He said, "SWI Prolog 7" I said, "Die, heretic!" And I
| pushed him over."
|
| - https://news.ycombinator.com/item?id=26624442
|
| or read more seriously here:
|
| - https://www.complang.tuwien.ac.at/ulrich/iso-
| prolog/SWI7_and...
| rlupi wrote:
| I can't help.
|
| > "Once I saw this guy on a bridge about to jump. I said,
| "Don't do it!" He said, "Nobody understand me." I said,
| "What's so special about you?"
|
| He said: "I don't want to jump".
| drekipus wrote:
| I don't get it
|
| * _Jumps off a bridge_
| triska wrote:
| A key performance attraction of Scryer Prolog is its
| _space_ efficiency for representing lists of characters,
| yielding a 24 _times_ (!) more compact representation
| than a naive implementation would.
|
| With Scryer Prolog and other recent systems that
| implement this representation, such as Trealla Prolog, we
| can easily process many GBs of text with DCGs, arguably
| realizing the full potential of the originally intended
| use case of Prolog for the first time. Trealla Prolog
| goes even further already, and allows overhead-free
| processing of files, using the system-call mmap(2) to
| virtually map files to memory, delegating the mapping to
| the operating system instead of the Prolog system.
|
| The linked benchmarks do not test these aspects at all,
| and in addition use a version of Scryer Prolog that was
| completely outdated already at the time the benchmarks
| were made: The benchmarks use Scryer Prolog v0.8.127,
| which was tagged in August 2020, more than 3 _years_ (!)
| before the benchmarks were posted. The linked benchmarks
| thus ignore more than 3 years of development of a system
| that was at that time 7 years old. Newer versions of
| Scryer Prolog perform much better due to many
| improvements that have since been applied. More than 1700
| commits were applied between these dates.
|
| In the face of the 24- _fold_ reduction of memory use
| that the above-mentioned efficient string representation
| enables, small factors of difference in speed between
| different systems are in my opinion barely worth
| mentioning at all in any direction.
|
| And yes, in addition to this great space efficiency, the
| strong ISO conformance of Scryer Prolog is also a major
| attraction especially when using it in highly regulated
| areas. For example, here is a recently envisaged
| application of Scryer Prolog in the context of machine
| protection systems (MPS) of giant particle accelerators,
| where adherence to industry standards is of great
| importance for warranty reasons among others:
|
| https://github.com/mthom/scryer-prolog/discussions/2441
|
| As another example, a medical application of Scryer
| Prolog, in the highly regulated domain of oncology trial
| design:
|
| https://github.com/mthom/scryer-prolog/discussions/2332
|
| Here is an overview of syntactic ISO conformance of
| different Prolog systems:
|
| https://www.complang.tuwien.ac.at/ulrich/iso-
| prolog/conformi...
| derdi wrote:
| > adherence to industry standards is of great importance
| for warranty reasons among others
|
| This is mostly a nice talking point rather than an actual
| thing, right? Scryer's license contains the usual all-
| caps NO WARRANTY and NO FITNESS FOR A PARTICULAR PURPOSE
| wording. Also, the links you provided describe these
| applications without references to warranties and
| standards and regulation. The users in these super-
| sensitive domains don't seem as sensitive about them as
| you claim.
| triska wrote:
| > the links you provided describe these applications
| without references to warranties and standards and
| regulation.
|
| This is not true. For example, quoting from page 2 of the
| paper that is linked to in a discussion I posted, _An
| Executable Specification of Oncology Dose-Escalation
| Protocols with Prolog_ , available from
| https://arxiv.org/abs/2402.08334:
|
| _" Standards are of great importance in the medical
| sector and play a significant role in procurement
| decisions, resolution of legal disputes, warranty
| questions, and the preparation of teaching material. It
| is to be expected that the use of an ISO-standardized
| programming language will enable the broadest possible
| adoption of our approach in such a safety-critical
| application area. For these reasons, we are using Scryer
| Prolog for our application. Scryer Prolog is a modern
| Prolog system written in Rust that aims for strict
| conformance to the Prolog ISO standard and satisfies all
| syntactic conformity tests given in
| https://www.complang.tuwien.ac.at/ulrich/iso-
| prolog/conformi...."_
|
| Regarding warranty guarantees of Scryer Prolog, may I
| suggest you contact its author if you need to negotiate
| arrangements that are not catered for by the only licence
| terms you currently have access to?
|
| One important advantage you get from the strict syntactic
| conformance of Scryer Prolog is that it reliably tells
| you what is Prolog syntax and what is not. In this way,
| you can use it as a free reference system to learn what
| Prolog is. The conformance makes it easier to switch to
| other conforming systems, such as SICStus Prolog which
| also offers different licences and commercial support,
| when you need to.
|
| > The users in these super-sensitive domains don't seem
| as sensitive about them as you claim.
|
| I am at a loss at this phrasing and also about the
| content of this text. Apart from the facts that I did not
| use the wording "super-sensitive", and that the
| importance of standards is explicitly stated in the paper
| I quoted above, is there even the slightest doubt about
| the great importance of standards when building and
| operating giant particle accelerators or devising dose
| escalation trials in clinical oncology?
| derdi wrote:
| I acknowledge that you also included your nice talking
| point in a paper you published on arXiv. Citing yourself
| doesn't convince me any more of the credibility of this
| argument.
|
| > is there even the slightest doubt about the importance
| of standards when building and operating giant particle
| accelerators
|
| The particle accelerator application is a checker for
| existing JSON config files. The accelerator is already
| running with those files. The proposed project is in an
| early stage. The checker will add more assurance, which
| is nice. The checker's author does not talk about the
| importance of warranties or standards. The checker could
| just as well be implemented in some non-ISO dialect as
| long as that dialect has a reliable specification and
| implementation.
|
| So yes, there is the slightest doubt.
|
| Edit: BTW, your oncology paper heavily uses CLP(Z), which
| does not have an ISO standard, so your argument is... The
| base language must be standardized, but arbitrary
| nonstandard extensions are OK? Please clarify as I've
| probably misunderstood.
| triska wrote:
| > CLP(Z), which does not have an ISO standard
|
| CLP(FD/Z) is a candidate for inclusion in the Prolog
| standard: Several Prolog systems provide it with notable
| commonalities in features, it fits perfectly into the
| existing language, and it follows the logic of the
| standard including its error system. It can even be
| implemented within Prolog, provided a few basic features
| are present in a Prolog system. For instance, the CLP(Z)
| system I provide and which is used in the paper runs with
| little modifications already in several different Prolog
| systems, including SICStus, Scryer and Trealla. CLP(FD/Z)
| is an admissible _extension_ of the existing standard:
| 5.5 Extensions A processor may support, as
| an implementation specific feature, any construct
| that is implicitly or explicitly undefined in the
| part of ISO/IEC 13211.
|
| This is completely different from _modifications_ of the
| standard that do not fit at all into the standard. For
| instance, interpreting double-quoted strings differently
| from what the standard prescribes is _not_ an extension
| in the sense the standard defines it, but a
| _modification_ of the standard.
|
| In addition, Scryer Prolog has an execution mode where
| all its extensions are turned off. This is called a
| _strictly conforming mode_ , and is also prescribed by
| the standard: 5 Compliance
| 5.1 Prolog processor A conforming Prolog
| processor shall: ... e)
| Offer a strictly conforming mode which shall reject
| the use of an implementation specific feature in Prolog
| text or while executing a goal.
|
| In Scryer Prolog, the strictly conforming mode is the
| default execution mode.
|
| Regarding the other points you mention: Even though it
| may sound easy to say "as long as that dialect has a
| reliable specification and implementation", I know no
| such system that exists, and what I see from systems that
| do not adhere to the Prolog standard makes me doubt that
| such a thing is possible. The systems that do not follow
| the standard often have elementary syntactic problems,
| such as reading a Prolog term that they themselves emit
| into a _different_ Prolog term, a recipe for disaster and
| unacceptable in every domain I know.
| derdi wrote:
| > For instance, interpreting double-quoted strings
| differently from what the standard prescribes is not an
| extension in the sense the standard defines it, but a
| modification of the standard.
|
| Agreed, but also minor as you can and should set the
| double_quotes flag, otherwise your program doesn't have
| portable semantics even among ISO Prolog systems.
|
| > Even though it may sound easy to say "as long as that
| dialect has a reliable specification and implementation",
| I know no such system that exists, and what I see from
| systems that do not adhere to the Prolog standard makes
| me doubt that such a thing is possible.
|
| Of course it is possible to program against the quirks of
| a given implementation. That's what you yourself are
| doing with your CLP libraries. As you note, your main
| target has different quirks from other targets.
|
| More broadly, Scryer itself demonstrates that it's
| possible to program against a programming language that
| doesn't have an ISO standard but does have a good enough
| specification and an implementation that adheres to that
| specification.
|
| > The systems that do not follow the standard often have
| elementary syntactic problems, such as reading a Prolog
| term that they themselves emit into a different Prolog
| term, a recipe for disaster and unacceptable in every
| domain I know.
|
| You're painting with a very broad brush here. What
| implementations, and what kinds of terms? If your
| examples involve infix dot, that would be the kind of
| term nobody uses and nobody should use in modern Prolog,
| as you well know. Some of these syntactic problems only
| appear if you go looking for them. Minor syntactic
| annoyances will be caught in testing.
|
| I agree that such things are bad, but they are knowable,
| controllable, and quite probably much less relevant in
| practice than you suggest.
|
| Very very tangentially: The company I work for is very
| serious about its software supply chains. If we want to
| use external software for development, we must apply for
| permission. For that permission, actual programmers and
| lawyers trawl through the code and licenses and
| documentation. Scryer's license file lists one copyright
| holder, and there are many source files without copyright
| headers, and then there are many source files with
| copyright headers that name another copyright holder. Our
| lawyers would not allow us to touch such a system. If
| you're serious about promoting Scryer as a serious Prolog
| for serious use, you might want to consider cleaning this
| up.
| mark_l_watson wrote:
| I interviewed and helped hire Mark Thom, the original author of
| Scryer. I also follow Scryer with interest, even though most of
| my limited Prolog use has been with SWI Prolog (and one large
| project with ExperProlog in the 1980s).
|
| One thing to check out: Prolog plays fairly well with Python,
| providing opportunities for hybrid projects.
| klibertp wrote:
| To playing well with Python, this was on a front page some
| time ago: https://arxiv.org/abs/2308.15893
|
| "The Janus System: Multi-paradigm Programming in Prolog and
| Python"
| mark_l_watson wrote:
| Hey, thanks! That looks cool.
| philzook wrote:
| I am quite pleased with the ability to easily use prolog
| from within python and vice versa. It makes it now one of
| the easiest and most expressive solvers to plug into for my
| tastes. I'm starting to accumulate useful solvers here http
| s://github.com/philzook58/prologsolvers/tree/164297d87f6...
|
| You need to install swi prolog https://www.swi-
| prolog.org/download/stable and pip install janus_swi
|
| A simple example to get started: https://www.swi-
| prolog.org/pldoc/doc_for?object=section(%27p...
| import janus_swi as janus janus.consult("path", """
| edge(a,b). edge(b,c). edge(c,d).
| :- table path/2. path(X,Y) :- edge(X,Y).
| path(X,Y) :- edge(X,Z), path(Z,Y). """)
| list(janus.query("path(a,Y)."))
| nextos wrote:
| On the topic of multi-paradigm programming, including logic
| programming, Oz/Mozart is an obligatory mention. See CTM
| and
| http://mozart2.org/mozart-v1/doc-1.4.0/tutorial/index.html.
|
| The authors were fairly prominent Prolog researchers. It's
| sad Van Roy is retiring and nobody is taking this forward.
| AliceML, a StandardML dialect inspired by Oz is also
| abandonware.
| nerdponx wrote:
| How do you normally use Prolog and Python together? I had
| looked into embedding logic programming within Python in the
| past, and found a lack of satisfying options, but maybe I
| didn't know where to look.
| mark_l_watson wrote:
| I have two short examples in one of my books that I am
| currently re-writing. Here is a link directly to the
| Python+ Prolog interop examples
| https://leanpub.com/pythonai/read#use-predicate-logic-by-
| cal...
| networked wrote:
| Thanks for the link. I have played with PySwip
| (https://github.com/yuce/pyswip), and the MQI looks like
| a more maintainable approach to integrating SWI-Prolog
| with Python (https://github.com/SWI-Prolog/packages-mqi).
|
| The biggest source of friction I noticed when playing
| with PySwip was that because Prolog code was represented
| as strings, you avoided generating it on the fly. It
| would be nice to have an embedded DSL for Prolog in
| Python. (I am thinking something like SymPy or the Pony
| ORM--https://github.com/ponyorm/pony.)
| nickswalker wrote:
| I noticed the same friction while trying to integrate
| Answer Set Programming solvers into Python projects. The
| people who built the dominant ASP solver actually provide
| nice solutions though. Possible inspiration for Prolog
| tooling:
|
| Clorm (Clingo ORM) [1] makes it easy to create facts
| after you define simple predicate Python classes. Here's
| an example project of mine which uses it to set up a
| scheduling problem (Python -> ASP) and to present the
| results (ASP -> Python).
|
| https://github.com/raceconditionrunning/relay-scheduler
|
| Clingo (the solver) exposes its internal AST
| implementation through Python bindings[2], so you can
| build up rules or other statements from typed components
| instead of strings. This simplifies the translation bits
| of implementing an ORM or whatever kind of wrapper a
| developer would prefer.
|
| [1] https://github.com/potassco/clorm [2]
| https://potassco.org/clingo/python-
| api/current/clingo/ast.ht...
| networked wrote:
| This is cool! I am glad to see that other people have
| thought in the same direction--and actually wrote the
| code. I have another reason to learn ASP.
| NegativeLatency wrote:
| Don't go looking at pony's source code for inspiration.
| The api is neat but when your app starts to get
| complicated it begins to not work well.
| nerdponx wrote:
| Thank you!
| sirwhinesalot wrote:
| Not sure about Prolog itself but Datalog really needs to overtake
| SQL, it's just so much better.
|
| Related areas like constraint programming are still very
| relevant.
| pfilo8 wrote:
| Could you explain more or point out some interesting
| references? I'm currently trying to understand how Datalog
| compares to SQL and, potentially GraphDBs
| sirwhinesalot wrote:
| Don't have any interesting references, sorry. My reasoning is
| mainly one of simplicity and power. In SQL you need to think
| in terms of tables, inner joins, outer joins, foreign keys
| etc. whereas datalog you do everything with relations as in
| prolog.
|
| Not only is it conceptually much simpler, it's also a "pit of
| success" situation as thinking in terms of relations instead
| of tables leads you towards normal forms by default.
|
| Add the ability to automatically derive new facts based on
| rules and it just wins by a country mile. I recommend giving
| Souffle a try.
|
| I haven't worked with GraphDBs enough to comment on that.
| greenavocado wrote:
| Prolog and Datalog example (they are identical in this case)
| % Facts parent(john, mary). parent(mary,
| ann). parent(mary, tom). % Rules
| ancestor(X, Y) :- parent(X, Y). ancestor(X, Z) :-
| parent(X, Y), ancestor(Y, Z). % Query ?-
| ancestor(john, X).
|
| The Prolog code looks identical to Datalog but the execution
| model is different. Prolog uses depth-first search and
| backtracking, which can lead to infinite loops if the rules
| are not carefully ordered.
|
| Datalog starts by evaluating all possible combinations of
| facts and rules. It builds a bottom-up derivation of all
| possible facts:
|
| a. First, it derives all direct parent relationships.
|
| b. Then, it applies the ancestor rules iteratively until no
| new facts can be derived.
|
| For the query ancestor(john, X):
|
| It returns all X that satisfy the ancestor relationship with
| john. This includes mary, ann, and tom. The order of rules
| doesn't affect the result or termination. Datalog guarantees
| termination because it operates on a finite set of possible
| facts.
|
| Prolog uses a top-down, depth-first search strategy with
| backtracking.
|
| For the query ancestor(john, X):
|
| a. It first tries to satisfy parent(john, X). This succeeds
| with X = mary.
|
| b. It then backtracks and tries the second rule: It satisfies
| parent(john, Y) with Y = mary. Then recursively calls
| ancestor(mary, X).
|
| c. This process continues, exploring the tree depth-first.
|
| Prolog will find solutions in this order: mary, ann, tom.
|
| The order of clauses can affect both the order of results and
| termination: If the recursive rule were listed first, Prolog
| could enter an infinite loop. Prolog doesn't guarantee
| termination, especially with recursive rules.
|
| SQL is more verbose. The equivalent of the Datalog/Prolog
| example above is: -- Create and populate
| the table CREATE TABLE Parent ( parent
| VARCHAR(50), child VARCHAR(50) );
| INSERT INTO Parent VALUES ('john', 'mary'); INSERT
| INTO Parent VALUES ('mary', 'ann'); INSERT INTO
| Parent VALUES ('mary', 'tom'); -- Recursive
| query to find ancestors WITH RECURSIVE Ancestor AS (
| SELECT parent, child FROM Parent
| UNION ALL SELECT a.parent, p.child
| FROM Ancestor a JOIN Parent p ON a.child =
| p.parent ) SELECT DISTINCT parent AS ancestor
| FROM Ancestor WHERE child IN ('ann', 'tom');
|
| This is a more interesting example of how one might use
| Datalog on a large dataset: % Define the
| base relation friend(Person1, Person2).
| % Define friend-of-friend relation
| friend_of_friend(X, Z) :- friend(X, Y), friend(Y, Z), X != Z.
| % Define potential friend recommendation % (friend of
| friend who is not already a friend)
| recommend_friend(X, Z) :- friend_of_friend(X, Z), not
| friend(X, Z). % Count mutual friends for
| recommendations mutual_friend_count(X, Z, Count) :-
| recommend_friend(X, Z), Count = count{Y :
| friend(X, Y), friend(Y, Z)}. % Query to get top
| friend recommendations for a person
| top_recommendations(Person, RecommendedFriend, MutualCount)
| :- mutual_friend_count(Person, RecommendedFriend,
| MutualCount), MutualCount >= 5,
| MutualCount = max{C : mutual_friend_count(Person, _, C)}.
|
| The equivalent Postgres example would be:
| WITH RECURSIVE -- Base friend relation
| friends AS ( SELECT DISTINCT person1, person2
| FROM friendship UNION SELECT person2,
| person1 FROM friendship ),
| -- Friend of friend relation friend_of_friend AS (
| SELECT f1.person1 AS person, f2.person2 AS friend_of_friend
| FROM friends f1 JOIN friends f2 ON f1.person2 =
| f2.person1 WHERE f1.person1 <> f2.person2
| ), -- Potential friend recommendations
| potential_recommendations AS ( SELECT fof.person,
| fof.friend_of_friend, COUNT(*) AS
| mutual_friend_count FROM friend_of_friend fof
| LEFT JOIN friends f ON fof.person = f.person1 AND
| fof.friend_of_friend = f.person2 WHERE f.person1
| IS NULL -- Ensure they're not already friends
| GROUP BY fof.person, fof.friend_of_friend HAVING
| COUNT(*) >= 5 -- Minimum mutual friends threshold ),
| -- Rank recommendations ranked_recommendations AS (
| SELECT person, friend_of_friend, mutual_friend_count,
| RANK() OVER (PARTITION BY person ORDER BY mutual_friend_count
| DESC) as rank FROM potential_recommendations
| ) -- Get top recommendations SELECT
| person, friend_of_friend, mutual_friend_count FROM
| ranked_recommendations WHERE rank = 1;
|
| Full example you can run yourself:
| https://onecompiler.com/postgresql/42khbswat
| dkarl wrote:
| > Prolog uses depth-first search and backtracking, which
| can lead to infinite loops if the rules are not carefully
| ordered
|
| Is this an issue in practice? Most languages can create
| programs with infinite loops, but it's easy to spot in code
| reviews. It's been over a decade since I encountered an
| infinite loop in production in the backend. Just wondering
| if the same is true for Prolog.
| Normal_gaussian wrote:
| Yes.
|
| It is trivially easy to create loops of rules when
| describing abstract properties.
|
| Concrete properties tend to have "levels" to them, but
| many human concepts are self-referential.
|
| In this way, its possible to spot that there may be an
| issue now or in the future, because the presence or lack
| of a loop depends on the specific choice of dependencies
| of a concept. However spotting the potential for a loop
| doesn't do a lot to help remove its potential existence,
| or show that it is there or not there.
| derdi wrote:
| There are classes of infinite loops that are harder to
| spot for beginners, it takes a while to really understand
| the execution model.
|
| Prolog variables can have two states at runtime: unbound
| or bound. A bound variable refers to some value, while an
| unbound variable is a "hole" to be filled in at a later
| time. It's common to pass an unbound variable into some
| call and expect the callee to bind it to a value. This
| can cause problems with infinite recursion where you
| intend to write a call that binds some variable, but the
| way you've structured your program, it will not actually
| bind it. So the callee ends up in the same state as the
| caller, makes a recursive call hoping its callee will
| bind the variable, and down the infinite recursion you
| go. With experience you can definitely spot this in code
| review. You'll also catch it in testing, if you test
| properly. But it's different enough from other languages
| that learners struggle with it at first.
|
| Another source of (seeming) nontermination is when you
| ask Prolog's backtracking search to find an answer to
| some query in a search space that is too large and may
| not contain an answer at all, or only an answer that is
| impracticably far away. This is also sort of Prolog-
| specific since in other languages you rarely write the
| same kind of optimistic recursive search. This is harder
| to spot in code review since it's really application-
| specific what the search space looks like. But again, you
| test. And when in doubt, you direct and limit the search
| appropriately.
| yaantc wrote:
| Take the infinite loop as just an example of an issue
| with depth-first search and backtracking. To be more
| general, I'd say that the issue is that the overall
| performance of a Prolog program can be very dependent on
| the ordering of its rules.
|
| As an anecdote, a long time ago for a toy project
| switching two rules order got the runtime to finding all
| solutions from ~15mn to a around the second (long time,
| memory fuzzy...). The difference was going into a "wrong"
| path and wasting a lot of time evaluating failing
| possibilities, vs. taking the right path and getting to
| the solutions very quickly.
|
| So in practice even if Prolog is declarative to get good
| results you need to understand how the search is done,
| and organize the rules so that this search is done in the
| most efficient way. The runtime search is a leaky
| abstraction in a way ;)
|
| It's not an issue limited to Prolog, many solvers can be
| helped by steering the search in the "right" way. A
| declarative language for constraint problem like MiniZinc
| provides way to pass to the solver some indication on how
| to best search for example.
|
| Also, most modern Prolog support tabling, which departs
| from strict DFS+backtracking and can help in some cases.
| But here too, to get the best results may require
| understanding how the engine will search, including
| tabling.
| jodrellblank wrote:
| Here's an infinite loop in Prolog, getting the length of
| a list: length(List_of_animals, Len)
|
| Oops, List_of_animals hasn't been bound to any value, so
| length/2 will backtrack forever making it a longer and
| longer list of empty placeholders. Nothing will warn you
| that the variable wasn't declared because that's also a
| normal thing to do. Here's another, checking if something
| is in a list: member(cat,
| List_of_animals)
|
| same problem, if the list isn't grounded to a fixed
| length list by the time this line executes, backtracking
| will generate longer and longer lists with `cat` in them
| and lots of placeholders: [cat]
| [_, cat] [_, _, cat] ...
|
| forever. It's not just that you can accidentally write an
| infinite for(;;) loop by typoing the exit condition, it's
| that a lot of things in Prolog can be used in ways which
| finish deterministically _or_ in ways that act a bit like
| Python generators _yield_ ing endless answers. So it's
| about the context in which you call them, and the
| surrounding code. e.g. one reason you're using Prolog is
| that you want it to generate List_of_animals for you
| (making up fictional animal names, or something), so you
| can't look for a missing `List_of_animals = [...]`
| because there might not be one anywhere.
| derdi wrote:
| > Nothing will warn you that the variable wasn't declared
| because that's also a normal thing to do.
|
| Minor nitpick regarding an otherwise good answer: Prolog
| systems will warn you about "singleton variables", that
| is, variables with exactly one occurrence. This does
| catch the usual cases of this kind of error.
| ted_dunning wrote:
| Infinite loops in Prolog can appear with very subtle
| changes in the use of code.
|
| One of the core problems is related to the reversible
| nature of Prolog. Not only are some programs reversible
| and some are, practically speaking, not, there are many
| gradations on this.
|
| The result is that programs that look equivalent and
| whose tests appear equivalent may exhibit non-termination
| in surprising ways. This is, in my experience, the rule
| rather than the exception with Prolog.
| dmpk2k wrote:
| How does the Datalog approach compare with RETE?
| ted_dunning wrote:
| The big deal about Datalog is that it is equivalent to
| SQL-with-recursion. Thus, it can compile to database
| queries.
| felixyz wrote:
| TypeDb is a practical Datalog-based database system [1] (with
| a different syntax). TerminusDb is a project in a similar
| vein [2], but actually an RDF store at its core. If you want
| to experiment with the connections between Datalog,
| relational algebra, and SQL, check out the Datalog
| Educational System. And if you want to jump into the theory,
| Foundations of Databases (the "Alice book") is very thorough
| but relatively readable [4]! Oh, and there's a Google
| project, Logica, to do Datalog over Postgres databases [5].
|
| [1]: https://typedb.com/ [2]: https://terminusdb.com/ [3]:
| http://www.fdi.ucm.es/profesor/fernan/des/ [4]:
| http://webdam.inria.fr/Alice/ [5]:
| https://github.com/evgskv/logica
| burakemir wrote:
| Mangle is a language that includes "textbook datalog" as a
| subset https://github.com/google/mangle ; like any real-world
| datalog language, it extends datalog with various facilities
| to make it practical.
|
| It was discussed on HN
| https://news.ycombinator.com/item?id=33756800 and is
| implemented in go. There is the beginnings of a Rust
| implementation meanwhile.
|
| If you are looking for datalog in the textbooks, here are
| some references: https://github.com/google/mangle/blob/main/d
| ocs/bibliography...
|
| A graph DBs short intro to datalog: just like the edges of a
| graph could be represented as a simple table (src, target),
| you could consider a database tuple or a datalog or prolog
| fact foo(x1, ..., xN) as a "generalized edge." The nice thing
| about datalog is then that as one is able to express a
| connections in an elegant way as "foo(...X...), bar(...X...)"
| (a conjunction, X being a "node"), whereas in the SQL world
| one has to deal with a clumsy JOIN statement to express the
| same thing.
| worldsayshi wrote:
| Are there any production ready open source databases using it?
| sirwhinesalot wrote:
| Datomic uses Datalog with a weird clojure syntax instead of
| the usual prolog-like syntax.
| worldsayshi wrote:
| Not open source though?
| sirwhinesalot wrote:
| Hmm open source I'm not sure, there are many SQLite
| equivalents listed on wikipedia though, if that counts.
| KingMob wrote:
| No. It's only free as in beer. There's some weird mention
| about the Apache 2 license, but it only applies to the
| _binaries_ , for some odd reason.
| refset wrote:
| Compiling Datalog to SQL with Logica is possibly the easiest
| path if you need a production ready open source Datalog setup
| (i.e. choose your favourite managed Postgres provider):
| https://logica.dev/
| networked wrote:
| DataScript, Datahike, Datalevin, and XTDB 1.x are open-
| source. (XTDB 2.x is also open-source but has switched from
| Datalog to its own query language and SQL.) DataScript,
| Datalevin, and XTDB have been used in production; not sure
| about Datahike. All of these databases come from the Clojure
| community and target Clojure as the primary language. The
| XTDB team has published a comparison matrix at
| https://clojurelog.github.io/.
|
| Aside: I write a lot more Python than Clojure, and I wish
| someone ported Datalevin/Datahike/persistent DataScript to
| Python. I'd try it as an alternative to SQLite. I suspect
| with thoughtful API design, an embedded Datalog could feel
| organic in Python. It might be easier to prototype with than
| SQLite. There are Datalog and miniKanren implementations for
| Python, but they are not designed as an on-disk database.
| PyCozo might be the closest thing that exists. (A sibling
| comment https://news.ycombinator.com/item?id=40995652 already
| mentions Cozo.)
| cmrdporcupine wrote:
| Not sure if "production ready" but it's worth looking at
| Cozo:
|
| https://github.com/cozodb/cozo
|
| Has a dialect of Datalog + some vector support. Multiple
| storage engines for backend including SQLite, so if your
| concern is data stability that seems like a reasonable,
| proven option.
| DonHopkins wrote:
| false.
|
| https://www.j-paine.org/dobbs/prolog_lightbulb.html
| aldousd666 wrote:
| I've actually been thinking about this quite a bit. I remember a
| foray into prolog when I was a younger pup in 2004-6. With the
| Advent of llms, I think that perhaps we could use llms to extract
| triples from large corpuses of text and then use that to build
| our prolog stores or ontologies and work on them. I haven't
| really experimented much with it but you saying this has reminded
| me that I should dig that back up again.
| felixyz wrote:
| Shameless plug: you should check out my podcast The Search Space
| for a view of the broader landscape of Prolog and logic
| programming: https://thesearch.space/
|
| I don't publish episodes often but I have a lot of good
| interviewees lined up :)
|
| In general, I would advice you to look beyond Prolog and explore
| Answer Set Programming, the Picat language, and the connections
| between logic programming and databases (SQL, RDF or otherwise).
| Not instead of Prolog, but in parallel. Prolog is awesome!
| overclock351 wrote:
| ASP is in another uni course of mine ;). I'll check the
| podcast, thanks
| forks wrote:
| I'll second the plug: it's an excellent podcast
| harperlee wrote:
| Good to know there is further content lined up! I'm subscribed
| and eagerly waiting for it!
| agumonkey wrote:
| thanks for the thread for allowing to find you and you for
| making the interviews
| duranga1234 wrote:
| I love your podcast! I wish you published episodes more often!
|
| I particularly enjoyed the first episode, the conversation with
| Robert Kowalski.
| shrimp_emoji wrote:
| My professor swapped Prolog out for Rust at the last minute. I
| don't know whether he did us a disservice or a favor.
| overclock351 wrote:
| That is my point, i think that prolog isn't just a simple tool
| to solve stuff, i think that it's potential can still be
| explored (even if, to be fair, Rust can run on a functional
| paradigm setting)
| jeroenvlek wrote:
| What a curious swap. May I ask which course he taught?
| shrimp_emoji wrote:
| It was a whirlwind "survey of languages" course. After
| blowing our minds with functional programming via OCaml, the
| last segment was traditionally logical programming via
| Prolog. But he decided to spare us, I guess, and made me fall
| in love with Rust for a few years. :p (Or he sadistically
| meant to inflict the trauma of knowing how much better C and
| C++ could be but never will be, which stays with you even
| after you stop using Rust and return to those.)
| tashmahalic wrote:
| I'd love to hear more about your trauma :-). What are the
| main ways C and C++ could be better?
| shrimp_emoji wrote:
| The easiest answer: they should have a build and test and
| packaging system like Cargo built-in. The best you have
| is a tedious anarchy of third-party systems, of which
| CMake seems to have come out the winner. I use CMake, but
| it's no Cargo (as an understatement).
|
| Borrowing and ownership is great for building safe code,
| whether it's single- or multi-threaded. In C, you have a
| nest of pointers, and a pointer communicates nothing
| about the ownership of its memory. Stuff can go, and
| leak, and dangle, everywhere. C++ mitigated this a little
| with references. Then it bolted on smart pointers,
| mitigating it further. Without learning Rust, though, I
| don't think I'd be as good of a C/C++ programmer because,
| unlike Rust, those languages don't _force_ you to think
| about where memory lives and where it 's going.
|
| The module system is also way better.
|
| Then I could take cheap shots: `u8` is way better than
| `uint8_t`. Rust had slices from the beginning, to be able
| to refer to parts of strings in a cheap way with easy
| syntax, whereas only C++17 introduced the comparatively
| awkward `std::string_view`.
|
| There are ways I think Rust is worse though! The easiest
| is that it still doesn't have a standard and will
| probably not see the uniquely deep and broad support of
| C/C++ in my lifetime. :p
| pjmlp wrote:
| I would say in the open source world, SWI Prolog is still the
| king implementation, in regards to tooling, language features
| beyond ISO Prolog, and toolchains.
|
| https://www.swi-prolog.org/
| overclock351 wrote:
| i've been aware of that for a while, it seems to be the state
| of the art at least in my university (to the point that to this
| day the researchers are trying to convert old prolog projects
| to this implementation)
| colanderman wrote:
| The CLP (constraint logic programming) systems available in some
| Prologs take it to the next level: https://us.swi-
| prolog.org/pldoc/man?section=clp
| tannhaeuser wrote:
| With compliments to your prof ;), interest in Prolog just now is
| recovering from a year-long focus on W3C's RDF/SPARQL. TBL surely
| had an itch to scratch with regards to logical knowledge
| representation dating back even longer than the web [1]. But
| Prolog has broader applicability not only in logical/knowledge
| graph querying, but also in solving all kinds of discrete
| combinatorical optimization problems. Or, as the Quantum Prolog
| site [2] puts it, "planning, optimization, diagnostics, and
| complex configuration." The site demos logistics optimization
| (in-browser demo) and reports initial optimization
| (parallelization) of Inductive Logic Programming and other ML
| tasks for partially auto-generating Prolog code from existing
| solutions.
|
| Edit: ... and on performance vs SWI Prolog, too
|
| [1]: https://en.wikipedia.org/wiki/ENQUIRE
|
| [2]: https://quantumprolog.sgml.io
| PaulHoule wrote:
| The problem w/ OWL is that everybody wants to work with first-
| order logic + math, but Godel proved it isn't decidable.
|
| For instance if I wanted to express financial regulations or
| business rules inside a bank or other business I'd need to use
| math: for instance to express the conditions for reserve
| requirements or approving a loan.
|
| OWL is best thought of as a set of templates for generating
| first-order logic rules that are decidable and also (in theory)
| quick to evaluate with the Tableau algorithm.
|
| In certain domains you might tolerate tools that are imperfect,
| like it isn't fair to expect a SMT solver to figure out this
| one x^N + y^N = z^N
|
| where x,y,z and N are all positive integers with N>2. For that
| one it would try to find solutions and probably time out. For
| some similar problems (a different polynomial) it might give
| you an answer.
|
| OWL doesn't want to go there which is a big reason people say
| "Nein Danke!"
| kstrauser wrote:
| > Godel proved it isn't decidable.
|
| He did no such thing. He proved undecidable problems exist in
| any system powerful enough to be useful. That doesn't make
| those systems useless, though.
| PaulHoule wrote:
| The trouble is the creators of OWL wanted to have
| performance and reliability bounds. That is, they want to
| make systems that act like more like a conventional
| database server than an SMT solver.
|
| I think they could have made a more expressive standard and
| something like that might have had more appeal to people
| but been less consistent in terms of performance.
| sproutini wrote:
| The problem with Prolog is that it's based on unification, and
| small unification engines can be expressed in a few lines in any
| functional programming language.
|
| That narrows down the already small niche where one would choose
| Prolog by probably a few orders.
| tpoacher wrote:
| Is this in the same sense that "one could write lisp in 99
| lines of c"?
|
| In my opinion, this does not imply that proper lisp (and
| correspondingly prolog) implementations are useless, just
| because a simple implementation can be written in a different,
| "more expressive" language.
| sproutini wrote:
| No, not really. A lisp in 99 lines of C would barely be
| useful. In contrast, Prolog mostly shines where you need
| reasoning/unification over a database of facts -happens
| pretty often,- but that's just too easily expressed in any
| proper functional language. And with a bit more pain in an
| imperative/OO language.
| jhbadger wrote:
| There is a very practical embedable logic-programming engine
| called miniKanren for many programming languages that can be
| used to add the logic-programming techniques of Prolog to
| other languages.
|
| https://en.wikipedia.org/wiki/MiniKanren
|
| There's a great book in the same series as the "Little
| Lisper"/"Little Schemer" books called "The Reasoned Schemer"
| that uses MiniKanren with Scheme.
| z5h wrote:
| I've been using Prolog daily for the past 1.5 years. I've also
| implemented and used a Kanren in Elm, and there is simply a
| world of practical difference.
| btbuildem wrote:
| For some, how a language is implemented seems to be the
| paramount thing.
|
| For many, how the language faces the user, how its paradigms
| fit the problems at hand and the user's mode of seeing the
| world, that is more important.
|
| These days, with the terabytes the petaflops and the
| megajoules, it might be even less relevant how the gears are
| turning inside the black box.
| kazinator wrote:
| > _expressed in a few lines in any functional programming
| language_
|
| I don't think that performs like a proper Prolog engine on
| larger problem.
|
| Real Prologs work by compiling to something called the WAM
| (Warren Abstract Machine).
| YeGoblynQueenne wrote:
| What makes Prolog, Prolog is not unification on its own but
| SLD-Resolution with unification, where "SLD" stands for
| [L]inear Resolution with a [S]election rule restricted to
| [D]efinite clauses. If you know your Resolution typology, that
| means soundness and refutation-completeness (or completeness
| with subsumption) [1].
|
| I don't think I've ever seen a discussion of Resolution in
| functional programming textbook implementations of "Prolog".
| They typically just bodge some depth-first search with
| backtracking and unification in polish notation and call it
| "Prolog", or "logic programming". A bit like if I wrote a
| "lisp" with eval(X):- call(X), then completely ignored all that
| jazz about lambda calculus and concentrated on garbage
| collection and linked lists.
|
| A good starting point instead, if one wishes to understand
| Prolog and not just dismiss it out of hand, is to try and
| understand Resolution, and what unification does for
| Resolution, and why it ended up in Prolog (and how) in the
| first place. I'd start, well, at the beginning:
|
| _A Machine-Oriented Logic Based on the Resolution Principle_
|
| https://www.semanticscholar.org/paper/A-Machine-Oriented-Log...
|
| Where you can follow the progress from ground Resolution, to
| unification, the Resolution theorem, and all the way to the
| (pre-modern) Subsumption Theorem. It's a long way to Prolog
| from there, but that's where it all begins.
|
| _______________
|
| [1] Although Prolog implemented by DFS is not complete if
| Prolog implemented by DFS is not complete (etc).
| segmondy wrote:
| It's a powerhouse, an even bigger secret than Lisp at beating the
| average.
| zelos wrote:
| Eclipse CLP still seems slightly active: https://eclipseclp.org/.
| I used it for some process scheduling research in the early 2000s
| but I've never had the chance to apply it in the non-academic
| world
| rramadass wrote:
| Though i only know Prolog cursorily it is in my todo list of
| languages to study. I think it has great value in that it teaches
| you a different _paradigm_ for programming.
|
| You might also want to look at Erlang which is used in the
| Industry and would be helpful for your future. Joe Armstrong was
| originally inspired by Prolog and he conceived Erlang as Prolog-
| Ideas+Functional/Procedural+Concurrency+Fault-Tolerance. Hence
| you might find a lot of commonalities here. Here is a recent HN
| thread on a comparison -
| https://news.ycombinator.com/item?id=40521585
|
| There is also "Erlog" (by Robert Virding, one of the co-creators
| of Erlang) which is described as, _Erlog is a Prolog interpreter
| implemented in Erlang and integrated with the Erlang runtime
| system. It is a subset of the Prolog standard. An Erlog shell
| (REPL) is also included._ It also says, _If you want to pass data
| between Erlang and Prolog it is pretty easy to do so. Data types
| map pretty cleanly between the two languages due to the fact that
| Erlang evolved from Prolog._ - https://github.com/rvirding/erlog
| btbuildem wrote:
| Ha! That explains a lot. I've started looking into Prolog
| recently, and there were some... familiar echoes in there,
| reminiscent of Erlang.
|
| But of course, the submarine is like a cigar, not cigar like a
| submarine.
| rramadass wrote:
| _The Development of Erlang_ by Joe Armstrong (pdf) -
| https://dl.acm.org/doi/pdf/10.1145/258948.258967
| tannhaeuser wrote:
| Sure, Erlang was prototyped on Prolog because Prolog has
| excellent built-in facilities for domain-specific languages:
| you can define new unary or binary operators along with
| priorities and associativity rules (you can use this to
| implement JSON or other expression parsing in like two lines of
| code, which is kindof shocking for newcomers, but comes very
| handy for integrating Prolog "microservices" into backend
| stacks), and you get recursive-decent parsing with backtracking
| for free as a trivial specialization of Prolog evaluation with
| a built-in short syntax (definite clause grammars) even.
|
| But apart from syntax, Erlang has quite different goals as a
| backend language for interruption-free telco equipment compared
| to Prolog.
| rramadass wrote:
| In _The Development of Erlang_ Joe Armstrong says "We
| concluded that we would like something like Prolog with added
| facilities for concurrency and improved error handling".
|
| See pdf linked here -
| https://news.ycombinator.com/item?id=40998632
| derdi wrote:
| You're reading too much into that quote. This is in a
| section titled "early experiments". It was an initial goal.
|
| There is a lot of historical connection to Prolog, due to
| the original implementation, and there are syntactic
| similarities and non-linear pattern matching and dynamic
| types and a general declarative vibe, but the actual end
| result of Erlang's evolution, despite the goal of
| "something like Prolog", is not very much like Prolog at
| all. Erlang is a functional language, not a logic language.
| Prolog is a logic language, not a functional language.
| General goals like in that quote can change over the
| decade-long development of a language.
| YeGoblynQueenne wrote:
| Yeah but to be honest, Erlang ended up being not something
| like Prolog at all.
|
| I think Joe Armstrong was a user here and I interacted with
| him waaaay way back when I first joined. He's dead now :(
| gorkempacaci wrote:
| Prolog, and Constraint Programming especially are great to have
| in your toolbox. I've done research in the field for years, and
| my job in the industry today is writing Prolog. There are real
| issues with Prolog:
|
| - no proper module nor package system in the modern sense.
|
| - in large code bases extra-logical constructs (like cuts) are
| unavoidable and turn Prolog code into an untenable mess. SWI
| prolog has single-sided unification guards which tackle this to a
| degree.
|
| - lack of static and strong types makes it harder to write robust
| code. At least some strong typing would have been nice. See
| Mercury as an example of this.
|
| All being said, Prolog is amazing, has a place in the future of
| programming, and gives you a level-up understanding of
| programming when you get how the types in every OO program is a
| Prolog program itself.
| ecshafer wrote:
| There are a lot of problems that Prolog / Constrain programming
| will solve very elegantly, and much more easily than imperative
| languages. I think constraint based programming is seriously
| under used in the industry, and too many programmers are
| unaware or unable to write constraint based code. I have always
| hoped to have just a constrain based programming subsystem in a
| lot of languages, for those niche cases.
| ToucanLoucan wrote:
| Maybe it's just me but I see a lack of a package manager as a
| massive, massive pro. I can't stand how seemingly every
| language has a package manager which requires it's own
| installation and you have to learn how to use THAT thing and
| then you need some library off github that does some minor task
| really well but you can't just download the fucking code, you
| have to import it via, idk, the Fork-Lyft manager which
| requires Python 3.3 and the PillJump framework and it's just
| like, I just want a fucking function to parse JSON, I don't
| want to saddle my system with 600 MB of shit I don't need.
|
| Old_man_yells_at_cloud.jpg
| phailhaus wrote:
| You can always just download the code, nobody's forcing you
| to use a package manager. It just turns out that unless you
| want to spend most of your life building and fixing other
| people's code, it's much easier to use the package manager.
| The inefficiency is the price we pay, but it's worth it.
| qu1j0t3 wrote:
| don't confuse "module system" with "package manager"
| duranga1234 wrote:
| Me too! I absolutely see a lack of package manager as a pro.
| I also hate to saddle anything with 600MB I don't need. 100%
| agree.
|
| I would go as far as to say that Prolog is more a problem
| solving language rather than a system building language.
| Package managers and module systems are for modularization of
| big systems. You don't need that when solving small recurrent
| problems. Furthermore, lack of them forces you to avoid
| dependencies, that most of the time would end as technical
| debt. IMHO.
| radomir_cernoch wrote:
| You write Prolog code for a living? Where? Do you happen to
| have a story to share? I'm very curious.
| BJones12 wrote:
| I suspect that his work is related to this:
| https://www.tacton.com/products/tacton-cpq/configurator/
| gorkempacaci wrote:
| Yes :)
| gorkempacaci wrote:
| Yes :) we make software that helps sell complex products (If
| your product has a million options and takes up a whole
| factory floor you can't just have a series of dropdowns)
| _glass wrote:
| Thanks for the insight, Gorkem! I was always thinking CPQs
| make a really good use case. We had so many problems with
| performance, not your product, CPQ is becoming a standard
| software for pricing contracts.
| kibwen wrote:
| _> when you get how the types in every OO program is a Prolog
| program itself_
|
| "Any sufficiently complicated type system contains an ad hoc,
| informally-specified, bug-ridden, slow implementation of half
| of Prolog."
| Arch-TK wrote:
| Any sufficiently complex type system is indistinguishable
| from an esolang.
| tannhaeuser wrote:
| I'd advise to not use Prolog as general-purpose programming
| language, but as an embedded DSL or as a service for the part
| it's really suited for (if your app involves exploration and
| search over a large combinatorical space in the first place,
| such as in discrete optimization in industry, logistics, and
| finance). You really don't need yet another package manager and
| pointless premature modularization for modelling your business
| domains in optimization.
| inkyoto wrote:
| I concur, Prolog particularly excels at being an advanced
| configuration, embeddable DSL that allows one to express
| system configurations that would otherwise be not easily
| possible using a bespoke configuration language or a format.
| I have used an embedded Prolog core to express complex
| installation configurations in the past with a great success,
| and I would do it again for the right problem space.
| hosh wrote:
| The cluster autoscaler in Kubernetes uses a constraint
| solver. It's translating configuration against dynamic, and
| changing state within the cluster.
|
| Using something like an embedded Prolog or miniKenran as
| the core of a Kubernetes operator is something I've wanted
| to try my hands on.
| jimbokun wrote:
| To me this makes Prolog sound like a tool to reach for
| similar to SQL. Specialized language for asking specific
| kinds of search or query over your data.
| gorkempacaci wrote:
| Indeed Prolog programs are also called databases sometimes.
| Some things Prolog can do over SQL:
|
| - infinite data defined by recursive predicates
|
| - flexible data structures (think JSON but better, called
| complex terms) and a way to query them (called unification
| algorithm)
|
| - execution strategy fine-tuned for reasoning (called
| resolution algorithm). You can do this with SQL but you'd
| have to formalize things using set operations and it'd be
| very very slow.
|
| On the other hand, SQL can query plain data very very fast.
| Karrot_Kream wrote:
| At this point, why not use one of the many other CP solver
| packages out there and the layers on top like OR-tools?
| throwaway3306a wrote:
| Which one is as developed, as universal and as capable as
| Prolog with CLP and/or DCG?
|
| Serious question, I'd like to have something that's easy to
| integrate with Node.js.
| Karrot_Kream wrote:
| OR-Tools has a lot of bindings in different languages,
| though Javascript/Node doesn't seem to be a first-class
| supported environment. Looks like
| https://www.npmjs.com/package/node_or_tools ports a few
| solver packages into Node so if those solvers fit your
| needs you can use this package.
| tannhaeuser wrote:
| The domain-specific Prolog code bases you're going to
| create still can become large and represent a significant
| development effort. Prolog being an ISO standard with many
| conformant (or at least mostly conformant) implementations
| available and relatively strong mindshare and ecosystem
| compared to extremely niche "CP solver packages and OR-
| tools" (which one exactly?) significantly reduces project
| risks such as not being able to find experts, the system
| not meeting functional or performance requirements, or
| becoming obsolete down the road. The same cannot be said
| for some mythical "CP solver packages and OR-tools"; you've
| nowhere to go if your "CP solver packages and OR-tools"
| project fails. Optimization and scheduling/planning
| projects, by their nature, are somewhat experimental and
| need exploration. It would thus be very difficult to pick
| "CP solver packages and OR-tools" upfront.
| gorkempacaci wrote:
| I agree with your point, I just would like to point out
| maybe the OR-tools they meant is the one made by Google,
| so a specific one:
| https://developers.google.com/optimization
| Karrot_Kream wrote:
| Yes that's the one sorry. I typed the comment hastily and
| didn't go back to edit it later.
| Karrot_Kream wrote:
| > extremely niche "CP solver packages and OR-tools"
| (which one exactly?) significantly reduces project risks
| such as not being able to find experts, the system not
| meeting functional or performance requirements, or
| becoming obsolete down the road. The same cannot be said
| for some mythical "CP solver packages and OR-tools"
|
| "Mythical CP solver packages and OR-tools"? Lol!
|
| Google's OR-Tools [1] has been winning golds in the
| MiniZinc Challenge since 2013 [2]. In 2023 it won Gold in
| most categories and the only Prolog to win, SICStus
| Prolog, took one Silver back. I'm curious where you're
| spending time in the community if you can word a comment
| like this as OR-Tools _is_ the behemoth in this area and
| Prolog is the weird hacker siren call that appeals to
| people who certainly aren 't about to publish anything
| novel in the space.
|
| I say this as someone who has tinkered a lot with Prolog
| over the years and finds Prolog's execution model to work
| really well with the way I think about programming.
| Prolog and its hybrid solver model just isn't good enough
| at any one thing to make it SOTA. It's fun to tinker
| with, but I just don't think in 2024 it has enough to
| offer anyone who's not interested in the language or the
| WAM to make it worth exploring, _especially_ not as an
| embedded constraint solver.
|
| [1]: https://developers.google.com/optimization/
|
| [2]: https://www.minizinc.org/challenge/
| cmrdporcupine wrote:
| I've tried casually to take this approach and what I've found
| is that basically none of the Prologs out there are really
| designed to be properly embeddable. Even Scryer Prolog,
| written in Rust, isn't really set up to linked into a Rust
| program and run this way. I was able to "sort-of" make it
| happen, but it wasn't a workflow that had been optimized for.
|
| To be clear what I'd like is to be able to fire up a thread
| hosting a Prolog runtime and stick predicates into it and
| query it using an API in the host language's syntax. Instead
| the best I could do was munge strings together and parse
| result out, sort-of. And that was after a bunch of time spent
| trying to reverse-engineer Scryer's API.
|
| I would love to embed a Prolog to host my application's
| business rules and knowledge. I could see it super useful in
| a game even (think of the myriad of crazy rules and
| interactions and special cases in a game like Dwarf
| Fortress...)
| tannhaeuser wrote:
| Yeah the preferred approach would be to run a Prolog engine
| as a service and access it via usual JSON-over-HTTP/REST
| protocols. Has the benefit of being able to adapt and
| scale/provision the specific Prolog engine load as well.
| For smaller projects I guess you could use Minikanren which
| is specifically for embedding as I understand it, but even
| standard job shop scheduling and factory/office resource
| planning tasks would be better served with a Prolog
| (micro-/whatever) service already IMO.
| DonHopkins wrote:
| You might be interested in reading about the Japanese "Fifth
| Generation Computer Systems" project from 1982, which revolved
| around PROLOG.
|
| https://en.wikipedia.org/wiki/Fifth_Generation_Computer_Syst...
|
| >The Fifth Generation Computer Systems (FGCS; Japanese: Di Wu Shi
| Dai konpiyuta, romanized: daigosedai konpyuta) was a 10-year
| initiative begun in 1982 by Japan's Ministry of International
| Trade and Industry (MITI) to create computers using massively
| parallel computing and logic programming. It aimed to create an
| "epoch-making computer" with supercomputer-like performance and
| to provide a platform for future developments in artificial
| intelligence. FGCS was ahead of its time, and its excessive
| ambitions led to commercial failure. However, on a theoretical
| level, the project spurred the development of concurrent logic
| programming.
|
| >The term "fifth generation" was intended to convey the system as
| being advanced. In the history of computing hardware, there were
| four "generations" of computers. Computers using vacuum tubes
| were called the first generation; transistors and diodes, the
| second; integrated circuits, the third; and those using
| microprocessors, the fourth. Whereas previous computer
| generations had focused on increasing the number of logic
| elements in a single CPU, the fifth generation, it was widely
| believed at the time, would instead turn to massive numbers of
| CPUs to gain performance.
|
| [...]
|
| >Concurrent logic programming
|
| >In 1982, during a visit to the ICOT, Ehud Shapiro invented
| Concurrent Prolog, a novel programming language that integrated
| logic programming and concurrent programming. Concurrent Prolog
| is a process oriented language, which embodies dataflow
| synchronization and guarded-command indeterminacy as its basic
| control mechanisms. Shapiro described the language in a Report
| marked as ICOT Technical Report 003,[7] which presented a
| Concurrent Prolog interpreter written in Prolog. Shapiro's work
| on Concurrent Prolog inspired a change in the direction of the
| FGCS from focusing on parallel implementation of Prolog to the
| focus on concurrent logic programming as the software foundation
| for the project.[3] It also inspired the concurrent logic
| programming language Guarded Horn Clauses (GHC) by Ueda, which
| was the basis of KL1, the programming language that was finally
| designed and implemented by the FGCS project as its core
| programming language.
|
| >The FGCS project and its findings contributed greatly to the
| development of the concurrent logic programming field. The
| project produced a new generation of promising Japanese
| researchers.
|
| https://www.sjsu.edu/faculty/watkins/5thgen.htm
|
| >The Japanese Fifth Generation project was a collaborative effort
| of the Japanese computer industry coordinated by the Japanese
| Government that intended not only to update the hardware
| technology of computers but alleviate the problems of programming
| by creating AI operating systems that would ferret out what the
| user wanted and then do it. The Project chose to use PROLOG as
| the computer language for the AI programming instead of the LISP-
| based programming of the American AI researchers.
|
| The Japanese National Fifth Generation Project: Introduction,
| survey, and evaluation:
|
| https://stacks.stanford.edu/file/druid:kv359wz9060/kv359wz90...
|
| >Abstract:
|
| Projecting a great vision of intelligent systems in the service
| of the economy and society, the Japanese government in 1982
| launched the national Fifth Generation Computer Systems (FGCS)
| project. The project was carried out by a central research
| institute, ICOT, with personnel from its member-owners, the
| Japanese computer manufacturers (JCMs) and other electronics
| industry firms. The project was planned for ten years, but
| continues through year eleven and beyond. ICOT chose to focus its
| efforts on language issues and programming methods for logic
| programming, supported by special hardware. Sequential 'inference
| machines' (PSI) and parallel 'inference machines' (PIM) were
| built. Performances of the hardware-software hybrid was measured
| in the range planned (150 million logical inferences per second).
| An excellent system for logic programming on parallel machines
| was constructed (XLI). However, applicationswere done in
| demonstration form only (not deployed). The lack of a stream of
| applications that computer customers found effective and the sole
| use of a language outside the mainstream, Prolog, led to
| disenchantment among the JCMs.
|
| Japan's Fifth Generation Computer Systems: Success or Failure?
|
| https://www.reddit.com/r/prolog/comments/owb0xg/japans_fifth...
|
| https://instadeq.com/blog/posts/japans-fifth-generation-comp...
|
| >This post is a summary of content from papers covering the
| topic, it's mostly quotes from the papers from 1983, 1993 and
| 1997 with some edition, references to the present and future
| depend on the paper but should be easy to deduce. See the Sources
| section at the end.
|
| [...]
|
| >Prolog vs LISP
|
| >Achieving such revolutionary goals would seem to require
| revolutionary techniques. Conventional programming languages,
| particularly those common in the late 1970s and early 1980s
| offered little leverage.
|
| >The requirements clearly suggested the use of a rich, symbolic
| programming language capable of supporting a broad spectrum of
| programming styles.
|
| >Two candidates existed: LISP which was the mainstream language
| of the US Artificial Intelligence community and Prolog which had
| a dedicated following in Europe.
|
| >LISP had been used extensively as a systems programming language
| and had a tradition of carrying with it a featureful programming
| environment; it also had already become a large and somewhat
| messy system. Prolog, in contrast, was small and clean, but
| lacked any experience as an implementation language for operating
| systems or programming environments. [...]
|
| >Fun Trivia
|
| >The one commercial use we saw of the PSI machines was at Japan
| Air Lines, where the PSI-II machines were employed; ironically,
| they were remicrocoded as Lisp Machines.
| Bunny_351 wrote:
| See also here for an actively maintained and relatively
| portable implementation of Flat GHC, Strand and PCN for UNIX
| systems:
|
| http://www.call-with-current-continuation.org/fleng/fleng.ht...
| emmanueloga_ wrote:
| Tangent to Prolog, perhaps check Flix, which includes logic
| programming features [1], and is discussed here from time to time
| [2].
|
| --
|
| 1: https://doc.flix.dev/fixpoints.html
|
| 2: https://news.ycombinator.com/item?id=25513397
|
| 2: https://news.ycombinator.com/item?id=31448889
|
| 2: https://news.ycombinator.com/item?id=38419263
| honorious wrote:
| I have been interested in Prolog since my time at the University,
| and I loved the idea of logic programming.
|
| For "proper" Prolog, in 2024 it is a niche language alive in
| specific constraint solving applications, but not really used
| outside of that. I haven't seen anyone attempting at using prolog
| as a general purpose language since the 90'.
|
| Datalog and logic-inspired languages tend to pop up here and
| there as domain-specific languages.
|
| Rego is a recent incarnation which had good adoption for k8s and
| other "modern" systems. However, when trying to get people in my
| org to adopt it in practice, I saw engineers struggle with the
| paradigm when complexity grows to more than toy problems.
| PaulHoule wrote:
| Don't forget the Datalog subset!
|
| In the 2000s I was interested in inference over RDF and wanted
| something a bit more than RDFS and OWL and found out about
| Datalog:
|
| https://en.wikipedia.org/wiki/Datalog
|
| There wasn't a lot of literature on it or implementations then
| but a few years later people realized it's a great query language
| for complex queries that does a great job on transitive closures,
| can do math (unlike OWL which won't do it because Godel proved
| first order logic + math is a hot mess)
|
| I took a comparative programming languages course circa 1993, the
| instructor thought that that Prolog was a taste of the future of
| programming. At first I thought the way you can implement
| ordinary procedural code in Prolog was really clever but if you
| write very much of it I think it is awkward; for instance it is
| common to treat procedural success as a logical failure because
| that gets the behavior you want.
|
| It's counterintuitive that you could write a reasonably fast
| interpreter for Prolog but Warren figured out how to do it and it
| really is a neat trick. In the 1980s the Japanese Fifth
| Generation project dreamed about parallel Prolog on a machine
| with 100s of CPUs but it was discovered pretty quickly that you
| couldn't really parallelize Prolog execution so they came up with
| the less expressive language
|
| https://en.wikipedia.org/wiki/KL1
|
| I am amused to see papers today where people are working on tasks
| similar to what they worked on in that project, parallelizing
| them with commodity hardware, and get scaling curves that look
| very similar to what was done with KL1. (In the end the 5GP
| settled on the same message-passing architecture that everybody
| else did until the GPU revolution came)
|
| One of the nicest examples in Prolog is writing a parser by just
| writing the productions which works because Prolog's resolver is
| quite similar to a common parsing algorithm. In the large
| however, you can add a library to a normal programming language
| like Python or Java where you write the same grammar in a DSL and
| it is handled by the library.
|
| See also production rules systems which use "forward chaining"
| with the RETE algorithm and variants for an approach which looks
| like Prolog in some ways but works in the reverse direction. My
| favorite example of this now is
|
| http://www.clara-rules.org/
|
| I built a prototype of a stream processing engine where the
| control plane was implemented as a set of production rules that
| would build a processing pipeline of reactive operators, key-
| value and triple stores and then tear it down. Unlike another
| stream processing engine I worked on, mine always got the right
| answers. I think a production rule system could be the target of
| a "low code" system. I'm a little disappointed that I've never
| seen a Javascript framework that uses production rules because
| they are a great answer to asynchronous communication
| choreography. (See complex event processing)
| fraber wrote:
| There was a massive parallel implementation of Prolog running
| on literally 256 processors: BA-Prolog (http://fraber.de/bap/).
| Unfortunately the hardware platform was abandoned some years
| later by Inmos.
| Nihilartikel wrote:
| I've brushed up against it in the form of datalog as the query
| language for databases like datomic and xtdb, so it's soul is
| alive and well!
|
| I'm also considering a prolog like domain specific language to
| make a state syncing engine with pure declarations of how the
| state in system A is reflected in System B, etc.
|
| Prolog itself may not be mainstream, but it is an answer to a the
| universal problem space of constraint solution, so comp sci will
| always be in its long shadow.
| Guthur wrote:
| I chose to use prolog to essentially build an expert system
| across and heterogeneous data ecosystem.
|
| Prolog could certainly use some serious improvements to its
| tooling. But the language is simple enough that it doesn't prove
| too much of an issue. You can get some much out of language it
| can be very powerful. In the system we've built it makes up a
| purely logical core that is completely referentially transparent,
| we leave all the ecky side effecting to a host program.
| GistNoesis wrote:
| The "magic" of Prolog is built upon two interesting concepts :
| Unification (
| https://en.wikipedia.org/wiki/Unification_(computer_science)... )
| and Backtracking ( https://en.wikipedia.org/wiki/Backtracking ).
|
| Often bad teachers only present the declarative aspect of the
| language.
|
| By virtue of being declarative, it allows to express inverse
| problems in a dangerously simple fashion, but doesn't provide any
| clue for a solution. And you are then using a declarative
| language to provide clues to guide the bad engine toward a
| solution. Making the whole code an awful mashup of declarative
| and imperative.
|
| Rules :
|
| - N integer, a integer > 1, b integer > 1
|
| - N := a * b
|
| Goal :
|
| N = 2744977
|
| You can embed such a simple problem easily but solving it is
| another thing.
|
| The real surge of Prolog and other declarative constraint
| programming type of language will be when the solving engines
| will be better.
|
| Unification is limited to the first order logic, high-order logic
| unification is undecidable in the general case. So we probably
| will have to rely on heuristics. By rewriting prolog goal solving
| as a game, you can use deep learning algorithms like alphago
| (Montecarlo tree search).
|
| This engine internally adds intermediate logical rules to your
| simply defined problem, based on similar problems it has
| encountered in its training set. And then solve them like LLM, by
| picking the heuristically picking the right rule from intuition.
|
| The continuous equivalent in a sort of unification is Rao-
| Blackwellisation (done automagically by deep-learning from its
| training experience) which allows to pick the right associations
| efficiently kind of the same way that a "most general unification
| algorithm" allows to pick the right variable to unify the terms.
| radomir_cernoch wrote:
| Do you see a good way to include backtracking in an imperative
| programming language?
|
| I can imagine how unification would work, since the ubiquitous
| "pattern matching" is a special case of Prolog's unification.
| But I've never seen how backtracking could be useful...
| vmchale wrote:
| backtracking is perilous in general; logic programming
| languages have really nice abilities for such but I don't
| know how to avoid pathological inefficiency.
| YeGoblynQueenne wrote:
| With memoization as in tabling (a.k.a. SLG-Resolution):
|
| https://www.swi-prolog.org/pldoc/man?section=tabling
|
| _Re-evaluation of a tabled predicate is avoided by
| memoizing the answers. This can realise huge performance
| enhancements as illustrated in section 7.1. It also comes
| with two downsides: the memoized answers are not
| automatically updated or invalidated if the world (set of
| predicates on which the answers depend) changes and the
| answer tables must be stored (in memory)._
|
| Known to the Prolog community since about the 1980's if I
| got my references right.
| abeppu wrote:
| > The continuous equivalent in a sort of unification is Rao-
| Blackwellisation (done automagically by deep-learning from its
| training experience) which allows to pick the right
| associations efficiently kind of the same way that a "most
| general unification algorithm" allows to pick the right
| variable to unify the terms.
|
| I don't know how to reconcile this statement about deep
| learning with my understanding of Rao-Blackwell. Can you
| explain:
|
| - what is the value being estimated?
|
| - what is the sufficient statistic?
|
| - what is the crude estimator? what is the improved estimator?
|
| Roughly, I think sufficient statistics don't really do anything
| useful in deep learning. If they did, they would give a recipe
| for embarassingly parallel training that would be assured to
| reach exactly the same value a fully sequential training. And
| from an information geometry perspective, because sufficient
| statistics are geodesics, the exploratory (hand-waving) and
| slow nature of SGD could be skipped.
| GistNoesis wrote:
| Once you view prolog goal reaching as a game. You can apply
| Reinforcement Learning methodologies. The goal is writing a
| valid proof, aka a sequence of picking valid rules and
| variables assignment.
|
| Value being estimated : The expected discounted reward of
| reaching the goal. The shorted the proof the better.
|
| The sufficient statistic : The embedding representation of
| the current solving state (the inner state of your LLM (or
| any other model) that you use to make your choices). You make
| sure it's sufficient by being able to regenerate the state
| from the representation (using an auto-encoder or vae does
| the trick). You build this statistic across various instances
| of problems. This tells you what is a judicious choice of
| variable based on experience. Similar problems yield similar
| choices.
|
| The crude estimator : All choices of have the same value
| therefore a random choice, The improved estimator : The
| choice value is conditioned on the current embedding
| representation of the state using a Neural Network.
|
| You can apply Rao-Blackwell once again, based by also
| conditioning one-step look-ahead. (Or at the limit applying
| it infinitely many times by solving the bellman equation.)
|
| (You can alternatively view each update step of your model,
| as an application of Rao-Blackwell theorem on your previous
| estimator. You have to make sure though that there is no mode
| collapse.)
|
| You don't have to do it explicitly, it happens under the hood
| by your choice of modelisation in how to pick the decision.
| inkyoto wrote:
| A unique property of Prolog is that, given an answer, it can
| arrive at the original question (or, a set of questions -
| speaking more broadly).
|
| Or, using layman terms, a Prolog programme can be run backward.
| ted_dunning wrote:
| To be precise, a small number of very small Prolog programs
| can be run backwards.
|
| There are essentially no significant Prolog programs that are
| reversible with acceptable efficiency.
| derdi wrote:
| To be even more precise, Prolog programs only ever run
| forward because the order of evaluation is fixed as top-
| down, left-to-right. These notions of "forward" and
| "backward" are very unhelpful and should be given up.
| Beginners find the order of evaluation hard enough to
| understand, let's not confuse them even more.
|
| Also, the notion is woefully incomplete. Let's say we
| consider this "forward": ?-
| list_length([a, b, c], Length). Length = 3.
|
| Then you would say that this is "backward":
| ?- list_length(List, 3). List = [_A, _B, _C].
|
| Fine, but what's this then? "Inward"? ?-
| list_length([a, b, c], 3). true.
|
| And then presumably this is "outward": ?-
| list_length(List, Length). List = [], Length = 0 ;
| ... List = [a, b, c], Length = 3 .
|
| None of these cases change the order of evaluation. They
| are all evaluated top-down, left-to-right. The sooner
| beginning Prolog programmers understand this, the better.
| The sooner we stop lying to people to market Prolog, the
| better.
| kazinator wrote:
| What's going on in the second example? Did Prolog
| generate a list term stuffed with gensym variables, which
| satisifies the list_length being 3?
| derdi wrote:
| It generated a list stuffed with distinct logical
| variables. Any list of length 3 is unifiable with this
| list. Or in other words, this is the unique (up to
| variable renaming) most general list of length 3.
|
| Whether this is a "yes" to your question depends on what
| your mental model of "gensym variables" is. They are
| variables, not symbols (which Prolog would call atoms).
| inkyoto wrote:
| I was largely joking. Even though the capability is there,
| it is not computationally practical nor possible to
| accomplish such a feat for any sufficiently complex
| programme.
|
| In the most extreme case, attempting to run a complex
| Prolog programme backwards will result in an increase in
| entropy levels in the universe to such an extent that it
| will cause an instant cold (or hot) death of our universe,
| and life as we know it will perish momentarily (another
| tongue in cheek joke).
| agumonkey wrote:
| the bidirectional (relational) aspect of prolog is what got
| me into this. I love symmetries so it was a natural appeal
| even before I learned about logic programming (Sean Parent
| made a google talk about similar ideas implemented in cpp).
| That said it's very limited. But I wonder how far it could
| go. (the kanren guys might have more clues)
| mvolfik wrote:
| If you are interested in small fun stuff, SWI-Prolog has network
| libraries. Just recently, I implemented a network gomoku (5-in-a-
| row) game in it for my school project:
| https://gitlab.mff.cuni.cz/volfmat1/prolog-network-gomoku. Turns
| out you can also write quite imperative-style code with it :D
| grose wrote:
| It's great to hear new people are interested in the language! I
| was enlightened a couple years ago and fell in love.
|
| Currently I'm focusing on creating easy-to-use embeddings of
| Trealla Prolog using Wasm. You can find my TypeScript library
| here: https://github.com/guregu/trealla-js and Go library here:
| https://github.com/trealla-prolog/go. The goal is to make the
| libraries as painless as possible. Trealla is a portable and
| lightweight Prolog written in C that supports CLP(Z) and is
| broadly compatible with Scryer. It's quite fast! I'm currently
| using it for some expert system stuff at $work and as an internet
| forum embedded scripting language for $fun.
|
| Speaking of Scryer, they recently got their WebAssembly build
| working and I hope to contribute a JS library for them in the
| future as their API stabilizes. Scryer and Trealla are both
| aiming for ISO compatibility, so it's my hope that we can foster
| an ecosystem for modern ISO Prolog and provide more embeddings in
| the future. It's super convenient to get logic programmer
| superpowers in your favorite language. Also check out Scryer's
| new website: https://www.scryer.pl/
|
| For something on the silly side, check out https://php.energy.
| Prolog Home Page, it's web scale :-). It's proof that you can
| integrate Prolog with bleeding edge stuff like Spin (server-side
| wasm ecosystem).
| vmchale wrote:
| Girard has some commentary scattered about his writing.
|
| The search algorithms for logic programming are simply slow, it's
| a very interesting idea in programming languages, but there's a
| reason it's not widely used.
|
| > PROLOG, its misery. Logic programming was bound to failure, not
| be- cause of a want of quality, but because of its exaggerations.
| Indeed, the slogan was something like << pose the question,
| PROLOG will do the rest >>. This paradigm of declarative
| programming, based on a << generic >> algorithmics, is a sort of
| all-terrain vehicle, capable of doing everything and therefore
| doing everything badly. It would have been more reasonable to
| confine PROLOG to tasks for which it is well-adapted, e.g., the
| maintenance of data bases.
|
| > On the contrary, attempts were made to improve its efficiency.
| Thus, as systematic search was too costly, << control >>
| primitives, of the style << don't try this possibility if... >>
| were introduced. And this slogan << logic + control13 >>, which
| forgets that the starting point was the logical soundness of the
| deduction. What can be said of this control which plays against
| logic14? One recognises the sectarian attitude that we exposed
| several times: the logic of the idea kills the idea.
|
| > The result is the most inefficient language ever designed;
| thus, PROLOG is very sensitive to the order in which the clauses
| (axioms) have been written.
| withoutboats3 wrote:
| This is a great quote and sadly true. What text is this from?
| thih9 wrote:
| "The Blind Spot: Lectures on Logic" by Jean-Yves Girard
| YeGoblynQueenne wrote:
| For me this kind of criticism is very familiar. It comes from
| theoretical computer scientists who have these purist
| ideological convictions about how a declarative language
| should look and behave, that are as unrealistic, because
| impossible to implement on a real-world computer, as they are
| uninteresting for practicing programmers because strictly a
| matter of aesthetics. Such critics have never made anything
| useable themselves and are simply angry that someone else
| made something that works in the real world while they were
| busy intellectually masturbating over their pure and
| untouchable vision.
|
| Although I concede that my comment might be a bit unfair to
| Girard who did, after all, invent the mustard watch.
| withoutboats3 wrote:
| This comment is idiotic.
| YeGoblynQueenne wrote:
| No, what's idiotic is the trite bullshit in the quote in
| the GP's comment- and from a logician from Aix-Marseille,
| no less!
|
| Prolog is "well adapted" to the "maintenance of
| databases". The only reason this nonsense keeps being
| repeated is because Prolog programs are stored as rows in
| a database. It's like people look at a list of keywords,
| pick out "database" and go "ah, so Prolog is a language
| for databases". Zero understanding of what the database
| is in there for: because your program and your data are
| one.
|
| Or take the "attempts" that "were made to improve its
| efficiency". What the illustrious academic is kvetching
| about here is the cut (!/0) an extra-logical construct
| used in Prolog to cut choice points (like markers in
| program state where execution backtracks to) and so lets
| the programmer control the program. Again, what we seem
| to have here is a bingo-card understanding of Prolog:
| someone wrote down the keyword "control", the academic
| looked at the cut and thought "ah, that's what 'control'
| means!". No, it means that an algorithm can be thought of
| as logic, that is always the same, and control, that
| depends on the executing machine. That's what "algorithm
| = logic + control" means, not that you get to cut choice
| points with a "control" structure.
|
| That's what's idiotic, and btw that's the common
| misunderstandings that clueless Prolog "critics" have
| been making since forever. It's trite, tired, boring
| bullshit that makes it clear the "critic" has no idea
| what they're talking about and are just looking for
| something to say to show they're knowledgeable and smart.
| 29athrowaway wrote:
| With ChatGPT it is a great time to learn new programming
| languages.
|
| Questions such as "give me table with a glossary of basic Prolog
| terminology with examples" as well as others can be helpful.
| evgskv wrote:
| I think of Prolog as a general purpose logic programming language
| and Datalog to be logic programming more focused on data
| analysis. Data analysis is a very large area, so boundary might
| get blurry at times.
|
| If your data is in a relational database consider Logica - a
| Datalog family language that compiles to SQL and runs naturally
| on SQLite, Postgres, DuckDB and Google BigQuery.
|
| Easy to install, easy to play with in CoLab or any other Jupyter
| notebook.
|
| Works for data analysis (aggregation, filtering etc) that is
| commonly associated with SQL, as well as recursive logical
| querries commonly associalted with Logic programming per-se.
|
| Here is what it looks like for a data-analysis-ish query of
| finding popular baby names over time:
|
| # Count babies per year.
|
| NameCountByYear(name:, year:) += number :- BabyNames(name:,
| year:, number:);
|
| # For each year pick the most popular.
|
| TopNameByYear(year) ArgMax= name -> NameCountByYear(name:,
| year:);
|
| # Accumulate most popular name into a table, dropping the year.
|
| PopularName(name: TopNameByYear());
|
| The classic grand-parent rule looks as usual:
|
| Grandparent(a, c) :- Parent(a, b), Parent(b, c);
|
| Here is a recursive program for finidng distances in a directed
| graph:
|
| D(a, b) Min= 1 :- Edge(a, b);
|
| D(a, b) Min= D(a, x) + D(x, b);
|
| Links to CoLabs:
|
| Grandparent, ancestor:
| https://colab.research.google.com/drive/1lujnnUOXsF6VrC9__jV...
|
| Distance in graph:
|
| https://colab.research.google.com/drive/1sOCODHqN0ruxZSx_L-V...
|
| Github repo: https://github.com/EvgSkv/logica
| conjurernix wrote:
| Not exactly a prolog, but Verse, a logical (and functional, or
| functional logic) programming language developed at Epic Games by
| Simon Peyton Jones of Haskell fame and Tim Sweeney. You can
| already use it to build mods for fortnite or something like that
| not really sure. But there's no open source compiler available
| yet.
| jodrellblank wrote:
| What is it like? 50 years of historic cruft. Questionable whether
| there are more trip hazards than usefulness for ordinary coding.
| A fractured community which feels like there are more Prolog
| systems than Prolog code. Learning Prolog is less "how do I do
| things in Prolog" and more "how do I contort my things to avoid
| tripping over Prolog?".
|
| A few dedicated clever people and idealists and dreamers talking
| about ontologies and building things I don't understand, e.g. the
| link in https://news.ycombinator.com/item?id=40994780 that could
| either be genuinely "Prolog is suitable for things no other
| language is" or "Fusion is 10 years away" or "Perpetual motion is
| here and so is cold fusion!", I can't tell. But I suspect from
| the lack of visible activity out in the wider world, closer to
| the latter than the former. Or perhaps the people able to make
| use of its strengths are few and far between.
|
| There's a saying about driving to a town which has been hollowed
| out and is now a road through some empty store fronts and car
| parks: "there's no _there_ there ". The soul of a place is
| missing, it's no longer a _destination_ , just some buildings on
| some land. Prolog has the opposite of that, a main road straight
| past it, few buildings or people, but there is a _there_ there -
| an attractor, spark of something interesting and fun. Buried in
| years of cruft. Might be a Siren 's call though, a trap - but if
| it is it appears less dangerous than the LISP one.
| chamomeal wrote:
| What do you mean by LISP as a siren call?
|
| I've just started learning clojure and besides the lack of
| static types (which is pretty harsh for me), it seems like a
| fun and practical language.
| epgui wrote:
| Clojure is probably the most beautiful language I've ever
| worked with. Nothing is perfect, but Clojure is _very_ simple
| and elegant.
| 7thaccount wrote:
| Only downside is I don't know Java, so some things that
| should be obvious are opaque to me.
| xyproto wrote:
| Java frolicks in opaqueness.
| epgui wrote:
| You really don't need to know any java. I don't know java
| either.
|
| Even if you're doing java interop, it's quite easy to
| figure it out.
| 7thaccount wrote:
| Last time I looked about file IO it involves calling out
| to some Java class that I had no clue about as I don't
| use Java. All the doc of the time just assumed you should
| be able to figure this all out.
|
| Edit: it's been like 5 years
| andrewflnr wrote:
| This was my experience too, at about the same time. I
| should really dig back into it at some point.
| fulafel wrote:
| The docs are better now (eg https://clojure-
| doc.org/articles/cookbooks/files_and_directo... ) but you
| still need to follow a Javadoc link every now and then
| for the full story.
|
| Alternatively you can use a library such as
| https://github.com/babashka/fs .
|
| I agree with the GP that you don't need to know any Java.
| xigoi wrote:
| What makes Clojure a non-starter for me is that it runs on
| the JVM.
| harperlee wrote:
| Could you expand why? It's not immediately obvious why
| would that be, my understanding is that the general
| consensus around here is that the JVM is a superb piece
| of tech with a bad rap due to java the language.
| xigoi wrote:
| Slow startup, huge memory consumption, design that
| inherently favors class-based languages like Java, the
| frequent need to use Java libraries.
| epgui wrote:
| > Slow startup
|
| This makes the jvm a bit less suitable for programmes
| with short lifetimes (like lambdas), depending on how
| sensitive startup times are in context... But is mostly
| irrelevant in long-lived applications like services.
|
| > design that inherently favors class-based languages
| like Java
|
| Clojure abstracts over this so well that it's really a
| non-issue for a wide array of use cases / applications.
| When programming in Clojure, you really don't have to
| think about objects and classes at all, unless you really
| insist on doing so.
|
| > frequent need to use Java libraries
|
| This would be going against the grain: you will have a
| much better time by staying within native Clojure. I've
| worked on commercial/production applications that barely
| had any java interop, and whatever java interop there was
| was rarely ever involved in day to day work.
|
| ---
|
| Disclaimer: I also am not a huge fan of the JVM and I
| really dislike the Java world generally, but it never
| stood in the way of me getting stuff done with Clojure.
| ethagnawl wrote:
| core.logic is pretty neat, too. Especially as it applies to
| this thread and the ancestor comments.
| wk_end wrote:
| Imagine it's, like, 1980 - or even earlier - and you can work
| in a language roughly as nice as Clojure, except the rest of
| the world is stuck working with pre-ANSI C or Pascal or
| FORTRAN or COBOL or raw assembly language. There's no Python
| or Java or C# or Ruby or Perl or Haskell or Scala or Kotlin
| or Rust or JS/TS. Nothing really resembling our modern idea
| of a high-level language.
|
| (OK, there was Smalltalk. Let's ignore Smalltalk. Lord knows
| everyone else did.)
|
| That'll alter your perception of reality a bit. Here they
| were, in possession of a tool massively more powerful - and
| more elegant - than what everyone else is using. And
| moreover, everyone else took a look at it and _turned their
| noses up_.
|
| Clearly, you and your fellow Lisp programmers are a different
| breed, capable of seeing further than the rest of the
| unwashed masses. In a word, you were better than them.
|
| It sounds like I'm being disparaging, but to a certain
| extent, I don't even think this was totally a wrong attitude
| to have. Elitist, definitely, but not wholly unwarranted.
| Lisp really was - in terms of expressiveness, anyway - really
| that far ahead of the competition. And yet somehow that
| competition won. The world is cruel and unjust.
|
| So Lisp becomes a kind of Us v. Them cult: if you've heard
| the good word of McCarthy, you're one of Us. If not, you're
| best ignored - too stupid to possibly have anything
| worthwhile to say.
|
| (If you think I'm exaggerating, spend some time reading the
| words of Usenet Lisp institution Erik Naggum - R.I.P. - who
| serves as the most extreme but hardly the only example.)
|
| This blinded Lisp diehards to the outside world, which slowly
| but surely, in many respects, began to catch up or even
| exceed Lisp.
|
| The other thing is - not only is Lisp a powerful language, at
| its core is a beautiful and simple and expressive
| mathematical idea. Combine that with the way macros allow you
| to extend the language virtually infinitely, there can be a
| near religiosity at the heart of Lisp - from one lambda all
| things depend. Lisp isn't just good engineering - it's a
| glimpse at the fundamental nature of computation, of the
| universe itself.
|
| I'm not going to sit here and tell you that this is somehow a
| terrible thing, per se. But it can be incredibly alluring to
| the right kind of mind, and once you're in its thralls it's
| hard to get out. You might be working with the tool, but in
| another sense the tool is working with you. A Siren Song.
| forgetfulness wrote:
| There's also the not all small factor that there was glam
| to Lisp.
|
| Early Internet discourse around programming was dominated
| by people who had ties to elite universities in the 1980s,
| who yearned for the times when the US Government was
| throwing an abundance of money to the AI industry of the
| time.
|
| They were the ones rubbing elbows with researchers from
| MIT, Stanford, Harvard, and Berkeley, who were using
| specialized hardware and software beyond the capabilities
| available to that of developers working on more mundane
| applications, all graciously funded by DARPA initiatives.
|
| That experience was, in truth, unrelatable to young people
| reading the recollections of ESR and RMS of the period, the
| in-jokes of these people, their ideas and interactions, but
| the tales of Lisp, the Lisp hackers and their fabled Lisp
| machines would be extremely appealing to someone who was
| very passionate about programming, striving for excellence
| as a programmer, and to advance in life through merit. Paul
| Graham would seal the deal with his essays.
| asimpletune wrote:
| Learning about the curse of lisp is always an eye opening
| point in one's career
| pjmlp wrote:
| > (OK, there was Smalltalk. Let's ignore Smalltalk. Lord
| knows everyone else did.)
|
| As someone that used Smalltalk/V on Windows 3.x, was aware
| of Smalltalk role on OS/2 and SOM, alongside the whole
| Visual Age line of products before Sun coming up with Java,
| there were enough people looking around Smalltalk until
| 1996.
| chamomeal wrote:
| Wow, thank you for the context!! That was a fun read. And
| definitely explains some of the stuff I've read about Lisp.
| (I only ever thought to look into lisp because of this xkcd
| https://xkcd.com/224/)
| jolt42 wrote:
| Lisps don't get in your way, but they also have no opinions,
| which is problematic for community development. As a static
| type fan, it's the only language I think the pros outweigh
| than one con.
| slashdave wrote:
| Who still has nightmares of infinitely nested parenthesis?
| jolt42 wrote:
| They seem to disappear with parinfer.
| forgetfulness wrote:
| The more nightmarish thing about Clojure is realizing that,
| in truth, you have no idea what all these dicts you are
| passing around the terse, nil-punning functions of your
| codebase hold at any given time.
| nogridbag wrote:
| That was the case for me. I went all in drinking the
| Clojure koolaid and wrote some small internal CLI tools
| with it. If I came back to that code a month or two later I
| could only properly understand it if I opened up a REPL to
| debug it. I ported those tools to Java and they were dead
| simple to comprehend.
| kamaal wrote:
| After a while, lesser the magic, the better.
|
| One of the reasons Golang has had a use case in today's
| age is there is a need for a programming language with
| just functions, loops and if/else statements.
| koito17 wrote:
| Yup. I learned Clojure just so I can use a Lisp and get
| paid for it, but there is some weird cult against all forms
| of typing. Even coming from a Common Lisp background, this
| was strange to me. In Common Lisp, there are
| implementations (like SBCL and ECL) that can make use of
| type declarations to produce efficient machine code _and_
| allow the compiler to catch errors that would otherwise be
| run-time errors. There 's also other benefits like
| contextual autocomplete. The autocomplete in Clojure
| tooling is very basic, and many Clojure libraries try to
| make up for this by using qualified keywords everywhere.
| That way, rather than seeing all keywords ever interned,
| you can type ":some.namespace/" and your editor shows a
| dozen keys instead of hundreds of unrelated keys.
|
| Many in the Clojure community believe that occasionally
| validating maps against a schema "at the boundaries" is
| good enough. In practice, I have found this to be
| insufficient. Nearly every Clojure programmer I know has
| had to "chase nils" as a result of a map no longer
| including a key and several functions passing down a nil
| value until some function throws an exception. (Note: I
| don't specify which exception, because it depends on how
| that nil value gets used!)
|
| Refactoring Clojure code in general is a nightmare, and I
| suspect it is why many in the community are reluctant to
| change code in existing libraries and build entirely new
| things in parallel instead. Backwards compatibility is one
| often-cited reason, but I do think another reason is that
| refactoring Clojure code creates an endless game of bug
| fixing unless you have full test coverage of your codebase
| and use generative testing everywhere. (I've never seen a
| Clojure codebase with both of these things. I can count on
| one hand the number of Clojure codebases where generative
| testing is used at all).
|
| Function spec instrumentation provides something that feels
| like runtime type checks in Common Lisp, but now you have
| to manually run certain functions at the REPL just to
| ensure some change in your codebase did not introduce a
| type error.
|
| On the flip side, Java has things like DTOs which always
| felt too boilerplate-ish for me (though at least it
| provides useful names for endpoint data when generating
| Swagger/OpenAPI documentation). Even then, records in Java
| provide what are essentially maps with type safety and
| similar characteristics as DTOs.
|
| I think the structural typing offered by languages like
| OCaml and TypeScript provide exactly what I'd want in
| Clojure. But when faced with feature requests in Clojure,
| people will state something like "I have never had a use-
| case for X, therefore you don't need X". In the case of
| criticisms, the response is often "I may have ran into X
| before, but it's so rare that I don't consider it a
| problem".
| nogridbag wrote:
| I still don't get how Java records can be used for
| anything like a DTO. Since you're a Clojure dev you may
| remember the pattern Rich Hickey described as "place
| oriented programming" :) Nearly every endpoint will have
| more than 2-3 fields and you really don't want a Java
| record with more than that many fields for the same
| reason you don't want a Java method with that many fields
| e.g. doIt(Long, String,String,Long,String,int,int,String)
| <-- code smell.
|
| And the problem I always see is something may start off
| as a Java record and then need to be refactored into a
| class as soon as 1-2 more fields are added.
| koito17 wrote:
| > I still don't get how Java records can be used for
| anything like a DTO
|
| In Clojure, we often deserialize a result set from a
| database to a vector of maps. These maps have different
| keys depending on what exactly your query was selecting.
| In Java, one often "projects" results to some DTO. This
| is one scenario where records offer identical
| functionality while avoiding boilerplate.
|
| Regarding "place-oriented programming", records are
| immutable, so that is one technical advantage they have
| over handwriting a DTO. And from my short experience
| using web frameworks like Quarkus, it seems that a lot of
| the "design patterns" I see in documentation exist to
| help design easy-to-test programs rather than unfettered
| mutation.
|
| Additionally, I have found records useful for describing
| the payload of endpoints that accept map-like data.
| Without records, I would be writing POJOs with public
| fields anyway.
|
| Overall, Java records behave like TypeScript interfaces
| with awkward syntax. I have found them ideal for
| expressing type-safe, map-like data with minimal
| boilerplate.
| nogridbag wrote:
| I'm also using it for projections. But to be honest we
| have a fairly large Quarkus app and only use projections
| in a few places. For immutable classes with a large
| number of fields where instances have to be created
| manually I usually use the builder pattern. But the
| analogy to typescript interfaces is interesting.
| ghufran_syed wrote:
| Could you use https://github.com/clojure/core.typed ? Or
| https://clojure.org/guides/spec ?
| koito17 wrote:
| Typed Clojure is interesting. However, until two months
| ago, it was practically unusable for most Clojure
| projects because of the lack of type inference in higher-
| order functions. This has changed, but there's another
| huge problem: nobody maintains type declarations for
| widely used libraries. If you look at alternatives to
| TypeScript, such as ReScript, you will find similar
| issues.
|
| I still use Clojure, but I am fully aware of the kind of
| bugs to expect down the road. Typed Clojure would work if
| I could maintain types for each library I use, but that
| is simply too much effort on my part.
|
| As for clojure.spec, I already addressed this in my post,
| but I will state the following.
|
| Schema, Malli, and Spec are not substitutes for a type
| system. Each of these libraries explicitly state so. You
| still need to enable instrumentation and _run_ erroneous
| code violating some contract. Most Clojure programmers
| have the habit of enabling instrumentation in dev and
| disabling it in production because validation is an
| expensive operation. I personally use Malli for data
| validation and coercion, but it does not make refactoring
| any easier, nor does it help autocomplete and other
| development-related tooling.
|
| (Someone will probably link a malli document
| demonstrating clj-kondo linter generation, but even that
| is not a substitute. At best it detects arity errors and
| primitive type mismatches, not the shape of data in a
| map).
| everforward wrote:
| > A few dedicated clever people and idealists and dreamers
| talking about ontologies and building things I don't understand
|
| I was briefly deeply interested in ontologies via OWL and I
| suspect Prolog has the same issues that I think plague
| ontologies in general.
|
| They are a fantastic tool for a system complex enough to be
| nearly useless. Modelling an ontology for a reasonably complex
| domain is unreasonably difficult. Not because the tools are
| bad, but because trying to define concrete boundaries around
| abstract ideas is hard.
|
| What is a camera? A naive attempt would say an item that takes
| pictures, but that would include X-rays. Are deep-space radio
| telescopes cameras? Trying to fix those issues then causes
| second order issues; you can say it's something that takes
| images from the visible light spectrum, but then night vision
| cameras aren't cameras anymore.
|
| The reasoning systems work well, they just don't solve the hard
| part of designing the model.
| riku_iki wrote:
| your camera example demonstrates that human knowledge is
| loosely structured and formalized in general, so you can't
| create strict onthology. One way to work around is to assign
| some confidence score on statements, so you will have
| something like that Nikon device is likely camera, and x-ray
| machine is unlikely camera based on current world model.
| wslh wrote:
| Yes, I think that is the experience, for example, in what we
| called (or call) data science: most of the time is spent in
| ETLs rather than using ML methods. In a real company linking
| data difficulty is not technical but time and resource
| consuming.
| strangattractor wrote:
| I had similar discussions with people that wanted to encode
| published research into ontologies. I would ask researchers
| what they think - the answer was always great idea. I would
| then follow up with - How would you use it? No response. I
| finally concluded that it would never happen.
|
| 1. No one wanted it enough to pay for it to happen.
|
| 2. There is always a turn over of ideas coming and going
| which can never be sufficiently updated to keep it useful.
| Again no one would pay anyway.
|
| Tools like LLMs seem to be fill the role now. I would like to
| see a Prolog integrated with LLMs is someway (lack of
| imagination fails me how that would happen).
| rscho wrote:
| A theorem prover for the medical literature:
|
| https://github.com/webyrd/mediKanren
|
| http://minikanren.org/workshop/2020/minikanren-2020-paper7.
| p...
|
| Not prolog though. But gives an idea about the goals behind
| the classification of science papers.
| varjag wrote:
| This is why Lenat and CYC had settled on micro-theories. They
| found it impossible to build a useful universal ontology so
| had to fracture them on domain boundaries.
| imglorp wrote:
| I was just pondering if the Prolog universal quantifier
| would be applicable to reasoning about Cyc frames. Does
| your comment imply it's not?
| nl wrote:
| I'm somewhat familiar with Cyc but I'd never heard of
| this development of "micro-theories". It makes perfect
| sense though - to generalize hugely structured ontologies
| break as soon as the second person tries to use them or
| they are used on a slightly different domain.
|
| Anyway, Prolog should be suitable for reasoning over
| them, but it is only grounded in the "micro-theory" part.
| drdeca wrote:
| I don't see an issue with saying "X-ray photography machines,
| and deep-space radio telescopes, are (or at least contains-a,
| in the case of the telescope) cameras". They just aren't
| ordinary cameras of the sort that a typical person might take
| a picture with.
|
| I think most of the reasoning you would want to do with a
| concept of "camera" that excludes X-ray machines and
| telescopes, but includes night-vision, could be handled with
| "portable camera"?
|
| Hm, I guess you probably want to include security cameras
| though..
|
| Ok. "Portable cameras or security cameras".
| HelloNurse wrote:
| An universal ontology cannot have any notion of an
| "ordinary" camera, not because of expressive limitations
| but because it's subjective.
|
| Is a CAT machine a camera? Maybe only its sensor and the
| computers that reconstruct images? Maybe just the sensor?
| It mostly depends on your location in the supply chain.
|
| Is a box with a projection plane and no means to capture
| images a camera? Before about 1830, definitely (and then
| making photographs became a simple upgrade for your "camera
| obscura").
| drdeca wrote:
| I don't think the "before 1830" case is really an issue.
| That's just an example of the meaning of words changing.
|
| I didn't mean that "ordinary camera" should be a term in
| the formal ontology. I meant something more like "If you
| want to formalize the notion of 'a camera', it should
| include the CAT machine and telescope. If you want to
| address only the types of cameras that you think of as
| ordinary cameras, you should add extra qualifiers to get
| at what you mean." .
|
| (Where, "what you mean" might not get the term "ordinary
| camera", but something more clear and descriptive.)
| worik wrote:
| Ontology: Study of the nature of being, becoming, existence
| or reality, as well as the basic categories of being and
| their relations (philosophy)
|
| What does that have to do with this?
|
| Is there some use of "ontology" in logic I have not heard of?
| mannyv wrote:
| In this context ontology means common
| vocabulary/categories.
| scheme271 wrote:
| Maybe more in philosophy and classic general AI. Basically
| ontologies are systems of categorizing and classifying
| knowledge. E.g. if you want to reason about self driving,
| you would have an ontology that lets you separate traffic
| signs from billboards.
| zdragnar wrote:
| Domain Driven Design - one of those things like Agile that
| triggers all sorts of holy wars - has a lot of overlap with
| the general concept of ontologies, to the point that I've
| seen some teams formalize all communication between
| microservices through a shared "ontology", which in reality
| was essentially a giant XML based descript of valid nouns
| and verbs that events could use to communicate between
| services.
|
| Additionally, there's a good deal of overlap with the
| "semantic web" concept, which itself had a good deal of
| hype with very limited (but important) application- even
| the W3C has some published content on how all three fit
| together: https://www.w3.org/2001/sw/BestPractices/SE/ODA/
| everforward wrote:
| It would be this version of ontology: https://en.wikipedia.
| org/wiki/Ontology_(information_science)
|
| Loosely speaking, ontologies are categories of objects
| defined by their attributes and relationships to other
| things. Where a hierarchy is a branching structure where
| items can only appear on the tree once, ontologies do not
| require everything to stem from a single "root" node and
| items can appear in the tree in more than one place.
|
| It's a way of working around how hierarchies can't model
| some things very well. E.g. "bipedal" is an attribute that
| can apply to both animals and robots; where does it go in a
| hierarchy that it can apply to both animals and robots
| without also implying that robots are animals or vice
| versa.
| 7thaccount wrote:
| My honest opinion is to avoid Prolog for most enterprise needs in
| favor of a regular general purpose programming language that
| calls out to a mathematical or constraint solver via API when the
| need arises. This way you get a language that is easier to learn
| with a strong ecosystem of libraries along with a solver that is
| built for your particular problem.
|
| Prolog may excel in some niche cases that are documented out
| there which is fine. For the majority of cases I can think
| of...it is too esoteric.
|
| Prolog is SUPER cool though as is it's history. You should
| definitely play with it a bit.
| vector_spaces wrote:
| To piggyback onto OP to ask about something very loosely related:
| what about miniKanren? Are there any active projects or work
| being done here, either in academia or industry? Most of the ones
| listed on minikanren.org appear to be dead -- although I haven't
| gone through them all since last year
| tpoacher wrote:
| You may find this paper interesting:
| https://www.cambridge.org/core/journals/theory-and-practice-...
|
| title: Fifty Years of Prolog and Beyond (2022)
| waldrews wrote:
| There are a few magical algorithms/systems which give you
| superpowers if you can find the right application for them. At
| least in the pre-LLM era, they were some of the magical tools we
| had, for just solving declaratively specified difficult problems
| without us explicitly writing code, while (unlike certain AI
| techniques which shall remain nameless) providing correctness
| guarantees and often being deterministic and stable.
|
| Prolog and logic programming is one, together with its relative,
| constraint logic programming, and its relative mixed integer
| programming, which in turn is part of the broader linear and
| convex programming family.
|
| What else should we put in that category?
| z5h wrote:
| In theory, Prolog is the king of languages. Simultaneously a
| logical formalism, and (with a resolution system) a language for
| computation, AND the ultimate meta-programming language as its
| homoiconic but only _goals_ are evaluated (there is no eager
| /lazy evaluation fuss - a term is just a term), and goals can
| only succeed (and have any consequence) if there is already a
| matching clause.
|
| In practice, there are some very performant and maintained
| implementations with small but helpful communities.
|
| Also in practice. With all of this power, it's clear that
| anything could be done (well) in Prolog, but it's not always
| clear what that way might be. DCGs are an example of a beautiful,
| elegant, simple, powerful way of building parsers (or state
| machines) that was not immediately evident to the Prolog
| community for some time. The perpetual conundrum as a user will
| be "I could do it this way, but there are certainly better ways
| of doing this, and I have many avenues I could explore, and I
| don't know which might be fruitful in what timeline".
| wkyleg wrote:
| I like Peter Norvig's book "Paradigms of AI Programming," where
| you learn old fashioned symbolic AI with LISP and Prolog. Is it
| outdated? Absolutely, but it is a classic read.
|
| Maybe a use case for new AI models could be creating more old
| fashioned expert systems written in LISP or Prolog that are
| easier for humans to audit. Everything tends to come back full
| circle.
|
| https://www.amazon.com/Paradigms-Artificial-Intelligence-Pro...
| foobarqux wrote:
| Logic programming is overrated, at least for logic puzzles (2013)
|
| https://news.ycombinator.com/item?id=36154011
| harperlee wrote:
| And the response for the curious: Logic programming is
| underrated (also 2013):
| https://news.ycombinator.com/item?id=5846185
| gnulinux wrote:
| I recommend that you check Souffle programming language out,
| here: https://souffle-lang.github.io/index.html
|
| * It is a dialect of Prolog
|
| * It reads from and writes to SQLite database format as well as
| CSV. This allows you to preprocess or postprocess data Souffle
| produces, or Souffle reasons. E.g. you can generate bunch of data
| in Python, output Sqlite, reason in Souffle. Load reasoning
| output back into python via sqlite.
|
| * It is pretty feature complete when it comes to logical
| reasoning, and transactional database management. You get best of
| both Prolog and Sqlite worlds.
| hpincket wrote:
| I've played around with Prolog on and off for 7 years. Still a
| novice. It's one of those languages that forces your mind to grow
| in new directions.
|
| It's difficult to make a case for it. The declarative paradigm is
| nice, but compared to other languages you're only saving a couple
| for-loops. I think its benefit comes from expressiveness for
| problems where clpfd can be applied. I once built an internal
| tool with Python and SWI Prolog that combined user input with
| CLPFD to configure test accounts in a consistent and useful way.
| Users could provide partial constraints, and the system would
| fill in the rest. Again, the ease of clpfd is great.
|
| I've had some fun generating Prolog facts/databases with LLMs and
| it's something I want to explore more.
|
| Note: I was just messing around with Prolog this week:
| https://hpincket.com/adding-an-easter-egg-to-our-numeronym-p...
| throwaway4aday wrote:
| It's an interesting but fundamentally flawed idea. My suggestion
| would be to play with it and have fun but don't bet the house on
| it.
|
| If you're curious what the flaw is, think Empiricism vs
| Rationalism.
| ghufran_syed wrote:
| I know almost nothing about prolog, but I enjoyed this tutorial
| using Datalog, a subset of prolog as an alternative data query
| language to SQL: https://www.learndatalogtoday.org/
| wolfspider wrote:
| Formal verification uses Prolog a lot. System on TPTP at U of
| Miami utilizes this for many of the formally verified tests on
| there. It is just a more intense discipline than general
| programming which is why I'm perpetually drawn to it trying to
| find more real world applications. It is not exactly Prolog but
| close enough to mention the similarities.
| fuzztester wrote:
| cut.
| evgskv wrote:
| yes.
| WaterScorpion wrote:
| As someone who had the exceedingly rare opportunity to experience
| professional context Prolog.
|
| Lol.
|
| Lmao. Even.
| kamaal wrote:
| If you are struggling to get Prolog.
|
| Think about it this way. In a regular programming language you
| write code and then write unit test cases to validate it.
|
| In prolog, all you do is write the test cases and then its up to
| the compiler to write and run the code for you. In other words
| you define a set of cases for which a logic is supposed to hold
| true. The compiler then decides what the code must look like if
| that is the case.
|
| This might look easy for simple True/False kind of cases. But
| when you have to write test cases for functions that return
| deeply nested data structures and all their variations. Then it
| becomes easier said than done. The other part that makes Prolog
| hard to get, is you are only allowed recursion to iterate or
| define things. All of this makes it a little hard to think, write
| and trouble shoot Prolog.
|
| If you are reading Prolog code then try to think of it like you
| have access to a code repo's unit test cases, but the actual code
| doesn't exist. The test cases are considered sufficient enough to
| define the code in a concrete way.
|
| As you might have started to notice by now. This is actually
| harder than writing the code itself. In a regular programming
| language, you get sufficient space to write a function that might
| not do 100% of what was intended(bugs). Im prolog such an
| adventure will produce absolutely something else altogether.
| ristos wrote:
| Prolog is a really interesting language. It's like lisp in that,
| it's definitely worth learning very well, even if you don't find
| a use-case for it, because the things you learn help you think
| about programming in a whole new way.
|
| The prolog community is pretty active. SWI has a discourse group.
| There's SWISH, CLP(FD/Z), abduction via CHR (a rewrite system) or
| libraries like ACLP. Prolog is homoiconic, and it achieves it in
| a unique way, via things like functor/3 and =../2 rather than a
| macro system. There's growing interest in ISO-standard, pure,
| monotonic prolog for writing large, clean prolog codebases. SWI
| is the most mature prolog, but Scryer and Trealla are very active
| and ISO conformant. Trealla is quite embeddable, particularly in
| javascript codebases. There's also janus for python, and the
| community is looking to integrate prolog with LLMs.
|
| Prolog shines for writing bidirectional parsers, NLP, expert
| systems, abductive reasoning, and constraint logic programming.
| Pure monotonic prolog has some very useful properties in terms of
| debuggability, making it useful for large prolog programs.
| There's also some interesting work in developing pure io
| (library(pio)). Prolog also has a few different techniques for
| coroutining, including shift/reset. Markus Triska has a very nice
| youtube series and book on prolog that's worth watching/reading.
|
| The main downside to prolog is really just that there's a steep
| learning curve to it that puts a lot of people off and prevents
| it from gaining more traction, similar to why langs like lisp,
| haskell, and idris have trouble gaining traction. SWI has a lot
| of features, but it's also not ISO conformant, and a lot of
| libraries aren't portable and/or feel very procedural/imperative,
| which defeats the purpose of prolog. The useful libraries can
| often be ported to less popular prologs that are more promising,
| like scryer and trealla. For example, I managed to port ACLP to
| trealla yesterday without much effort, which is a pretty useful
| abductive system for writing expert systems or any sort of
| abductive reasoning.
| ristos wrote:
| You can also change the search strategy used in Prolog, ie
| using library(search), supporting BFS and iterative deepening.
| Tabling is also supported.
|
| Another useful tool for homoiconicity is clause/2:
|
| ?- assertz((foo(X) :- append(X, _, [1,2,3]))).
|
| true.
|
| ?- clause(foo(X), Body).
|
| Body = append(X, _, [1, 2, 3]).
|
| If you really like Haskell and OCaml's pattern matching, you'll
| probably really love Prolog. Prolog's pattern matching is much
| more powerful.
| pbronez wrote:
| Wish there was more discussion of Datalog here. That's come up in
| a few interesting places and I'd love to hear about folk's
| experience with it.
|
| https://en.wikipedia.org/wiki/Datalog
| fraber wrote:
| Prolog is very, very dead. I love Prolog with all my heart, but
| it excells at problems that are solved today much more
| efficiently using neuronal networks. So it's utterly obsolete.
|
| The issue of Prolog is that you need to code your rules manually.
| Doing ML with Prolog is possible, but very clumsy. Better stick
| to Python.
|
| Speed is irrelevant, because most problems suitable for Prolog
| are exponential. Implementation is irrelevant, because SWI-Prolog
| does all you need with good integrations, except that it's a bit
| slower. But that's irrelevant, see above.
|
| Learning Prolog is a great experience for any advanced computer
| science student. It amazes, doesn't it?
| gorkempacaci wrote:
| Prolog was never good at the things they thought it would be
| at, like AI, which is better done by ML today, specifically
| often like you said, with NNs. But it turned out to be good for
| other things, and those use cases are still alive today, even
| though there are many competitors. Look at Tiobe index,
| Prolog's usage is constant just under 1 percent, and has been
| for decades. So it's good for something.
| YeGoblynQueenne wrote:
| Here's what I'm doing with Prolog:
|
| https://github.com/stassa/louise
|
| Louise is a Meta-Interpretive Learning (MIL) system. MIL is like
| a second-order Prolog where first-order programs are learned from
| higher-order programs by Resolution. There's a long thread of
| literature on MIL going back to 2014 but it now seems we're
| starting to move towards applications, e.g. I'm doing a post-doc
| where I use MIL to learn autonomous behaviours for an agent that
| must guide a mobile robot in survey missions. Other colleagues
| are working on applications in biology. We're going slowly
| because there's very few of us but MIL is a powerful technique
| that extends the soundness and completeness of SLD-Resolution to
| induction, so I'm hopeful that good things will happen with a bit
| of elbow grease and a bit of patience.
___________________________________________________________________
(page generated 2024-07-19 23:15 UTC)