Hacker News Reader

Comment by usgroup | Hacker News Reader

In my opinion, if you are after the mystical experience of understanding functional programming, you're better off learning Prolog. I think it has more to offer in terms of insight, because wrapping your head around the language only takes a couple days, but wrapping your head around its consequences is a gift which keeps on giving for quite some time.

Immutable functional programming is basically what 80% of your Prolog code will look like. The benefit is that you'll be able to understand how everything works from end-to-end.

View on HN

Prolog is a logic programming language though, I wouldn't expect it to have a lot of overlap with functional programming?

Prolog variables are immutable by default. Data structures are the same as the immutable functional programming counterparts (no arrays, and tree based everything). Recursion is the only way to loop. Map, filter, fold(l/r), reduce, accumulate, etc, are staple predicates.

As I said, 80% of your code, or more, will look just like a functional programme.

An execution pipeline in a functional language is just half a relation in Prolog. Prolog allows you to also run it 'backwards', you can provide the output and have it figure out what the inputs would need to be.

Run in backwards, so they say, but not really. Most things you'll write can't run backwards. You have to write them in a special way for that to be possible, and even then what it means is that you can do a depth first search to find the value.

There are some useful extensions like clpfd and asp but really if what you're doing is solving a constraint programming problem, you're much better of with OR-tools or MiniZinc.

Prolog is beautiful. I have practically no use for it. I've struggled to find something I can do better with Prolog than other tools, but I just love it aesthetically and that's enough for me sometimes.

I don't know, most things I've written in Prolog 'runs backwards'. Doesn't seem special to me, things like cut and whatnot that might interfere do.

I kind of feel that clpfd, clpz and so on are just libraries, in what way do you consider them extensions to the language?

For me it's a neat way to model problems, and when I have I've commonly learned something new about the problem domain. Performance might not be great, interoperability and FFI might not be great, but as a tool for thought I really think it is.

https://www.metalevel.at/prolog

In SWI for example, clpfd and friends rely on attribute values and hook predicates to interject the backtracking process with their own thing. SWI provides those things so that it can be extended.

Non trivial Prolog programs which only use pure predicates and do not use cut are sparse. Yet those are also the only circumstances in which things like clpfd will work without special consideration.

Besides pengines and web development I have very little experience with SWI specifically.

And, well, yeah, it's common (e.g. look for cuts in https://github.com/mthom/scryer-prolog/blob/master/src/lib/c... ), but I don't think I've ever written a cut and I use Prolog rather effectively as a tool for problem solving. It's an interesting and quite powerful way to model and examine problems even if I don't produce programs with 'imperative' interfaces. Some scripting tasks are also quite easy in Prolog, e.g. certain log parsing, stuff like that.

How would this work with the XOR operator? Would it give all possible inputs?

Would depend on the implementation, I think. You could probably write one like that, but as usual there will be trade-offs. I suspect it would also matter if you're targeting booleans or numbers.

The typical, obvious case how these things work in Prolog is in list concatenation. If you only supply variables it'll start outputting lists of increasing length with placeholder variables. It's a somewhat simple engine for traversing a problem space and testing constraints that uses backtracking to step through it. Some implementations allow you to explicitly change the search strategy.

It's also biased into informal definitions, mixing side effects with logic, and encapsulating complex behavior together. It's way more biased into being a scripting language, while Haskell has all those biases pointed at being an application language.

So, I'd say that both languages lead people into very different programing styles.

Reply on news.ycombinator.com