Again it's probably my limited scope on the topic that brings me to such conclusions.
I gave a check to the ARC project and it seems like a great challenge (from the standpoint of proactiveness).
What i might not understand is how could a challenge defined like so "AGI is a system that can efficiently acquire new skills outside of its training data." be possible. My mind goes to deep learning, to RNNs, to something that does online training but then again i think that after a while, learning on it's own, wouldn't it introduce noise into it's system? in my mind (again, ignorance speaking here) online training requires some sort of back propagation, some sort of learning on it's own from it's own. The acquisition of new skills must come from either itself or an agent's surrounding environment... i just can't see how this whole system could be stable
I started doing some side activities (gym, theater, creative writing) etc but haven't taken time of in... years? (i use my PTO from work to study for uni exams)...
I also lift, and I've written and published some fiction that's basically Hawkmoon on a Harley, but when I get as burned out as you seem to be, I can't do anything resembling intellectual or creative work.
Or, rather, I can, but just slowly and half-assed.
It sounds like you need at least a weekend where you do absolutely nothing, like post-hypnotic Peter Gibbons in Mike Judge's 1999 accidental documentary Office Space. Just sleep. It sounds like you're worn the hell out.
It also sounds like you're killing yourself to live.
I should think about it soon enough... exam season is closer than ever... shit i do wish to go on top of a mountain and never come back doe... Kaczynski style (with less bombs)
No bombs, of course, because while a bullet can have your name on it, AOE damage is addressed "to whom it may concern" and I don't want to hurt some poor schmuck who didn't have it coming. Though if a Republican annoys me I might mail them some Anthrax albums. See what they make of Persistence of Time or Among the Living.
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)
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)
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.
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?
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."
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:
>> 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 SWI-Prolog discourse thread linked above this is pointed out to Jan Wielemaker who clarifies it was a mistake. He then repeats the benchmark comparing a newer version of Scryer to SWI and finds that Scryer has improved significantly:
Updated Scryer Prolog to 0.9.3. They made serious progress. Congrats! The queens_clpfd.pl and the sieve.pl benchmarks have been added. The ISO predicates number/1 and retractall/1 have been added. I had to made more changes to to get the code loaded. Creating a module with the programs and some support predicates somehow did not work anymore (predicates became invisible). Loading a file programs.pl from directory holding a subdirectory programs silently loaded nothing until I added the .pl suffix. The sieve bar is cut at 20, but the actual value is 359.
> 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.
> 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?
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.
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.
> 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.
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.
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
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
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)
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.
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.
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.
