What @nicos is suggesting makes loads of sense to me, since it seems to reproduce the structure of successful longer-term open-source efforts. Of course the question is whether these groups of 2-3 people exist. I’d love to volunteer but I don’t have sufficient knowledge of programming language design to be of much help. Perhaps one could help with some of the libraries?
It’s funny (or a little sad) but I’ve always tried to use as few of the Swi-specific libraries as possible exactly for the reason that I’m not sure that my code will still run after 40 years, if I do. I’ve already basically lost the ability to run all the Prolog code I wrote in 2011 for my undergraduate dissertation, which was written for the proprietary Win LPA compiler. I’m always worried that using any advanced features of any particular Prolog implementation will only hurt the portability of my code somewhere down the line.
But I’m heartened by the news that there are trams in Amsterdam. Dr. Wielemaker is tougher than a tram.
(I’m trying to start a meme :).
3 Likes
In my discussions with Paulo Moura he explained that one key motivation for Logtalk is portability, so that one can use its libraries and thereby seamlessly use any of the support “backend” Prolog systems.
If future existence of a Prolog is a key stake, then Logtalk could be a good choice. But, then again, its also maintained by one person … but, it does change the nature of what needs to be maintained – a VM or libraries and preprocessor code.
Dan
I seriously investigated writing a book along these lines last fall. Ultimately, the financial reward wouldn’t have been enough to cover my living expenses while writing it.
It still might happen - I’m approaching retirement age, and at some point might decide to do it as a retirement project.
5 Likes
I have been wondering about LogTalk. Yes that too is one individual, but then we would at least have two, however disjoint, individuals 
It’s an issue in part because Prolog is that rare language that has somehow survived despite its not being taken up much by US academics and US tech companies, vs its relative popularity in Latin America and Europe. (From where I sit it seems that the role of deviant academic programming language in the US is Haskell.) It’s interesting from a “sociological” perspective, and suggests that perhaps its survival might require some support from, say, EU institutions. Has this been tried?
What I mean is this: SWI Prolog could be designated as a European technology project that is clearly valuable, and therefore needs some support, perhaps to fund postdoc positions and its promotion in universities and startups. The French through INRIA do this sort of thing, and hey, the language is originally French
It would be just amazing if you were to write that book. I get that the book itself isn’t terribly likely to provide the necessary financial return, but I wonder if one couldn’t rig up a kickstarter-like campaign to provide the funding?
1 Like
I had a little revealing experience some time ago:
I wanted to port some Prolog code C – and I immediately noticed how much harder it is to express in C ideas clearly using its data structures and code.
After Prolog i felt like I fell down a few levels in an elevator – to a bottom floor.
Ultimately, what is most compelling in language choice – is programmer productivity – I wonder how Prolog could be positioned very competitively as a productive language for small to medium sized development shops – which are the workhorses (i think) of the (European) economy.
Dan
Looks more that if either of the two is hit by a van you have a problem 
Logtalk is great if your Prolog needs are basic. It provides a portable library and a portable code reuse and encapsulation system that is more advanced than what any Prolog system offers.
If your Prolog needs include the stuff from SWI-Prolog that you do not find elsewhere or not in the combination you need it (e.g., unbounded integers and tabling with well founded semantics) you are in the “either one hit by a van” position. Note that Logtalk provides only pure Prolog libraries. If you depend on such libraries from SWI-Prolog you can port them along with your system as the BSD license allows for this. Most of these good old libraries are anyway around in most systems and/or are easily ported as their origin is typically from the 80s and 90s, predating lots of interesting developments
Interesting thought. Something to keep in mind and if anyone has concrete leads to make this work, please share. On the other hand, development was for over 30 years in academic. I think we can get enough commercial stakeholders together to keep it afloat in a sustainable way that doesn’t depend on a single individual. The system is pretty mature and there is quickly growing commercial interest. Let us go for it!
Do you think on something like Pharo Smalltalk did on INRIA (-> Stephane Ducasse for example as one leader and prof.)?
Cheers
Hans
Yes, I totally agree. Recently I resolved: this year I will learn an up-and-coming language. I chose Rust. Within minutes I felt depressed: you have to actually compile the program and run it at the command line. Your program now is this blobby thing, lying on your filesystem, which you invoke over a data file. It’s all so archaic: you can’t talk to the system, interactively.
Two of my best NLP professors in grad school, when pressed on which platform they preferred to work on (as they taught courses in Python), eventually admitted: Prolog. One American, the other at Oxford.
The two main complaints by those who have tried to use Prolog at scale are:
- Speed. This is of course a real issue. “It’s kinda slow”, shrugged one of those profs ^.
- Tangled programs, unmaintainably complex logic, so that debugging or even understanding what’s going on becomes impossible. My view about this is as long as one doesn’t dynamically assert/retract, and religiously maintains a growing set of unit tests, the great power of the language – which leads to the complex logic of programs – is manageable. Doing so is appropriate for concurrency in any case.
I suspect the ship has sailed in the US. I agree that European small/mid dev shops could well be the commercial target.
One feature that could help a lot is an interactive jupyter-like tool. Does something exist? I know about PlDoc, but I understand it’s not interactive?
2 Likes
Quoting that because hopefully someday it will be at the start of a chapter in a book.
Have you seen SWISH?
This site has Useful Prolog references and many other such items in the categories
Wiki
Useful Code
Nice to know
Announce
Resources
Is there is something you think is missing the Wiki topics are just that Wiki so edit away.
This is an interesting discussion. I love the Prolog.I have wanted to start a project on Prolog many times.Every time I missed the little things. I cannot work normally with the DBMS. Of course I can use ODBC, but this is a bad way in 2021. There are always not enough little things, there is no time to do everything yourself. I would like to take ready-made blocks and connect them, I cannot be distracted from the main task.I sigh every time and choose the language in which I will do my task quickly.Now I am writing in Erlang, but I hope to do something in Prolog
It would be good to learn about those little things and then address at least some of them, to reduce the friction in getting up and running.
Perhaps ODBC is out-dated, or perhaps it can be improved significantly, so it just works with one or a few lines of code that can be copied and pasted.
Various databases these days seem to have a REST interface - perhaps that’s the way to go.
Dan
I think Prolog’s speed comes down to three things:
-
Knowledge how to program it succinctly – speed is often a matter of how the solution is expressed. From what I understand Prolog can be close to C, when done right.
-
the ability to cache solved goals – i.e. tabling – thereby avoid computation (at the cost of memory)
-
Prologs inherent hash-based / indexed access to facts – while other languages offer approaches, including pointers, arrays, and i guess optimized matrices (tensors).
However, for many enterprise application I suspect that the hash-based access is not a bottleneck.
I think, it would be great to understand what drives development language and environment choice in development shops.
I would suspect that one is the customer existing environment they are working into – often, its based on buy-in of cloud providers – e.g. MSFT Azure, Google Cloud or Amazon AWS.
And, then there are the secondary development environments that come with it - e.g. the .NET ecosystem, or more open systems with Amazon and Google – usually, aligned with mainstream languages.
I guess, if swi-prolog could support for those ecosystems that would be a significant step towards adoption.
Dan
I think with a module system, and perhaps somewhat better support for interface (e.g. enforcing public / private) – code complexity can be managed.
for example i want to be able to access postgree via postgresql wire protocol. I want to have a pool of connections.
Some companies have a tool to post features and then have users vote on them – perhaps this is what is needed here as well.
That is of course true, but holds equally for many other high level languages. I’m working on a ROS2 interface and some first tests indicates it is 4 times faster dealing with ROS2 services than the Python library. Both are partly written in C and partly in Prolog (Python), using about the same level of abstraction at the C level (as I get most of my inspiration about how to use the low-level ROS libraries from the (ROS Client Library for Python). Once it becomes possible to write more serious things in the SWI-Polog ROS2 bridge I plan to investigate this in more detail.
And we should not forget that SWI-Prolog it truly multi-threaded, scaling pretty well with the number of cores you have. This in contrast with Python, JavaScript, etc. If you have mostly I/O tasks, the model used by these languages are fine. If you want to provide CPU intensive services with many clients, SWI-Prolog does a good job.
7 Likes
And even the cyclists are tough as nails. I was on a tram that tangled with a cyclists. The poor tram driver looked the worse for wear [shock] the cyclists walked away. their cycle might have needed more work. But back on topic. It is a real issue. It doesn’t need an incident per se. I was rolling along nicely running my department then one night got taken out by a stroke. Fortunately by design others had enough expertise and familiarity with the system to keep the show on the road,
Might be worth looking around for examples of good practice. Members of The Squeak [Smalltalk] community put out a set of books that explain the internals and how to use them. There are also the classic beige “Addison Wesley” texts including “Bits of History, Words of Advise”.
Explanation of the source has been suggested. A model here might be “A Model Implementation of Standard Pascal” by Jim Welsh and Athol Hay that sets out a full implementation of Pascal using Knuth’s Literate programming paradigm.
The GHC[Haskell] community has a steering board of volunteer contributors who are helping plan
evolution whilst providing a central pool of expertise on the compiler and libraries…
One concern might be to separate the specification of what components of the implementation
must do from the details of how they do it.
I agree that it could be an invaluable community resource: information on how to implement a good Prolog system is distributed in a small number of books [e.g… Tick, Warren], numerous papers and in the heads of people who will one day retire
Finding funding is more difficult - appealing to the self-interests of commercial users sounds good
in principle, but I suspect they would be ore willing to contribute if there was evidence if
other support. is this some thig where W3C or ERCIM might help…?
I have modest familiarity with SWI, Prolog generally , time on my hands through early retirement
Happy to chip in effort if there is anyway that I can assist.
bw
David.
1 Like