I think Prolog suffers from the Lisp-curse (Prolog-curse?): any perceived imperfection isn't seen as one, because the gurus can just hack a meta-interpreter in no time (and they are right, I have never come across a more meta-programmable language).
This has led to a zillion libraries doing things that instead should have been standardized at the language level. There are prolog variants with function calls and many modernizations (e.g. Ciao prolog), but they are not widely agreed upon.
In the same vein, Prolog can be typed very easily, but this has been done through libraries (meta-interpreters again), that are fragile and not well-documented. The same goes for typing of the modes of predicates. Here the curse of the symbolic terms (which I think are great, btw.) hits again, because there is no standard as to how to specify types.
Picat is a wonderful language, but, alas, it lacks the metaprogrammability that makes Prolog to interesting. I don't think without metaprogrammability it will ever be able to take Prolog's place.
Another "curse" of Prolog is that SLD resolution over Horn clauses is just on the threshold of what is still computable in linear time.
Even small changes, such as interpretation of the clauses under stable model semantics, lead to an NP-complete problem. So, while Answer Set Programming is very appealing for many applications, it can't form the basis of a general-purpose programming language. And I am not even speaking about λProlog.
From a complexity point of view, we will never get a more powerful Prolog2 that could realistically solve what Prolog can't.
I love Prolog, I think it is an awesome language, but I also share your gripes. One of the main issues is that, because I need to leave my regular programming environment, I very rarely think about problems the way I would think about programming in Prolog.
In my opinion, we need:
a stronger integration of Prolog into other languages. Janus Prolog is a good start. Ultimately, I would love to see a tight integration, like what LINQ did. I know that the Prolog gurus will strongly disagree, but I don't think using Prolog as the main language is the right approach.
de-crufting of Prolog, and moving towards a more declarative approach. Markus Triska's approach is refreshing.
integration of specific solvers for higher order logic, ASP etc. s(CASP) is already tightly integrated with Prolog. Similarly, using other solvers, SMB, SMT, need to be a bit smoother, and well-documented.
it irks me a bit that we have a split between logic programming, and solvers for logic programming problems (such as OR or SMT), the latter which are typically written in C++. I would love to better understand what logic programming is lacking to be considered here.
similarly, a Prolog engine would be a perfect addition to anything where backtracking is needed. Attributed variables, https://www.metalevel.at/prolog/attributedvariables , are incredibly powerful as the attributes are automatically sync'ed with the search state. Building such a system by hand is extremely error prone. This integration is what makes it possible to seamlessly integrate constraints into Prolog.
Unfortunately, there is disagreement in the community as to which solution is best, this has ultimately led to the creation of Scryer Prolog. Details are here: https://github.com/SWI-Prolog/roadmap/issues/14
I think Prolog suffers from the Lisp-curse (Prolog-curse?): any perceived imperfection isn't seen as one, because the gurus can just hack a meta-interpreter in no time (and they are right, I have never come across a more meta-programmable language).
This has led to a zillion libraries doing things that instead should have been standardized at the language level. There are prolog variants with function calls and many modernizations (e.g. Ciao prolog), but they are not widely agreed upon.
In the same vein, Prolog can be typed very easily, but this has been done through libraries (meta-interpreters again), that are fragile and not well-documented. The same goes for typing of the modes of predicates. Here the curse of the symbolic terms (which I think are great, btw.) hits again, because there is no standard as to how to specify types.
Picat is a wonderful language, but, alas, it lacks the metaprogrammability that makes Prolog to interesting. I don't think without metaprogrammability it will ever be able to take Prolog's place.
Another "curse" of Prolog is that SLD resolution over Horn clauses is just on the threshold of what is still computable in linear time.
Even small changes, such as interpretation of the clauses under stable model semantics, lead to an NP-complete problem. So, while Answer Set Programming is very appealing for many applications, it can't form the basis of a general-purpose programming language. And I am not even speaking about λProlog.
From a complexity point of view, we will never get a more powerful Prolog2 that could realistically solve what Prolog can't.
I love Prolog, I think it is an awesome language, but I also share your gripes. One of the main issues is that, because I need to leave my regular programming environment, I very rarely think about problems the way I would think about programming in Prolog.
In my opinion, we need:
a stronger integration of Prolog into other languages. Janus Prolog is a good start. Ultimately, I would love to see a tight integration, like what LINQ did. I know that the Prolog gurus will strongly disagree, but I don't think using Prolog as the main language is the right approach.
de-crufting of Prolog, and moving towards a more declarative approach. Markus Triska's approach is refreshing.
integration of specific solvers for higher order logic, ASP etc. s(CASP) is already tightly integrated with Prolog. Similarly, using other solvers, SMB, SMT, need to be a bit smoother, and well-documented.
it irks me a bit that we have a split between logic programming, and solvers for logic programming problems (such as OR or SMT), the latter which are typically written in C++. I would love to better understand what logic programming is lacking to be considered here.
similarly, a Prolog engine would be a perfect addition to anything where backtracking is needed. Attributed variables, https://www.metalevel.at/prolog/attributedvariables , are incredibly powerful as the attributes are automatically sync'ed with the search state. Building such a system by hand is extremely error prone. This integration is what makes it possible to seamlessly integrate constraints into Prolog.
Unfortunately, there is disagreement in the community as to which solution is best, this has ultimately led to the creation of Scryer Prolog. Details are here: https://github.com/SWI-Prolog/roadmap/issues/14