Goal based programming generally implies non-determinism of some sort. In a way, it is "just" higher up the abstraction ladder, but it is pretty profound in its presumptions in terms of how you program. Languages like Prolog or SQL have a master algorithm behind the scenes that accomplish your goal, and so you spend a lot more time expressing the data and constraints on the data than on how it's done. In particular, it is hard to make assumptions about computational complexity or performance. In practice you wind up in an dual problem solving pattern where you alternate between goal/problem expression and tinkering under the hood with the system internals to improve performance.
Whether that's good depends on the problem... certainly SQL has been pretty successful.
But "at a high level of abstraction" and "leverages non-determinism" still isn't enough to get to "goal oriented". Garbage collection involves both of those things. So does JIT. And constraint-based layout engines. Although that last one, unlike the first two, is goal-oriented, right? Is there a pattern?
You're right, they're not enough. I guess it really boils down to making the computer reason about the data it has to achieve a goal or answer a question, rather than applying algorithms to data. The algorithms are intrinsic and hidden. https://en.m.wikipedia.org/wiki/Reasoning_system
Constraint based layout engines are such an example. Business rules engines are another. It's the fuzzy dividing line where we start considering programming techniques to be AI instead of conventional. This line is somewhat arbitrary based on history.
"It's the fuzzy dividing line where we start considering programming techniques to be AI instead of conventional. This line is somewhat arbitrary based on history."
Whether that's good depends on the problem... certainly SQL has been pretty successful.