I disagree with
The SWI-Prolog web framework (obviously) does not replace the OS.
As the same SWI-Prolog program performs right on Linux,OSX,Windows (Android, near future) it could replace the OS, at UX level.
|Did you know ...||Search Documentation:|
|Can I replace a LAMP stack with SWI-Prolog?|
Yes, you can, and you'll be happier for it.
LAMP is short for the following open source components to realise a web server:
In this picture, Linux provides the OS, Apache the web server, MySQL the database and PHP server-side scripting facilities. In fact, most of these components can be replaced. One can replace Linux with almost any other OS, Apache with Nginx, MySQL with PostgreSQL. PHP is similar to ASP.
There are also larger replacements of this stack, such as Tomcat, which replaces both Apache and PHP. Similar architectures are available for Python (django), Ruby (Ruby on Rails) etc. As we will see below, this is the picture into which SWI-Prolog fits.
The SWI-Prolog web framework (obviously) does not replace the OS. It does replace Apache, PHP and to some extent MySQL. We could refer to the stack as LP (Linux Prolog). Below, we point at the various libraries that make up the stack and relate them to the LAMP components they replace.
The core web services are provided by the following libraries
For development purposes, there are the following support libraries
The previous section provides a basic web server that can serve static
pages from the filesystem and optionally does authentication, session
management, logging and error handling, i.e., Apache 0.1. The
library(http/http_dispatch) binds HTTP locations to Prolog predicates
that need to write a document to the
current_output stream using the
CGI conventions, i.e., write the header followed by two blank lines and
the content. There are two high level libraries for generating dynamic
pages. None of them relates directly to PHP, but we consider that a
Anne Ogborn has written a good tutorial on how to use the SWI-Prolog web framework.
There are several replacements for MySQL, depending on
The alternatives are
Services can be developed simply by running your application on your laptop or desktop and directing your browser to http://localhost:<port> as long as you use relative HTTP locations, preferably computed by http_link_to_id/3 which computes an HREF based on the referenced predicate on the local server and parameters. When ready for testing, you can run the web server in a terminal and use an Apache proxy to make it publically accessible from port 80. If problems occur, you can insert debugging statements, trace the program, fix it and reload the source without shutting down the server. If all runs cleanly, there is this library and accompanying (Debian) Linux init script for production:
The above assumes a single process server. What if one needs more power or wishes to split responsibilities over multiple servers? Obviously, you can use an external load balancing system to distribute the traffic over multiple Prolog servers. SWI-Prolog's session management is ready to deal with the Apache server load balancing facility to keep sessions on the same server. What if you want the servers to communicate?
Why would one choose the SWI-Prolog web programming framework over LAMP, Tomcat, Django, Ruby-on-rails, etc.?
It is difficult to see principal technical disadvantages in the LP framework. The main weakness of Prolog are algorithms that require destructive assignment, intensive array processing or bare-metal performance for e.g., processing pixels. Such requirements are rare in the context of web programming. If necessary, such requirements can be fulfilled using C/C++ plugins.
There is a weakness in scalability and robustness. Both are mostly related to a small user basis and thus limited testing. Notably dealing with unexpected high loads and DDoS attacks is not ironed out. This can be remedied by using a proxy server that implements state-of-the-art DDoS defence techniques, load regulation and load balancing. Slightly more fundamental is that each request is processed by a Prolog thread. This is also the case in Apache, but server architectures that aim at really high traffic such as nginx process many requests using I/O multiplexing.
Our final problem is the lack of masses of Prolog programmers one can easily hire. Running critical Prolog applications is possible if you invest time to become part of the Prolog community. You will get answers to your questions and you will be able to hire someone to solve a problem for you.