Ask HN: Could a faster Prolog have succeeded in industry? | Hacker News Reader

Ask HN: Could a faster Prolog have succeeded in industry?

13 pointswrp7 comments

I've read most of what's available in English regarding the Japanese FGCP and their use of Prolog derivatives. What strikes me in all that I've read, is that the "failure" of the enterprise is attributed just to the poor performance they were able the achieve compared to object-oriented procedural programming. I haven't seen any evaluation of the FGCP approach in regard to the practicalities of software production.

From their early publicity, it's clear that the FGCP was aimed at programming in the large, the kind of projects now done with hundreds of programmers using C++ or Java. Consider a typical Java programmer in industry. How well would that person adapt to logic programming?

My suspicion is that even if the Japanese had gotten KL-1 performing like C++, there still would have been tremendous difficulty shifting programmers to that paradigm. I expect that a highly-performant parallel Prolog would have been received about like Haskell has been.

Any anecdotal evidence for or against this?

I agree that's the stated reason but I don't agree that was the real reason why it was considered a failure. Here are my reasons, reading between the lines, for why they considered it a failure in my opinionated order of importance:

1.) The Japanese bubble economy collapsed. They realized they'd have to stop funding it, and put their ambition to be the biggest AI power in the world aside.

2.) Logicist AI was losing ground to probabilistic AI.

3.) Special purpose machines were much more expensive to design and build than running the same programs on commodity general purpose machines. The Lisp machines ultimately suffered the same fate as the Japanese PIM machines.

4.) They weren't ready to deploy concurrent prolog. They hadn't worked it all out even theoretically. They were hoping that running it concurrently would speed it up, but probably realized that smarter algorithms and optimized implementations in individual programs would have a greater effect.

5.) They rushed the project, rolling out machines and languages before they had been fully worked out. The rushing mentality caused them to increase the expense of their mistakes and to make more mistakes than they might have if they didn't rush.

Also, I disagree that prolog hasn't been a commercial success. For example, Prolog is the right language for solving finite domain contraints and there is a mini-industry around this.

As far as shifting programmers, they had quite a few skilled prolog programmers and they weren't recruiting from the ranks of the then COBOL business programmers.

Yes, Prolog has survived in a few niches. But my question was regarding the original vision that Prolog would lead us to an era of large-scale, logic-based, general purpose programming. Historical reviews harp on the performance problem, while I suspect that the design and personnel issues involved in using logic programming would be a much bigger factor.

BTW, where have all those skilled Prolog programmers been hiding since then?

I kind of agree. It was definitely a combination of those factors and a few others. I think there was an inflection point in the past ten years where performance became less of an issue, allowing us to say now that performance isn't the issue it used to be. I still think that logic programming will be rediscovered as the language paradigm for the "killer app" to manage "big data."

Ultimately, it felt like less of a speed problem or even a design and personnel problem than a simple matter of taste. In other words, the reason why prolog isn't more widely used is because no one _wanted_ to train people to use it, the way they trained people to use scheme, c,c++,java, and now python. For some reason, logic and logic programming was distasteful to some influential people and many unfavorable conclusions were drawn about it without much foundation, whereas similar issues in other programming paradigms tended to be glossed over.

[edit] AFAIK those Japanese FG guys dispersed into academia and industry. But in the meantime, there was a development of being able to use multi-paradigm programming in a variety of languages including Java, so it's possible they are using other languages where appropriate parts of programs are written in the logic programming paradigm.

Not directly responsive, but here are two interesting Prolog-based systems for statistical modeling:

AutoBayes: http://ti.arc.nasa.gov/opensource/projects/autobayes/ by the same group that did AutoClass, one of the original publically available clustering codes.

PRISM, http://sato-www.cs.titech.ac.jp/prism/

Is there anything remotely "complicated" that has been really successful in industry? Java is about as basic as you can get, it doesn't even stretch its OO and imperative parts a lot, never mind other programming paradigms. C# has a few more elaborate parts, but I wonder how much use the more "arcane" subsystems get in larger code bases…

Prolog wouldn't have a chance over C++ or Java because it's not as good a programming language as C++ or Java (or Perl or Python or Ruby or C or many other languages). You'll notice that dramatically poor performance has not held back Python or Ruby.

Logic programming is a bad programming paradigm. The reason strictly evaluated imperative languages like Scheme or C++ are popular is because in these languages, you tell the computer what to do.

I think it was just bad timing.

Reply on news.ycombinator.com