> Well, I didn't say that clause ordering doesn't matter!

The OP complained about "[having] to specify how exactly in which order the calculations need to be made", and you said that this complaint had "no real basis in actual practice" and "I've never been in a situation where I had to think long and hard about how to order my predicates". You did kind of dismiss their criticism.

BTW, you keep talking about clause ordering, where goal ordering within clauses is the more difficult issue, I think.

> I don't think it has much to do with experience, or at least you don't need to be an advanced user to be aware of how clause ordering affects your results.

Based on my experience as a teaching assistant in a Prolog univesity course for a few years, I would say that it does have to do with experience, and beginners often get clause and goal order wrong. It's true that soon they become aware that ordering affects the behavior of the program, but they often don't understand how it affects the program, so they semi-randomly reorder things until they find a permutation that seems to work.

> So, yes, you need to understand a few things about how the language works

Yes! But we collectively haven't figured out how to teach this well, and many people are left with a terrible first impression of Prolog and don't continue to a point where they understand enough to be effective.

> Check out my new library.

From the Readme it looks nice. I think iterm_value/3 should maybe be called iterm_nth/3, which is more idiomatic. Also, since you mention GNU Prolog's array library, maybe also add if your interface is compatible with it, and if not, why not? I think more standardization of libraries across implementations would be better for the Prolog community than more fragmentation.

I think I dismissed the criticism about goal ordering being a game-stopper, not about it being an issue at all. That's what I tried to say anyway. I'm concerned that miserly nitpicking like this only serves to give programmers a good excuse to not even try to pick up Prolog.

>> BTW, you keep talking about clause ordering, where goal ordering within clauses is the more difficult issue, I think.

Yeah, sorry about that. I often refer to goals in the body of a predicate as clauses. I'm not sure if that's entirely wrong but it might be a bit confusing.

>> Based on my experience as a teaching assistant in a Prolog univesity course for a few years, I would say that it does have to do with experience, and beginners often get clause and goal order wrong. It's true that soon they become aware that ordering affects the behavior of the program, but they often don't understand how it affects the program, so they semi-randomly reorder things until they find a permutation that seems to work.

Isn't that how everything gets done? :)

I don't have any experience with teaching the language but I do understand it's a very hard subject to teach. I do remember that my first serious attempt at coding in Prolog was unbelievably frustrating. It took me a week to write a measly little predicate to get the next element of a list- because I really didn't understand what I was doing. I basically didn't need to do anything in the first place, I could have done what I wanted with member/2. But this was really not obvious to me from the descriptions of member/2 (or anything else) so I spent a week tracing my program and trying to figure out what the hell it was doing.

I'm used to the pain though, because I'm dumb-as-bricks and everything I've ever tried to learn, I had to really struggle through. So I persevered and now I'm a happy long-time user (that doesn't mean I don't still hurt, often). I understand why smarter students with a lower pain threshold would just give up on Prolog.

I was unhappy with the way Prolog was taught in my degree course. It was mostly "here's the syntax, here's some examples, go figure out the semantics on your own". Which is completely inappropriate for a language that's 99% semantics and basically has almost no syntax.

On the other hand, I think, as students, we had all been collectively spoiled by Java and Python and so on. If most languages are easy to pick up but hard to master, a language that's hard to pick up _and_ master is not going to be very popular.

>> From the Readme it looks nice. I think iterm_value/3 should maybe be called iterm_nth/3, which is more idiomatic. Also, since you mention GNU Prolog's array library, maybe also add if your interface is compatible with it, and if not, why not? I think more standardization of libraries across implementations would be better for the Prolog community than more fragmentation.

Thank you! I appreciate this. Those are good suggestions, particularly the one about following GNU Prolog's interface. You're absolutely correct about fragmentation and I'll try to follow your advice- but indexed_terms is not my array library yet! It's a precursor to that. I'm working on the actual array library now, based on indexed_terms. I just put indexed_terms out there hoping for some early feedback.

> I think I dismissed the criticism about goal ordering being a game-stopper, not about it being an issue at all.

Fair enough.

> I'm concerned that miserly nitpicking like this only serves to give programmers a good excuse to not even try to pick up Prolog.

Agreed, though "the issue you raised is not really an issue" could be read as "you're not smart enough for this", which is also a turn-off.

Anyway, even if goal ordering matters, we still have unification and backtracking as advantages over imperative languages.

>> "you're not smart enough for this",

Eh, I hope my original comment didn't come across as saying this. I'm fully aware that's the worse attitude for attracting more people to Prolog.