It’s essentially Lisp “modernized” and made available for the JVM ecosystem. It seems to have gained its followers.
Perhaps some tight integration with one of the large ecosystems could help as well – Java perhaps, but tighter than the current a bridge – some kind of tight / binary interoperability, so one could seamlessly work in both environments – and java developers could easily gain access to the prolog paradigm.
I guess this would mean many kinds of deterministic calls (when using java in prolog) – but, some could be non-deterministic as well.
Perhaps Logtalk is a better fit for that … given its object-oriented flavor.
IMHO using a language that needs tail-call optimization and uses the JVM is to be done knowing that not all JVMs are created equal and doing tail-call optimization is not required. The problem is well noted and easy to find.
Just to clarify. .NET or more specifically the Microsoft CIL has the tail call opcode. I still don’t see a tail-call opcode in the JVM. This is not implying that a VM needs the tail-call opcode (goto is another possible means) but it does make it nicer for code analysis; when you see the tail-call opcode, you know what you get, when you see a goto, what does it mean?
The point is that when the JVM is used with code that should make use of tail-call optimization, you have to look more closely under the hood to make sure you are getting what you seek, while with other technologies it is standard; in other words just because tail-call optimization is something that is known and standard in many areas does not mean it is should be assumed to be there.
Sorry if what I wrote was interpreted that way. Yes a trampoline and a goto are different, I was just pointing out that sometimes in the complication of the code, in some cases a goto is used where other VMs have more specialized op-codes.
I don’t exactly understand the question (the word binary is cutting down on the options), but another possibility that exists with F# is Computation Expressions. Just because F# uses them, does not mean they can not be transplanted into another language.
Also related to computation expressions and used in F# for querying, is Query Expressions.
I understand that there are JVM languages such as Cjoure and Scala that seamlessly interoperate with Java.
For example, a class defined in scala can (seamlessly) subclass an imported java class. No need for bridge or wrapper code. I think Cjoure supports that as well.
However, using Cjoure and Scala code from Java is apparently more tricky since both languages have features that go much beyond Java.
I take you are aware of JPL: A bidirectional Prolog/Java interface but I will note it here for others that find this topic and are wondering about other options. This one regularly comes up in questions on StackOverflow, but AFAIK still works and is useful.
You can not subclass logic programming (Prolog) with Java
While it would be nice to access Prolog in Java via subclass, why such importance on this requirement?
I agree that it would be nice to have and beneficial for beginner programmers, but at what cost, e.g. do you lose features like constraints problem solving, and speed of computation. Also since I have not used Java with an SQL database in the last few decades, what is the current industry standard to access an SQL database using Java; does that use subclass?
I did use JAVA to access a No-SQL database last year and it used a custom protocol: Bolt but Neo4j can also be embedded in Java since Neo4j is written in Java, and also has a high level query language (Cypher) which can be used with the drivers.
The same motivation for making Scala and Clojure a JVM language – to seamlessly benefit from the immense Java ecosystem – could drive making Prolog a JVM language.
Note both Clojure and Scala are multi-paradigm language supporting Object Orientation as well as functional programming styles – i.e. the language designers found a way to seamlessly integrate these.
So, perhaps, one approach to make Prolog more used in industry is to define a multi-paradigm approach that seamlessly integrates with the JVM ecosystem.
The same goes for the .NET ecosystem – another ecosystem another ball game (F# – another multi-paradigm language – analogous to Scala).
Personally I am not a fan of multi-paradigm languages that bolt on features after the first major release. It makes the syntax harder to write and comprehend and often comes with work arounds that if you are not aware of allow you to quickly shoot yourself in the foot. I have a friend who, while just starting out by getting their degree in CS, is also a fan of JVM for the same reason and loves Clojure.
I introduced him to the Brick book (WorldCat) and he has been working through it over the summer and was surprised at some of the things it shed light on. If you get the book also get “An Introduction to Functional Programming Through Lambda Calculus” (WorldCat) as the Brick book starts from Lambda Calculus and works up.
Its quite possible that multi-paradigm is just a means to get acceptance (e.g. functional paradigm) in mainstream (OO paradigm) – but, then, it does help get acceptance in mainstream … which has all the benefits that come with it …
Functional programming was quite a niche, and now its gaining a lot of acceptance - possibly overtaking object-orientation, with its immutable paradigm in highly scalable systems (e.g. via domain driven development).
The route to consider Prolog a dedicated sub language for solving particular problems has been explored quite a bit. Amzi! is probably one of the most famous examples and we have seen various Prolog systems written in other frameworks, notably for the JVM. I guess some of them had some success but all in all I have the impression this didn’t make the difference. Embedding Prolog in XYZ comes with the object-relational impedance mismatch as described for RDBMS systems, made worse by logical variables that are hard to deal with and the existence of untyped structured data (compounds). As a result, your application typically looks clumsy and if the interface involves strings representing Prolog concepts (many do) typically software that is hard to validate and subject to injection attacks.
The funny thing is that the other way around it works much better. Prolog has no mismatch with relational data, nor with OO systems, graph query languages, hierarchical data (XML), etc. Embedding Java/Python/C(++)/… in Prolog also provides access to their eco system. At the same time it is a replacement for the not so uncommon approach to embed compiled languages in a more flexible framework for developing the overall application. Think Lua. JavaScript, but also R, NumPy, etc. Technically this works fine, but convincing people is hard.
Best embedded language is typically C(++) or other languages with a minimal runtime system. Syncing the will to control the environment that applies to high level languages such as Java/Python/Prolog is hard (garbage collection, threads, signals, etc).
My industry experience (outside support to others, mainly in working for startups, which are a world of its own…) is limited compared with other contributors in this forum but I’m happy to share some highlights of that experience. For context, most of my contracts are for Logtalk coding using selected Prolog compilers.
Working on an environment where logic programming is a part of a solution that uses other languages and their ecosystems, some of the concerns from non-Dilbertian pointy haired bosses are:
Installation. How easy is to build into a container, can the installation be performed unattended? Can the sanity of the installation being automatically tested? What’s the coverage? Can it be instrumented easily from whatever build systems the company is using?
Reliability. Saying that “others use it and they seem happy” doesn’t cut it. Is the development process sensible? Are stable versions available? What’s the development cycle? Are commit messages readable? How are builds tested? What’s the mean time for answering bug reports?
Community. Is it friendly? What documentation and learning resources are available? How easy is to hire capable human resources?
Developer tools. Can we write, test, document, diagram, debug, … the code that we’re going to write? Can testing and documenting be automated (think CI/CD) How do we evaluate our engineers work? Can we apply standard metrics? How easy will be for new hires to get up to speed?
There are certainly other concerns but anyone in industry will be familiar with the questions above and likely answered them multiple times to justify the use of logic programming solutions in their workplace. These kind of questions also should make it abundantly clear the direction of Logtalk, SWI-Prolog, …, development. We want logic programming to be increasingly used in industry? We need to keep working in providing the best possible answers to these and similar questions.
Notice that there’s no mention of language features above (e.g. logical variables, homoiconicity , tabling, threads, objects, constraints, web frameworks, …). While those features are often the main reason logic programming is under consideration, a mature, well supported ecosystem is also key and often a deciding factor. YMMV of course. Just my two cents.
In a nutshell, by using the full Logtalk ecosystem, notably its developer tools (https://logtalk.org/tools.html), running on reliable and well supported Prolog systems (notably, but not exclusively, SWI-Prolog).
An example is full support for automated testing in CI servers complying with industry standards such as xUnit and TAP and generating detailed reports, including code coverage reports at the clause level (e.g. https://logtalk.org/diagrams/coverage_report.html).
Another example is generating both API documentation and application diagrams at several abstraction levels where you can use the diagrams no navigate to both code and documentation in order to better understand, discuss, review code bases (a simple example is https://logtalk.org/library/tools_inheritance_diagram.svg).
Yet another example that makes a difference in writing quality code is the linter (https://logtalk.org/tools.html#lint-checker), which catches a good number of issues that most Prolog compilers will let pass silently (recently, SICStus Prolog SPIDER IDE also does a good job here; SWI-Prolog native editor is also to report a number of issues).
But the key point for this discussion is that you use all of this with a Prolog system (taking full advantage of its features and strengths), not instead of a Prolog system.
One of the interesting applications is the Bayesian (probabilistic) programming, in which ProbLog goes. See their GitHub repository. And DARPA working with the industry funding and nudging the research of probabilistic programming systems. For example there are attempts to combine deep learning with the Prolog systems. Another potent application of such logic is computational biology, e.g. genomics.
I use prolog now for many years in commercial applications. Prolog is very much suited for parsing data or parsing other languages ( natural and computer ), and is also very good in generating code for other languages, for example to javascript. We use swi-prolog in a web-service with the swi-prolog web server. I use also prolog for generating graphs in Javascript canvas.
