[anthk]

>what if programming wouldn't involve defining exact steps, but instead just roughly defining what we have and what we want and maybe giving a few hints, and having the computer generally do the right thing - wouldn't that be awesome?

So, Prolog?

[giardini]

Why Prolog? I have never noticed that Prolog was any better than other computer languages at reading one's mind!

[acobster]

Generally doing "the right thing" based on a rough definition of "what we have and what we want" is not mind-reading, but it is essentially what Prolog does. The author seems to conflate AI with declarative programming here, and I think that was the point.

[jcranmer]

Prolog, or at least logic programming languages, were thought to be the wave of the future of programming in the 80s. They, of course, turned out to be a massive bust.

[YeGoblynQueenne]

>> They, of course, turned out to be a massive bust.

What was supposed to be the wave of the future was the Fifth Generation Computer Project [1], initiated in Japan. Its ambition was to create machines that ran Prolog natively, as in, in special-purpose hardware. What turned out to be a "massive bust" was any attempt to use special purpose hardware in the face of rapid increases in both speed and power by general-purpose hardware (ie, x86). The same fate awaited Lisp Machines [2] and similar projects.

Prolog and generally logic programming hasn't really gone bust at any point. The point of Prolog was to use first-order logic as a computer programming language. That worked just fine, and works just fine nowadays still, although of course automated theroem proving must always rely on heuristics in order to be practical.

As to the issue of efficiency, most Prolog interpreters today are based on the Warren Abstract Machine, an efficient virtual machine for Prologs. There are other designs besides it that are also equally efficient.

Prolog has not really ever had an issue with efficiency ever since the early seventies. In fact it was a previous attempt at a "pure" logic programming language that had the efficiency issues, PLANNER [3]. Prolog was created specifically to be an efficient logic programming language, sacrificing purity for pragamatism.

I calculate it will be at least 2070 before we hear the last of it, of course.

_______

[1] https://en.wikipedia.org/wiki/Fifth_generation_computer

[2] https://en.wikipedia.org/wiki/Lisp_machine

[3] https://en.wikipedia.org/wiki/Planner_(programming_language)

[yazr]

You are factually correct

But, a key problem was the runtime (in)efficiency of the prolog implementation engine. Maybe today with x1M more powerful computers it is worth trying again ?

Neural networks were abandoned in the 80s and made a massive comeback with a. more compute power b. convolutional networks

In fact, maybe a ML-optimized VM will make higher-level languages useful again ;)

[ScottBurson]

No, the problem was not that Prolog was too slow. The problem was that it was too stupid.

Prolog's strict left-to-right, depth-first search strategy allowed the implementations to be, in fact, quite fast. But that same strategy also kept it from being more than a small step toward true declarative programming, because Prolog programmers have to understand the order in which subgoals are tried. For example, consider a goal that can be satisfied by either of two clauses, which we'll call A and B, and where every problem instance can be solved by exactly one of these; however, clause A always completes (either succeeding or failing) in constant time, but clause B, if invoked on an instance that would cause it to fail, goes into infinite recursion (an easy thing to do by accident in Prolog). It's imperative (ha!) for the Prolog programmer to make sure that clause A is tried before B.

This kind of thing comes up all the time in Prolog programming. On the one hand, you have to be aware of the order of operations so you don't cause infinite recursions (or, short of that, cause your program to take exponential time); on the other, Prolog programmers frequently exploit the left-to-right, depth-first strategy by using the operator known as the "cut". The cut is a non-logical operator in the sense that its semantics can be expressed only by reference to the Prolog search order.

Programs written in a true declarative language might superficially look a lot like Prolog programs, but the implementation would need to be much smarter -- doing things like figuring out the correct order of operations on its own. (I think machine learning might actually turn out to help with this.)

Anyway the problem with your suggestion that we just need to throw more hardware at Prolog should be evident by this point. It doesn't matter how fast your machine is if your algorithm is exponential in the typical case (never mind if it contains an infinite recursion!).

[YeGoblynQueenne]

>> The problem was that it was too stupid.

It's ... a programming language? It's Turing complete. Nobody said it's intelligent.

>> It's imperative (ha!) for the Prolog programmer to make sure that clause A is tried before B.

That is one of those cases where Prolog takes the pragmatic approach to allow efficient computation rather than sticking to "pure" semantics of the kind that tends to make a big mess of things just to keep things "clean" (like, oh, I don't know... monads?).

Btw, I've written reams and reams of Prolog in the last five or six years. The fact that your code has two readings, declarative and imperative is only a problem if you allow your mind to remain stuck in some purist definition of declarative programming that looks beautiful but doesn't really work.

If you accept that we live in an imperfect world, have to contend with primitive computers and limited resources of all kind, then Prolog is fine and miles and miles ahead of anything else in terms of declarative semantics. Even lisps have magickal and mysterious stuff like eval etc.

In actual Prolog programming practice the imperative reading means you can actually debug your code and follow it around as it falls over your own bugs. A purely declarative program would also be purely undebugable.

The dual semantics is only a problem if you don't understand the language. And in what language is that not what you'd expect?

>> Prolog programmers frequently exploit the left-to-right, depth-first strategy by using the operator known as the "cut".

No, let's say things the way they really are. The cut is there to allow a branch of the depth-first tree to be, well, cut. Correct, its semantics are purely imperative. Its real use though is to stop unnecessary searching and backtracking and therefore make your program more efficient.

It's not there to "exploit" anything. The fact that it can be exploited is troublesome, but so is all sorts of stuff in programming, like buffer overruns or sql injection. It sucks, but ... imperfect world, scarce resources etc.

>> your algorithm is exponential in the typical case

What? Why does your algorithm have to be exponential if it's in Prolog? What the hell are you on about?

[ScottBurson]

I guess my use of the term "stupid" made my post sound more pejorative than I meant it to be. I have enjoyed writing Prolog programs on occasion. Some of my best friends are Prolog programmers!

But I was trying to explain why Prolog is not the declarative language that we all hope for (well, a lot of us do, anyway) and that it initially appeared, to some, to be. And I think the answer to that is exactly what I said. That doesn't mean it's not a useful tool!

> [The cut is] not there to "exploit" anything. The fact that it can be exploited is troublesome, but so is all sorts of stuff in programming, like buffer overruns or sql injection.

Whoa! "Exploit" is a general term; it doesn't just refer to security vulnerabilities. Dictionary.com offers this definition for the verb: "to utilize, especially for profit; turn to practical account: to exploit a business opportunity". (The definition I would offer is "to take advantage of", which can mean to make use of a vulnerability, but doesn't have to: you can take advantage of a convenient feature of a program.)

So when I say people "exploit" the search strategy by using the cut, I mean only that they gain benefit from it; if the search strategy were not so well-defined, the cut would be unusable.

> Why does your algorithm have to be exponential if it's in Prolog? What the hell are you on about?

If you try to write a significant Prolog program without understanding the search strategy, as if it really were a declarative language, your program will wind up being exponential or worse. Merely throwing hardware at this problem won't fix it. That's all I'm saying. I agree I didn't say it well the first time.