Amzi Prolog becomes open source

Looks like a standard case of "the source is OSS and you can use it for free if you build from source, but if you want pre-built binaries, you have to buy them from us". That's basically what Red Hat does with RHEL... you can get the source and build yourself, or you can buy RHEL binaries from them (for the sake of argument, for the moment lets forget about support and indemnification and all the 'other' stuff buying a subscription gets you).

Of course, one difference with RHEL is that there's a vibrant community of people who take the RHEL source and rebuild it and release things like CentOS. Presumably you could do the same kind of thing with the Amzi source, so long as you respect their trademarks and what-not.

  The very stable 9.x release of the software will remain as a supported commercial version.

I'd like to revisit prolog, I think it is an underused language in industry.

If SICStus went open source or free for academic use, I would probably use that in my research/courses over SWI Prolog. Mostly because of familiarity, performance, and compatibility reasons.

Frankly, SWI gets all the action. There are times where it isn't the most efficient Prolog, but the toolset you're going to get from AMZI is much more limited, and that in the end is going to be a bigger deal. Does AMZI have ODBC, CLP, CHR, and a web framework? Probably not. SWI has the biggest community, the largest built-in library, the most 3rd-party packages, and is the easiest to install. Everything else is basically tied for second place. Except Visual Prolog, which comes last. :)

It's kind of a shame, because my earliest exposure to Prolog was through AMZI; they had a nice Windows IDE you could try for free (30 minutes at a whack). I went through their "Nani Quest" tutorial and that gave me positive memories of Prolog that I revisited later.

Mercury is an interesting language, but not having a REPL is a huge problem for me. The language mixes in some good ideas from Haskell and Clean. The tutorial comes off as sort of condescending towards Prolog users and fans though. Having to furnish modes and effect types is a bit of a burden.

Allegro is a pretty compelling product, but when I want to do Prolog, I want to do Prolog. core.logic in Clojure seems like it would be more interesting to me, because Clojure is enough better than Common Lisp. I believe core.logic is based on miniKanren, which is also interesting.

The Prolog implementations I sometimes wish I knew more about are B-Prolog, YAP and XSB. But I don't really have the kinds of performance problems that would benefit from tabling or a more sophisticated compiler.

Also, having more open-source Prolog engines is a very good thing, both for the language and for the project itself. For the project, it's good because it makes it easier for a community to grow around it. Swi has benefited enormously from its popularity (Jan Wielemaker has commented on this occasionally). For the language, it's good because the more healthy Prolog communities we have, the more we can hope to get new people interested in the language.

Comparing to other Prologs (and Prologs-ish'es) the problem with having closed-source and only for-pay Prolog engines is mainly one of portability, which in the Prolog world is a bit shit (and that's a vast understatement).

Frex, I wrote my degree dissertation using Win-LPA Prolog in 2010-11. LPA is commercial and I don't have a licence anymore (I had a student one) so now I can't run my dissertation. I tried (and tried (and tried)) to make it work on Swi but failed (and failed (and failed))[1].

The problem is there are subtle differences between implementations that bite you in ways you never thought possible, and it's just aaaargh hard to get the same program running in the same way on two different Prologs.

Apparently the exception to this portability hell is Yap and Swi, who have worked together to maintain some compatibility with each other. I don't have experience of this myself (after getting burned I've stuck to Swi) but if Amzi open-sourcing their stuff also means they'll be more open to this sort of working with others, then that's really, really amazing news.

____________________________

[1] It's here: https://github.com/stassa/Gleemin But it will hurt you.

Also, graduate dissertation, 5 years ago: embarrassing.

My classmate used it for his master-degree paper, and I just want to know its status when AI is starting to really catch up these days.

Now I should probably recommend you to play a bit with both approaches and do the same myself.

So, if prolog has future, it probably is outside of AI research.

I would say, that verifying is one of the places where logic programming never went away. I.e if you ever wanted to write type checker of protocol verification, you might write an embedded prolog first.

Prolog and erlang are not the same, or even particularly similar. Some features (such as unification, which is what erlang uses, not assignment, with the = symbol) are present, and inspired by, prolog. But the underlying computational models aren't the same. Erlang is functional/concurrent/procedural (procedural meaning you write an explicit sequence of steps). Prolog is functional/declarative. You don't (normally) write explicit steps. Rather, you describe the solution you want to find, describe the configuration of a system (essentially propositions and axioms), and let prolog search for your solution. You can do a lot more than that with the operators (declaring order of execution, terminating early, etc.), but the underlying computational model is this search. You would not use them for the same domain.

You can because they're both turing complete and thus capable of expressing the same computations. You won't because erlang excels in its concurrency model (and performance with many concurrent processes), and prolog excels in its declarative/search model. I believe there are some other languages (Oz/Mozart?) that might be suitable if you want a hybrid of erlang's concurrency and prolog's declarative model.