I have a question that I have often wanted to ask of someone that knows something about declarative programming. In my day job, I spend most of my time worrying about trying to make my code run faster (I do low-level user-interface work - building the libraries that application UIs then use, so it's all about moving pixels as fast as possible, getting data to the app as fast as possible etc. If I need to make a SW blit run faster, I go into the function doing the blit, and I may replace some of the C code with some SSE-style vectorised assembler. Or I may choose to run an expensive SQL query once a day, storing the result in a binary file that is then used to feed application data requests, or other things of that nature.
I just don't see how those kinds of optimisations could be done in a declarative language. Do I just have an unusual use-case, or are these languages seriously constrained with respect to the types of programs that they can be used for?
The right tool for the job. I wouldn't try to cut a piece of wood to length by using a hammer.
Declarative languages tend to lend themselves to being used at a much higher level, for example easily encoding rules regarding salary payments rather than low level bit twiddling.
We used tuProlog for rule-based intelligent agents in several applications and it worked pretty well, but its poor performance eventually led us to look for alternative implementations. That was about five years ago, though, and perhaps it has improved.
Nice to see SOMEONE mentioned its use in rule-based AI. I find it rather confusing how everyone only mentions its use in NLP and harldy ever AI. Anyone care to comment on it?
For anyone interested in Prolog the usual book recommendations are:
"Programming Prolog" (Mellish & Clocksin), "The Art of Prolog" (as a first/second book), "The Craft of Prolog" (as an advanced book for later)
I don't own the first one but "Art of Prolog" was a little over my head when I got it (maybe I'm not that smart) and the typical "family database" examples are kind of tedious. I've worked through a couple of books now and the first book I'd recommend these days is "Prolog Programming for Artificial Intelligence". Don't let the AI in the title distract you, Part 1 is a very good introduction to Prolog (the best I'm aware of) and Part 2 covers typical AI topics (also very interesting of course).
I really like Mercury[1] so good to see anything Prolog up here. Prolog was the first language I learnt from a theoretical point of view (first learning the in depth language theory before writing a line of code) at university and I have always liked it since.
I try to create things with Mercury but it's so fresh that it's rather hard; almost no-one is using it so when something goes wrong (which it will do when trying to do real-life stuff and linking libraries to do) there are not many people to ask and the people who are working with it are rather busy.
Anyway; Prolog is a nice language for some use cases; try it.
The Prolog class I took in college wound up being one of my favorite classes (although I was alone on that amongst all of my friends).
I always liked the idea of declarative programming, it felt very natural when I first learned about it. That being said, I didn't have much use for Prolog after finishing that class. (I wrote one fairly small application at my first job, but really nothing else).
I think that if you're interested by any of the recent developments around the Kanrens (or Core.Logic if you're a Clojure programmer), you'll find yourself better served by at least having a passing familiarity with Prolog.
I also find that SQL feels to me quite a bit like Prolog (you have to sort of squint), and I find myself liking writing SQL way more than you're apparently supposed to from how much people complain about it online. That might have nothing to do with having learned Prolog, maybe my brain is just wired wrong.
> I also find that SQL feels to me quite a bit like Prolog (you have to sort of squint), and I find myself liking writing SQL way more than you're apparently supposed to from how much people complain about it online. That might have nothing to do with having learned Prolog, maybe my brain is just wired wrong.
It's not just you. I'm in the process of writing "Euclid's Elements in SQL". It can be a beautiful thing if you think in relations, rather than tables.
Prolog was on my list of "neat to learn languages" but I never got around to it.
Any Prolog fans here to sing its praises?
It's very well fit for writing computational grammars for natural language and parsers/generators. I have used it a lot during my PhD. Terms can be used to represent attribute-value structures and e.g. agreement can be checked and larger structures can be formed through term unification.
Interesting, I'm working on a project that uses rules based agents but I am actually going to use ANTLR4 instead of Prolog for the grammar/parsing.
It feels very odd because this is supposed to be one of Prolog's strengths. Basically what I do is generate Prolog code (via ANTLR) from a rule description of an agent (a custom DSL).
My main motivation (outside of ANTLR seems neat, I want to play with it) is that I might eventually generate non-Prolog code from the DSL-code.
Let me sing half a praise: I learned Prolog at university through three courses and learned to love it for a certain set of problems. Everything with multiple outcomes or things that map well to descriptions trough constraints are very easy in prolog. Conceptually, it is well removed from other languages and therefore worthwhile learning. Prolog naturally teaches you interesting approaches to work with data. Writing parts of my software in Prolog is still an option for me.
Practically, though, it suffers from real world problems: there are quite a few of runtime systems, dropping in and out of maintenance every once in a while. Lots of things are semi-standard, for example each runtime ships with a constraint library with different behavior. (e.g. in one Prolog, applying a constraint to a variable that already has a value is an error, in others, it is allowed if the variable satisfies the constraint). Prolog is really more a family of languages, sharing a similar syntax.
We use Prolog extensively at RainBird - I could definitely be considered a fan!
As always it's about using the right tool for the job. Prolog is a great choice for many symbolic type problems. We use it as the basis of our knowledge representation and inference platform.
Prolog is often considered too slow for production use. Again this depends on how you're using it, use it for solving the right kind of problems and it's quick. Very quick. Using multithreaded SWI-Prolog and it's C++ foreign language interface we're able to reason over large data sets with hundreds of thousands of concepts very quickly indeed.
Another common misconception is that you need to be a logician with a background in formal logic to work with Prolog. You don't. You need to get your head round declarative programming, which can take a while if you're not used to it. It's worth the effort though, even just so you've got a new technique for your toolbox.
Some solutions are very elegant and intuitive. It's probably the right tool for a number of jobs and the wrong one obviously for others.
When you get pretty far into it, you start to get into several real-world realities. First is side effects. You have to decide how pure you want to be.
Another question is efficiency. The first few chapters of most books will be about look how cool this stuff is. Then much of the rest will be exposing inner workings so you can word your solution to skirt problems or give the interpreter hints. Red and green cuts come to mind.
One thing I'd really like to know is how well can the unification algorithm be split across multiple cores/processors.
Erlang takes many features from Prolog, such as the syntax, and also solves a number of questions such as side effects and distribution, but I'm pretty sure they've omitted the unifier. It might be neat that was in there too.
Personally I think Prolog is excellent for anything that can be thought of in rules and it's obviously strong in constraint solving situations.
Most Prologs I have used are lacking in what I'd call "plumbing". I/O in particular feels fairly strange, web libraries etc. are low level (no MVC framework I'm aware of).
A combination of Java and Prolog works quite well (technically any JVM language I suppose). Most Prologs provide a good Java connector (they usually also have C/C++, sometimes .NET and Python + sockets). Tomcat+JavaScript+HTML+CSS+database of choice and Prolog for the logic is a good combination.
Go for it if you'd like to learn a natural language.
Nothing worked for me as well as making a basic French language grammar parser. It is beautiful to throw some rules at it and then get the number of sentences I can construct out.
i see no mention of a C ABI interface - this is the one truly cross platform interface we have which has no prior dependency, and it is at the native level.
it utterly boggles my mind how this is not the first thing mentioned or used. maybe it is just in there anyway and i need to find out. will definitely take a look at this as a fan of prolog anyway. :)
tuProlog does not offer an interface directly to C code. It's implemented in Java and does provide a decent interface to Java code. I suppose you could develop a JNI interface to your C library code, and then interface tuProlog with that, but that's admittedly a complicated approach.
I just don't see how those kinds of optimisations could be done in a declarative language. Do I just have an unusual use-case, or are these languages seriously constrained with respect to the types of programs that they can be used for?