
Ask HN: How would a goal-oriented programming language look like? - snrji
Reading this article and discussion: There Are Three Programming Paradigms (2013)  https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13612587<p>Imagine you could design a general purpose goal-oriented programming language. I was wondering how would such a language look like.<p>Actually, I&#x27;ve been having much spare time lately, so I&#x27;d like to actively research this topic.
======
irq-1
Look at Racket. It hosts multiple languages including prolog/solver variants.
Racket is made to create variant languages so you could start with a working
system and change it to try designs. Here's _just a few_ relevant Racket
links:

[https://docs.racket-lang.org/racklog/index.html](https://docs.racket-
lang.org/racklog/index.html)

[https://docs.racket-lang.org/parenlog/index.html](https://docs.racket-
lang.org/parenlog/index.html)

[https://docs.racket-lang.org/datalog/index.html](https://docs.racket-
lang.org/datalog/index.html)

~~~
snrji
Excellent, thanks!

------
brudgers
Prolog, SQL, or other logic programming languages...as mentioned in the linked
C2 entry.

~~~
snrji
Right, but these languages are declarative.

~~~
brudgers
Sorry. I guess I don't see how a goal oriented language would work without
declaring the goal and declaring the conditions under which it must be
achieved.

~~~
coldtea
Did you read the article the poster is reffering to, though?

It specifically mentions that the kind of "missing paradigm" looked for is not
one of the declarative ones we currently have (SQL, Prolog, etc) because those
fall into the Evaluate + Consequent combo.

So, he gives 3 paradigms:

FunctionalProgramming -> Evaluate + Mechanism (list of instructions)

ImperativeProgramming -> Execute + Mechanism

LogicProgramming/ConstraintProgramming -> Evaluate + Consequent (i.e. towards
a consequent (result) based on constraints) [this is where declarative falls).

So, the "goals oriented" language he defines as the missing: Execute +
Consequent pair.

~~~
brudgers
Yes. And the Hacker News guidelines.

~~~
coldtea
I would expect something more substantial for my "several paragraphs with
summary and references" response than "the HN guidelines say to not question
whether another has read TFA" then...

~~~
brudgers
Not going to feed you.

------
bjourne
Prolog and MiniZinc (google them) are two useful goal-oriented programming
languages. They are amazing at solving goal-problems, but are IMHO lacking in
the general purpose department. What I mean is that they are great at solving
n-queens problems and finding optimal seating arrangements, but not great for
writing web servers or GUI:s in.

------
childintime
I find Picat an exciting new development, with all three paradigms represented
properly. See
[https://news.ycombinator.com/item?id=16563349](https://news.ycombinator.com/item?id=16563349)

~~~
snrji
Very interesting. Gonna read it. Thanks.

------
wsy
If you want to work on a new programming language, think hard about an
application area where all current languages can't be used to express a
developer's intention easily and clearly.

Designing a language in the abstract usually doesn't work, it is better to
start with use cases that demonstrate how the new approach helps expressing
nicely what was cumbersome in previous languages.

~~~
snrji
So, start small with a niche? Thanks.

------
phaedrus
Another good source is anything to miniKanren / uKanren, especially papers and
talks by William Byrd. There's a book called the Reasoned Schemer by Daniel
Friedman and William Byrd describing their take on a goal oriented language.

~~~
snrji
Great, thanks!

------
coldtea
Neural networks and things like that look like "goal oriented" programming...

------
phaedrus
I've been working on this (albeit as a library rather than a language in its
own right).

The more papers I read the more lost I became trying to make sense of the
different approaches to goal-oriented / relational / logic programming. This
retrospective paper by Robert Kowalski gave me an historical framework to make
sense of it all:
[https://www.doc.ic.ac.uk/~rak/papers/History.pdf](https://www.doc.ic.ac.uk/~rak/papers/History.pdf)

One of the key insights I gleaned from that paper is the difference between
bottom-up and top-down strategies. All logic / relational / goal oriented
paradigms exhibit a characteristic top-down or bottom-up quality, and this
classification can then be used to understand the essence of goal-oriented
programming.

The following is my interpretation of the historical information from that
paper:

During the 1980s a burgeoning Datalog community, with roots in the database
field, assimilated the existing deductive database community which had roots
in AI. The database perspective focuses on finite models that are computable
bottom-up. However a naive bottom-up implementation, deducing forwards from
facts using rules, ignores the query until it derives it "as though by
accident." To make generated models relevant to the query, Datalog uses
transformations such as "Magic Sets" to incorporate the query into the rules.

An early deductive database (AI) strategy was Hyper-resolution, which is
essentially also bottom-up, and it suffers from the same problem of generating
new derivations blindly until one matches the query "by accident". Another
strategy known as "set of support" restricted the inputs (axioms) so as to
keep the derivations relevant to the query. However, according to Kowalski,
set of support only approximates top-down reasoning, and a better
approximation is linear resolution.

"Linear resolution addresses the problem of relevance by focusing on a top
clause C0, which could represent an initial goal."

A problem which stood in the way of implementing this top-down strategy was
the fact that given "n" clauses there are "n!" ways to compute the
conjunction.

"The obvious solution was simply to resolve upon the literals in the clauses
Ci in a single order. This order can be determined statically, by ordering the
literals in the input clauses, and imposing the same order on the resolvents.
Or it could be determined dynamically, as in selected linear (SL) resolution."

Thus, you see, it was the invention of SL, soon extended to SLD resolution
(the D stands for "definite clause") which enabled top-down logic programming
such as Prolog to be computationally tractable.

This top-down versus bottom-up distinction is what separates something like,
e.g. language integrated query (LINQ) from logic programming: despite the
similarity as a declarative form, a LINQ statement is computed bottom-up
because datasets are generated and transformed in a forwards (i.e. not
contingent) manner. In contrast a Prolog-style logic query (such as the Castor
C++ library) is computed top-down: the query consists of an AND-OR tree of
goals and subgoals which is visited top-down.

~~~
snrji
Wow, very interesting.

I'm familiar with Prolog and its implementation, but definitely didn't know
all of that.

------
svisser
You should look into BDI agents and BDI programming languages.

~~~
snrji
I will. Thanks!

------
meric
SHRDLU? It was goal oriented.

