3 ms·

I think you're right. The promise of Prolog was that you'd be able to just define the task requirements, then write the requirements in Prolog and magic would

I think you're right. The promise of Prolog was that you'd be able to just define the task requirements, then write the requirements in Prolog and magic would happen. But even the most experienced Prolog coders I know don't really think in Prolog. When faced with a coding task, they inevitably first (mentally) figure out the problem in an imperative form, perhaps with some recursion, and then they they ask themselves "okay, how do I convert that to logic and pattern-matching?" If you're going to go through that process, then Prolog provides no value: it's just an extra step, and you might as well code in C (okay, Lisp). I fear that Haskell will turn out the same way. After all monads are just monoids in the category of endofunctors, right?

nv-vn 9y ago
This is really dependent on the programmers background and what they're writing. Some code is super easy to write in Prolog and much harder in any other languages. Take type inference algorithms for example. Rather than describing how to solve it, you just translate the typing rules directly to Prolog clauses. Thinking about imperative problems is hard in Prolog and will make you think backwards. Thinking about logic problems in C is the same way.
- zmonx 9y ago
  I second this. When writing Prolog programs, the more you think procedurally, the more specific your programs will become in the sense that you can then typically only use them in specific directions. To make your Prolog code as general as you can, I recommend to also think in terms of relations. This definitely takes effort, which pays off in the increased generality.
mst 9y ago
Interesting - I know a number of people who think in prolog, and when faced with a task that it's well suited for I often mentally figure out the problem in prolog form, and then ask myself "okay, how do I convert that to normal code?" Happens with lisp as well - I barely ever write prolog or lisp but I regularly think in them first before writing the solution in another language.
mabbo 9y ago
I suspect that very experienced Prolog developers 'grok' it. They get it, they think in it. Whether that's due to a lot of hours of practice in it, or just having a brain that works in a way that Prolog makes more sense, I'm not certain.

nv-vn 9y ago

This is really dependent on the programmers background and what they're writing. Some code is super easy to write in Prolog and much harder in any other languages. Take type inference algorithms for example. Rather than describing how to solve it, you just translate the typing rules directly to Prolog clauses. Thinking about imperative problems is hard in Prolog and will make you think backwards. Thinking about logic problems in C is the same way.

zmonx 9y ago
I second this. When writing Prolog programs, the more you think procedurally, the more specific your programs will become in the sense that you can then typically only use them in specific directions. To make your Prolog code as general as you can, I recommend to also think in terms of relations. This definitely takes effort, which pays off in the increased generality.

mst 9y ago

Interesting - I know a number of people who think in prolog, and when faced with a task that it's well suited for I often mentally figure out the problem in prolog form, and then ask myself "okay, how do I convert that to normal code?" Happens with lisp as well - I barely ever write prolog or lisp but I regularly think in them first before writing the solution in another language.

mabbo 9y ago

I suspect that very experienced Prolog developers 'grok' it. They get it, they think in it. Whether that's due to a lot of hours of practice in it, or just having a brain that works in a way that Prolog makes more sense, I'm not certain.