Ask HN: Why isn't Prolog more popular? - <AUTHOR> Also, what would it take for Prolog to become a great general-purpose language? <comment><USER2> For me, the big problem with Prolog (and the whole concept of declarative languages) is that the intended benefit requires an unreasonably (or impossibly?) smart compiler.

The concept works when I can declare what I want to be done, and the system does it - and when that happens, Prolog is great, the language is great for declaring what I want to be done.

However, often it happens that the system does it in a way that's somehow horribly inefficient and makes it totally unusable. And _then_ I have to redeclare my requirements in a slightly different way to nudge the system into doing it differently - and this is much harder, then I have to worry about much more moving parts than just my code.

Also, the language is not really well suited for that; if I have to specify how exactly in which order the calculations need to be made, then imperative languages are a much better tool. I'm throwing away all the advantages of Prolog if I have to do this all the time - and in practice I do.

Haskell has a bit of similar problems (though generally not with unexpected speed complexity but unexpected memory complexity through laziness and thunks), but Prolog is much worse in that regard.

<comment><USER3> > For me, the big problem with Prolog (and the whole concept of declarative > languages) is that the intended benefit requires an unreasonably (or > impossibly?) smart compiler.

I'd say... sufficiently smart. We've been writing SQL for decades without such complaints and it works rather well in practice. Sometimes you have to introspect your queries and interact with the underlying interpreter to understand the performance constraints but it is much better than the alternative! Imagine having to write every query as a procedure... what a headache and the duplication!

Although learning to write well-performing queries does, I think, take some understanding of the underlying theory driving relational databases and SQL... which can be true for Prolog as well.

I'm not really sure why Prolog isn't more popular. Any time I've written declarative DSLs for a solver engine it always feels like I'm re-inventing an under-specified sub-set of Prolog.

After all the calculation of computer programs is the syntactic manipulation of predicates, is it not? Maybe if we all started with first-order logic and predicate calculus a language like Prolog would appear to be more practical. I think for a majority of programmers however it can seem a bit alien as we're trained to think in terms of procedures and steps rather than invariants and predicates.

<comment><USER4> _We 've been writing SQL for decades without such complaints and it works rather well in practice._

Speak for yourself. My experience of SQL is that it requires careful tuning whenever the numbers involved grow beyond the trivial. Query plans need inspecting, and often indexes aren't used appropriately. Queries are written and rewritten several different ways to encourage the database to choose one plan or another.

If your use of a database is limited to key-value lookups and object graph navigation with an ORM, with <100 values on any given edge, you'll have a fine time, I'm sure. Not everybody uses databases that could trivially be replaced with an object graph.

For more complex operations, I'd like to be able to write in the form of a plan with a graph of data flow directly. Scan this table, filter against this index, sort these two data sources and do an merge anti-join, etc. Today, I need to rewrite the query while knowing the planner well enough to foresee how it's going to implement my query, gradually homing in on my target through a series of indirect inspections.

<comment><USER3> > Speak for yourself.

Fair enough.

I use PostgreSQL quite heavily at present and do not use ORMs. I'd guess, probably optimistically, that 80% of the non-trivial queries I write are easily optimized by the query planner and require no further thought from me. In my experience these aren't the majority of the queries I write. The final 20% of these queries are the hard ones that, as you say, require some work and re-writing to get the query planner to choose an appropriate plan.

At least I find the tooling in PostgreSQL to be more than ample to assist in optimization tasks.

The spirit of my example of SQL is that we already use declarative programming languages in mainstream systems. Even with recursive queries and common table expressions I think, and I may be wrong, that Prolog is probably more general- purpose and expressive than SQL. And yet it's not nearly as popular for some reason.

<comment><USER2> Well, but SQL is actually a quite good illustration of the reasons why Prolog isn't popular.

I mean, you technically _can_ write all of application functionality in many dialects of SQL, but it's generally considered a bad idea to do so for obvious reasons - SQL is good for some tasks, but for everything else other languages are preferred.

In a similar manner, even in tasks ideally suited for Prolog's strengths (e.g. reasoning systems) _that_ part of the task will be relatively small - in any practical system, the "boring" code of integrating everything with everything else, handling a graphical UI, mangling data from one format to another, wrapping it in a REST web API and god knows what else will be at least 3-10 times larger than the core part of that task. I recall an old project where we had the core algorithms in Prolog, but the surrounding app in Java - the fact that the Java code was much more than 20 times bigger wasn't a verbosity issue, it actually did 10 times more stuff; although it was quite boilerplate, it all was needed and it was clearly simpler/faster/cheaper to make it in Java back then rather than do everything in Prolog. It's not sufficient for a language to make the hard (or domain specific) things possible, it also needs to make _all_ the easy things easy, and Prolog really does not.

So the language either needs to be truly general purpose (and "more general- purpose than SQL" isn't sufficient) or easily integrated with other languages. There are successful examples - for example, tensorflow->python, where again the actual ML part for anything more than proof-of-concept is much, much smaller than the surrounding general purpose python code; or SQL, which is well integrated into other languages.

In another post you mention "I've written declarative DSLs for a solver engine" \- why it wasn't trivial (compared to writing a new DSL) to include some Prolog code _as the DSL_ inside the app as easily as people include SQL in their apps as the DSL for managing data? There's your answer for why it's not nearly as popular.

</comment></comment></comment></comment></comment><comment><USER5> My opinion: Humans are good at thinking sequentially, imperatively. Other language paradigms are harder.

That isn't to say that Functional languages (Lisp, Haskell, Scala, etc) aren't as good; frankly, I like them better. There's just a mental gap that has to be crossed and for most developers I've met, that can be challenging. Why do things in a challenging way when I've got Java right here and it works just fine? (straw man, not my own view)

Prolog (logic programming) is a bigger gap, imho. It takes more effort for me to really understand Prolog code. Can do some beautiful things with it, but it's easier to have a few good developers be good at it and put their hard work behind a library/API than it is to have every other developer try to get over that gap.

<comment><USER6> I think you're right.

The promise of Prolog was that you'd be able to just define the task requirements, then write the requirements in Prolog and magic would happen. But even the most experienced Prolog coders I know don't really think in Prolog. When faced with a coding task, they inevitably first (mentally) figure out the problem in an imperative form, perhaps with some recursion, and then they they ask themselves "okay, how do I convert that to logic and pattern- matching?"

If you're going to go through that process, then Prolog provides no value: it's just an extra step, and you might as well code in C (okay, Lisp).

I fear that Haskell will turn out the same way. After all monads are just monoids in the category of endofunctors, right?

<comment> nv-vn This is really dependent on the programmers background and what they're writing. Some code is super easy to write in Prolog and much harder in any other languages. Take type inference algorithms for example. Rather than describing how to solve it, you just translate the typing rules directly to Prolog clauses. Thinking about imperative problems is hard in Prolog and will make you think backwards. Thinking about logic problems in C is the same way.

<comment><USER7> I second this. When writing Prolog programs, the more you think procedurally, the more specific your programs will become in the sense that you can then typically only use them in specific _directions_.

To make your Prolog code as general as you can, I recommend to also _think_ in terms of relations. This definitely takes effort, which pays off in the increased generality.

</comment></comment></comment></comment><comment><USER8> I have a few ideas, but the main one is that: independent of the language/semantics, languages only really take off because of a "killer app" use case where they are required. Once that's in place, tooling is built to make it much easier to complete projects in.

As a few examples: Objective-C was only popular for years because it was _required_ to write iOS apps. Ditto JavaScript being the only way to write for web. Ruby only got popular after Rails. C++ was the blessed way to write for Windows in the 90's. Java had a giant marketing budget, "write once, run everywhere," and was looking to be the best way to write for the web (lol applets). This isn't a perfect explanation, but in many of these cases, it wasn't about eager-vs-lazy, control flow constructs, variations in type systems, or anything related to what the language offered you, it was primarily necessity to be on the platform of your choice.

After that, tooling evolved, and they became easier to write major projects in. Why write a web app in Erlang when the JVM has every major templating system, an implementation of CommonMark, several high-performance JSON libraries, model validation, several mature build systems, and thousands of Stack Overflow answers?

This makes it hard for languages like Crystal or Nim to take off, but ON TOP OF THAT Prolog is asking its devs to completely change how they approach programming.

What would it take to make Prolog take off? A killer app. Which, in the 80's, looked like it was AI :-p

<comment><USER9> PHP's killer app was that it was easy for a System Admin to install on Apache and easy for a programmer to upload something that worked.

<comment><USER7> ... for a quite generous definition of "worked".

In comparison, writing web applications with SWI-Prolog is quite safe also thanks to the powerful quasi-quotation mechanism.

<comment><USER10> "... for a quite generous definition of "worked"."

Barely. All kinds of people learned it quickly. They built web applications. It became a dominant web, application language. The momentum led to many improvements in its ecosystem and deficiencies. Prolog failed to do... any of that at PHP's scale.

<comment><USER7> A language like PHP greatly increases the chance of security problems. There is ample evidence of such issues in practice. This is one consequence of the quite low-level way to reason about the available data, and a class of problems that does not arise so easily in Prolog.

This is just one of many instances where barely working solutions are used, partly stemming from a lack of alternatives at that time. Robust web frameworks are only now becoming gradually available in Prolog!

<comment><USER10> PHP wasn't designed for secure web applications. Most of its users don't care about that. It thrives anyway. So, this isn't a failure of PHP. On contrary, the author cranking it out quickly might have been a reason for success.

Now, someone wanting secure apps might not want PHP. They traditionally went with "safe" languages such as C# or Java whose runtimes were full of 0-days. They might find Ada, Component Pascal, or Rust with a web framework helpful. Even enterprise sector hasn't been writing most web pages is Ada, though. ;)

<comment><USER7> Why are you downvoting what I wrote? You are arguing against statements I did not make.

PHP worked for many people in what I can only consider a quite generous definition of "worked", in tandem with countless security problems that arise almost necessarily from its low-level data representation. I am not arguing that this has impeded its adoption, that most users care about this, or that it does not "thrive". These are _not_ signs that it works in the way I prefer software and languages to work. In particular, for writing secure web applications, I cannot recommend PHP.

In the future, I expect to see more and more Prolog web applications. The necessary frameworks are now becoming available, with much better safety properties.

<comment><USER10> You just repeated the statement Im arguing against: "generous definition of worked." The goal of PHP was to help people, esp non-experts, quickly build web sites. People off all skill levels managed to build web sites that did what they intended in the intended use case. As in, PHP worked for the exact thing it was designed for. It also went beyond that by getting massive adoption by people cranking out too many sites go count. Its success at its goal is legendary in a good or bad way depending on who you ask.

Next, you talk about the preference for secure, web apps. Being a high- assurance, security engineer, I'd expect you to immediately start talking about Ada, Opa w/ modified back end, SWIFT on SIF, Ur/Web, Haskell with secure framework... languages that are systematically dedigned to either make classes of vulnerabilities impossible or reduce them greatly. Also, esp Ada or SPARK whose low-level libraries are written in same language for as much safety as possible. Instead, you counter insecurity of PHP use by recommending a Prolog not designed for security with low-level components probably written in C or C++ since most Prologs are. It's probably gotten almist no pentesting to knock out low-hanging fruit either. If those are true, then that's highly hypocritical that you'd smear PHP while recommending something so insecure or uncertain in its security.

Far as downvotes, it was because you made a bogus claim about PHP's success with no substantiation. I certainly didnt downvote you cuz Im anti-censorship, voted to eliminate downvotes on Lobsters, and it's impossible to downvote a person replying to you. Check that claim by looking for downvote option next to my name. I instead prefer to counter bullshit with facts in actual comments. Also, with citations when I have time. As is clear by this one.

<comment><USER7> Thank you for your explanation! I do not in the least dispute that the goal of PHP was to help people, or that people managed to build web sites for the intended use cases. In fact, if one of PHP's goals was to allow a great number of unintended security flaws in user programs, then this was also splendidly achieved. Personally, I only cannot bring myself to call a site with security flaws "working", and when using PHP, these flaws are simply more easily made than with Prolog in my experience. Note that I need not even go as far as making any statements about particular implementations of Prolog or PHP, only about user _programs_ written in the two languages.

Please also note that I cited quasiquotations as one important advantage of Prolog. As for citations, the most relevant publication for this feature is:

Wielemaker, J., and Hendricks, M., _Why It's Nice to be Quoted: Quasiquoting for Prolog_ [https://arxiv.org/pdf/1308.3941.pdf](https://arxiv.org/pdf/1308.3941.pdf)

This feature lets you easily build _safe_ template engines in Prolog. Please let me know what you think, if you have time. I am in fact frequently looking for a pentester when building Prolog-based websites, are you interested in such a project?

<comment><USER11> Having done some work on static analysis of PHP applications, I agree that the language is very poorly designed. It seems the designers add any feature that they think will make it easier to write code, regardless of its effects on readability or security. It's an ongoing problem, too. One might have had some sympathy for an inexperienced language designer who pushed something out into the world because he thought it was cool, but then when people pointed out the problems with it, studied language design and learned to make better decisions. That's not happening with PHP; even some relatively recent design decisions are just mind-bogglingly bad. I am particularly frustrated by the choice, a few years ago, to remove the requirement that arguments being passed by reference be marked with an '&' at the call site (as well as on the function parameter receiving the reference). Since in general you don't know until runtime what function is called at a variable call site (e.g. '$f(...)'), you can't tell by looking at such a call which arguments, if any, are being passed by reference!

But, all that said, I think you can write an unsafe library or framework or app in any language. In fact I recall a vulnerability in a widely-used Ruby library in which one of the API functions normally expected some kind of object, but if you passed it a string instead, it would call 'eval' on it for you and use the result. This "helpful" behavior was not documented.

My point is that there's more to educating the masses about writing secure code than just telling them not to use PHP.

<comment><USER7> Thank you for this! Interestingly, the cases you mention _cannot arise_ in Prolog, because Prolog terms are _never_ evaluated implicitly. They are just terms, and you write predicates that reason over them. In pure Prolog, there is no way to pass something "by reference" either.

If you are determined enough, you can definitely write an unsafe library or app also in Prolog, and security mistakes are also routinely found in Prolog implementations, just as in PHP or Java implementations. The main point is still though that a large class of security issues that _easily_ arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs, due to the more direct, symbolic way you reason about data in Prolog, and additional mechanisms such as the mentioned quasiquotations which allow safe embeddings.

<comment><USER10> " The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs"

This is true. While we're at it, I think it's worth bringing up that the most powerful use of Prolog is embedding it in a LISP that is "batteries included." One like Racket. That way, one can use a safe, easy-to-analyze, functional style for most of the application, one or more DSL's for the templating (esp HTML), and Prolog operating on LISP structures when Prolog is best thing to handle it with. Alternatively, Shen uses something like Prolog as its type system so you can hand-roll a custom, type system for each component which might include security properties.

Far as good design, web, and security-oriented, the best I've seen is Opa language for doing that plus being productive.

[http://opalang.org/](http://opalang.org/)

Too bad they moved the backend to Node. Probably to latch onto an ecosystem getting momentum which is a lesson from Worse is Better philosophy. Most IT tech that didn't disappeared into history at some point. I'd have preferred it be Go if one of the new, popular things given its fast, simpler, and safe enough. Hell, if libraries aren't a concern, they can even output safe subset of C with all the checks enabled like Pieter Hintjens did with iMatix DSL's.

<comment><USER11> I thought Opa looked very interesting when I first heard about it, but I don't see much recent activity on the GitHub repo. Is it still alive?

<comment><USER10> I didn't even realize the last blog post as Sep 2013:

[http://blog.opalang.org/](http://blog.opalang.org/)

Hell, it might be dead. I'll have to email them some time this week to find out what's up. Fortunately, it's open-source so others can pick up where they left off if they want. Or do a clean-slate work with similar capabilities.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> For me, what killed it was the fun of making a simple change to your program and due to a single character mistake insert a bug that turns its run time from O(n) to O(e^e^n).

Besides, deep first recursive searches are easy to write and almost never work well in practice, so even the problems that are greatly represented in Prolog either do not get efficient binaries from the existent Prolog compilers or are easy enough to write in another language that little is lost on the transition (often both).

That said, I do think search based programming is underrated. There ought to be some representation for theorem resolvers that is good for general purpose programming. It's just that nobody found it yet.

<comment><USER13> > There ought to be some representation for theorem resolvers that is good for > general purpose programming. It's just that nobody found it yet.

There are some nice examples of search-based programming in Z3 (using the Python API) in [https://yurichev.com/writings/SAT_SMT_draft- EN.pdf](https://yurichev.com/writings/SAT_SMT_draft-EN.pdf) , if that is along the lines of what you meant.

<comment><USER12> That's cool. Although the syntax is very specialized, I never though about approaching general purpose search from a SAT solver.

</comment></comment></comment><comment><USER14> Oddly enough, I was just recently trying to play around with the PortableApps package of SWI Prolog, available here:

[https://portableapps.com/apps/development/swi- prolog_portabl...](https://portableapps.com/apps/development/swi- prolog_portable)

It's about the ONLY PortableApp that offers any kind of program development capability beyond text editing, that I could tell. No compilers, no interpreters outside of this and a couple of SQLite packages. Anyway, I pulled this one down, fired it up, and... no worky. I got a console, theoretically I could execute commands, but try and access the help or docs, and it bails out with an error, telling me xpce can't be loaded, because load_foreign_library/1 is not defined? At least half the menu commands failed with the same error, closing out the app in the process. Basically, the app is impossible to use.

So, there's my answer, one that can be applied to many otherwise promising languages. Any system looking to gain traction really needs to go out of its way to Just Work; to make itself readily available, easily installable, immediately functional, and with clear documentation right at hand. You can carry on 'til you're blue in the face about lazy programmers unwilling to learn a simple build-and-install process, but with the ready availability of other environments that generally Just Work, there's really no excuse. At least, that's how I feel about it.

<comment><USER15> But why try the "PortableApps" package of a program that isn't listed on that program's homepage instead of using that program's own executable installer listed on its homepage?

Is it not possible that this "PortableApps" package broke the program?

</comment></comment><comment><USER16> It's about 15 or so years ago I tried Prolog in an application for analyzing features of images. I remember two things from that – 1. Even though concurrency is elegantly described through guards, implementation turned out to to be not that easy, 2. You have to bypass the beauty of pure logical statements in practice (for example see the 'Craft of Prolog' by Richard O'Keefe on optimizing Prolog code). Once we get to this level of writing Prolog code, you find other standard languages and libraries more competitive and practical.

</comment><comment><USER17> When I tried to use SWI prolog for a toy-task, it failed miserably when dealing with facts that contained numeric expressions. I think if a variant of Prolog was paired with an SMT solver (e.g. Z3) it would be much more relevant today.

For example, when dealing with bitemporal data (common in finance) you might have a set of facts with two date range attributes. Lets simplify by saying we have a set of facts each having a start date and end date. Here is some non- working Prolog that could work if there was such a capability.

      entity('TimeWarner').
      ticker(entity('TimeWarner'), 'TWC', date(1999-01-01), date(2014-04-31)).
      ticker(entity('TimeWarner'), 'AOL', date(2014-05-01), date(9999-01-01)).
      current_at(ticker(entity(_), _, Start, End), T) :-
        T @> Start,
        End @> T.

      -- find current ticker for Time Warner
      current_at(ticker(entity('TimeWarner'), _, _), date(2017-05-29))

      -- SWI prolog can not unify the above clause!

(The code above is semi-pseudocode - but I did try and fail to make this work some time ago)

Now, it turns out that this sort of exists already, it's called Answer Set programming. There is one implementation out there [0] - but I didn't feel like dredging up an old research project.

[0] - [http://potassco.sourceforge.net/](http://potassco.sourceforge.net/)

<comment><USER18> I simplified your notation a bit and added some slightly silly predicates, but this works:

        ticker('TimeWarner', 'TWC', date(1999-01-01), date(2014-04-31)).
        ticker('TimeWarner', 'AOL', date(2014-05-01), date(9999-01-01)).

        transform_date(date(Y-M-D), R) :-
            R is Y * 416 + M * 32 + D.

        after(Adate, Bdate) :-
            transform_date(Adate, A),
            transform_date(Bdate, B),
            A @> B.

        current_at(Name, C, Start, End, T) :-
            ticker(Name, C, Start, End),
            after(T, Start),
            after(End, T).

        ?- current_at('TimeWarner', C, S, E, date(2017-05-29)).
        C = 'AOL',
        S = date(2014-5-1),
        E = date(9999-1-1).

<comment><USER17> Thanks - this is great. I stand corrected!

</comment></comment></comment><comment><USER19> Netsil's stream-processor is programmed using Datalog, which is a subset of Prolog.

Our architecture/use-case: At Netsil, stateful packet processing pipelines are written in declarative rules and materialized tables are backed by SQL compatible embedded in-mem DB. Tuples are executed in parallel and parallelism is controlled by specifying context constraints in rules (e.g. packets within same TCP flow should be processed in order). Further, Datalog workflows are distributable by providing "location specifier" in rules -- i.e. Tuples and attributes serialize to protocol buffers and can be sent/received over ZMQ. Also, the materialized tables in Datalog can be made to sync up with Zookeeper, allowing distributed stream processors to do service discovery and so on. It's a pretty sophisticated runtime/compiler, written primarily in C/C++ for optimal performance. The underlying runtime uses a combination of Intel TBB and Boost ASIO.

We are in general big fans of declarative approaches as they have saved us a lot of time, allowing our small team to leapfrog the competition. You can learn more about our architecture here: [https://netsil.com/blog/listen-to- your-apis-see-your-apps/](https://netsil.com/blog/listen-to-your-apis-see- your-apps/)

Disclaimer: I am co-founder of Netsil (www.netsil.com).

</comment><comment><USER20> I'd argue it can't be done. It basically has features that are best implemented as a library. In fact, the many kanrens (including Clojure's core.logic) demonstrate the effectiveness of this approach. Meanwhile, stuff like GPU-accelerated ML have supplanted it in the natural language processing arena, and functional programming has become the paradigm of choice for theorem provers like Agda.

<comment><USER21> Do you know very much about GPUs? Would but be viable to implement a kanren on top of cuda or something like that? Wouldn't that lend kanren insane performance gains?

<comment><USER22> not too surprisingly, a lot of logic programs don't parallelize very well at all because of very linear dependencies (control flow).

and some do a lot of largely independent but very regular work that would execute quite well on a simd/vector/smt array.

people have come up with some tricks to map control flow into simd (like some really cool parser tricks), but i think in general those have regimes where they have sub-serial performance.

so maybe? if you had the magic compiler? or you provided some manual annotation support? or a robust ffi?

for sql, which has a much more limited footprint, there's been some cool vectorization work.

</comment></comment></comment><comment><USER9> Prolog never had the SQL moment. SQL had IBM, Oracle, and relational databases to back it up and propel it into popularity. Prolog just never had that application. I also believe that the Japanese Fifth Generation Project's failure did a bit to harm the idea of a mainstream Prolog. I was very interested when Borland released Turbo Prolog, but it didn't quite last that long. It also, in its early days, suffered from a bit of Smalltalk vendor syndrome.

..and, sadly, it didn't look like C

// strangely Prolog is listed as a spelling error by Firefox...

</comment><comment><USER23> Prolog has a beautiful, powerful idea at its core: Resolution. Datalog shines because it doesn't try to overreach and focuses on making this core nimble and expressive in a domain excellently suited to resolution. Prolog tries to be general purpose and is all the worse for it.

Eventually the ideas in Prolog will make their way into a general purpose language where the relationship between the logical components and the algorithmic components of a program is harmonious instead of a constant conflict.

</comment><comment><USER24> This is opinion but I think the problems you can express well with a language like prolog are quite special. The problems programmers need to solve every day are better expressed by a language that's closer to human languages. How would you write in prolog that you want it to serve a website? Of course this is possible but probably not in an idiomatic way. Furthermore like with functional languages the performance of the program is harder to predict.

<comment><USER25> > How would you write in prolog that you want it to serve a website?

Here's one approach: [http://www.swi- prolog.org/pldoc/man?section=pwp](http://www.swi- prolog.org/pldoc/man?section=pwp)

Scroll down for examples. You might disagree, but I think the fit between Prolog semantics and expanding XML templates is surprisingly natural.

</comment></comment><comment><USER26> It's difficult to get started with Prolog beyond toy examples. Prolog was originally designed for creating linguistic models for use in NLP. Even for this original purpose it isn't exactly easy to use.

When it comes to mundane tasks such as opening a file and reading its contents as a string or accessing databases, things get even more difficult. Technically, this is all possible with Prolog, too. It's just not exactly fun to do so.

<comment><USER7> First of all, I fully agree that it is hard to start with Prolog initially. However, let us take a look at these particular examples:

As to _opening a file and reading its contents as a string_ :

I find it best to use Ulrich Neumerkel's library(pio) to accomplish this task. Importantly, this lets you apply a DCG to a file in a _pure_ way. I start with a DCG that simply describes a _list of characters_ :

        content([]) --> [].
        content([C|Cs]) --> [C], content(Cs).

I save this in content.pl, just to have a file to try. I can now apply this DCG to the file contents with phrase_from_file/2:

        ?- phrase_from_file(content(Cs), 'content.pl').
        Cs = [c, o, n, t, e, n, t, '(', '['|...] .

Thus, I have read the file contents as a _list_ of characters, which I can easily convert to anything I want with other predicates.

As to _accessing databases_ : That's quite straight-forward too, in particular if we take into account the following: If you are really using Prolog professionally, then typically Prolog _is_ the database. You simply assert facts, and retrieve them by _querying_ the built-in Prolog database.

Personally, I find Prolog queries much more convenient and also more expressive than SQL, and great fun too.

<comment><USER27> The problem is "Prolog is the database" is that there isn't a great solution for persisting that database, which is usually what people mean when they talk about databases. Sure, for SWI-Prolog there's Persistency but that a) doesn't help you if your data doesn't fit in memory, and b) doesn't give a lot of the same guarantees as something like Postgres about durability through sudden failures (as far as I can tell, the docs sure don't mention it). It's closer to SQLite than a database you'd use for a production web app.

<comment><USER7> Yes, I agree with this. In SWI-Prolog, in addition to library(persistency), there are already some published results on transaction support for the internal database, which will give you some features that facilitate such use cases. This is already available and in fact also running for production web apps, but currently only for the RDF database. It is true that if you need more advanced functionality that dedicated database systems readily give you, then you have to wait until such features become available in SWI-Prolog, pay for their implementation, or resort to using an external database for which there often are bindings.

</comment></comment></comment></comment><comment><USER28> Prolog is used in IBM Watson, Datalog, and AFAIK in Windows OS.

Prolog is not so popular for general purpose computing since: compilers are inconsistent, compatibility problems, difficult debugging, high maintenance costs, few experts, steep learning curves (my professor joked that the more computer science the student is exposed to, the harder is the mental switch to Prolog).

Prolog remains great for education on logic, NLP parsers, recursion.

</comment><comment><USER29> As someone who has quite the extensive experience with Prolog, I can best summarize that there are some types of programming problems at which it excels: deduction, ordering, discrete constraint problems, etc; and at everything else an imperative language is often simpler to use to achieve the same end result.

</comment><comment><USER10> Look into Mercury language for a take on something that might be more acceptable by mixing logical and functional:

[https://www.mercurylang.org/about.html](https://www.mercurylang.org/about.html)

<comment><USER30> Prince XML, a software tool to generate PDF from HTML and CSS, is written in Mercury.

[https://en.wikipedia.org/wiki/Prince_(software)](https://en.wikipedia.org/wiki/Prince_\(software\))

From above page:

>Prince was developed using the Mercury functional logic programming language.

</comment></comment><comment><USER31> I'm no expert, but I've tinkered with prolog in the past and with Clojure's core.logic more recently and in my opinion it's because the part of my problems that would be a good fit for prolog make up only a small part of the solutions that I write to solve them. For this reason, something like core.logic is much more interesting and useful because it means I can express the part that is well suited to logic/constraint programming in "prolog" and the parts that are not well suited, can be written in another language more suited to those tasks.

For example, I can write some code in clojure, that, for example, implements a UI which then calls core.logic to do some processing, which then calls some clojure to pull the logic data from a database. If I wanted to use prolog, I'd have to do something like: (other language -> ffi -> prolog -> ffi -> other language) which is usually too much effort for me to bother.

</comment><comment><USER32> I thought the same thing till I tried to program in it and I immediately understood.

It is not intuitive, and most programs aren't logical problems in the sense that the prolog can solve. It is highly specialized.

It belongs to an era -- and this era isn't "over" \-- when the primary manner of solving AI was symbolic.

</comment><comment><USER7> As to the first question: There are several reasons for this. One is rather inherent and can be understood by considering the following analogy:

Java, C, and many other programming languages are like chess: There are many syntactic rules, and by learning them, you already obtain a rough overview of what you can do in principle. You try out these constructs, and get a sense that you have accomplished something, even if it is rather worthless, and more complex tasks are extremely hard to carry out successfully in these languages.

Prolog is more like Go: The syntax is very simple, and there is essentially only a single language element, the _logical rule_. This means that even if you know, syntactically and semantically, almost everything about the language, you have no idea what to do at first. This can be rather frustrating. From this, beginners easily arrive at the misguided conclusion that the language is useless, or restricted to very specific applications. But it only means they have not grasped its true power and flexibility! Getting to the core of Prolog is hard, and requires systematic guidance.

This inherent difficulty is frequently compounded by a rather ineffective and _outdated didactic approach_ which, at its worst, stresses difficult and mostly superseded procedural aspects over more important declarative principles and more modern solutions like constraints. This easily gives the misguided impression that the language is rather imperative and limited in nature, and again causes many students to dismiss it due to their wrong impressions.

A third reason is found in the _implementational complexity_ : From a user's perspective, a major attraction of Prolog is its _ease of use_ due to the syntactic simplicity, powerful implicit search mechanism, generality of predicates etc. which are features that are rather specific to logic programming languages. The complexity of all this is shifted to the implementation level: In order to make all this both powerful _and_ efficient, the implementation must do many things for you. This means you need, among other things and in no particular order: an efficient garbage collector, JIT indexing, a fitting virtual machine architecture, a fast implementation of unbounded integers, rational numbers, good exception handling, ISO compliance, many goodies like tabling, an efficient implementation of constraints over integers, Boolean variables, Herbrand terms etc. Most of these topics are even now still subject of _active research_ in the logic programming community, with different advantages and trade-offs. Implementing an efficient Prolog system is a project that _easily_ takes 30 to 40 years. In fact, we are only now getting to the point where systems become sufficiently robust and feature- rich to run complex client/server applications for months and years. In such complexities, you find the answer why Prolog isn't more popular _yet_. It has simply taken a few decades to implement all this in satisfactory ways, and this work is still ongoing. In my view, Prolog is now _becoming_ interesting.

To the second point, Prolog already _is_ a great general-purpose language. You can use it for almost all applications that are currently written in Java and Python, for example. Of course, there are always some features that are worth adding on top or via extensions, and certain tasks would benefit from this. For example, you can add extensions for type checking, and for fast arrays. Various Prolog implementations are already experimenting with such extensions. Many extensions can in fact be implemented via term and goal expansion, a facility that is analogous to macros in Lisp, or via simple reasoning over given programs.

<comment><USER33> Good post, in particular splitting out the differences between explicit syntax vs expressive syntax. I myself am quite fond of expressive formal systems, but equivalently useful explicit systems are much easier to pick up even if their ruleset is larger. One has hack-y corner cases but generally keeps you on the rails, the other has the hacks _as the rails_ and expects you to not fuck up where you're going. Or something like that.

<comment><USER7> Thank you! I found the following chart useful:

      *) machine and assembly languages: simple syntax, simple semantics
      *) procedural languages: complex syntax, AST not available, many language constructs
      *) Smalltalk, LISP, Prolog: AST available, few language constructs

Source:

[http://www.complang.tuwien.ac.at/ulrich/prolog2009.pdf](http://www.complang.tuwien.ac.at/ulrich/prolog2009.pdf)

<comment><USER33> Well now I must definitely use Smalltalk!

<comment><USER7> It's definitely worth a look! Richard O'Keefe, one of the most highly regarded and accomplished Prolog programmers, even wrote his own Smalltalk implementation too:

[http://www.cs.otago.ac.nz/staffpriv/ok/software.htm](http://www.cs.otago.ac.nz/staffpriv/ok/software.htm)

</comment></comment></comment></comment></comment><comment><USER34> One of the worst things I found during my prolog courses was that authors seemed to conflate "shorten" and "simplify". We had whole exercises dedicated to taking a readable chunk of code and turning it into some godawful one liner.

</comment><comment><USER35> You can answer this question yourself: simply figure out how you'd implement certain types of programs in Prolog. For example: an operating system, a Unix command-line tool, a video game, etc. You'll quickly shake out deficiencies.

<comment><USER7> These are good questions! As a simple control, I have asked myself these questions with Java in mind, which enjoys notable popularity.

Would I write an operating system in Java? No. A Unix command-line too? No. A video game? Probably not.

In my view, this casts some doubt on the test's adequacy to answer the initial question. In the concrete case of Java, I think marketing and other influences also played important roles. It could be possible to apply these advantages to Prolog too.

<comment><USER36> You are not asking the same questions. The question is _how would_ , not _would_. While I'll admit writing an operating system in Java is non-trivial (thinking of kernel-level programming here), writing a command-line tool or a video game is pretty simple. You main method receives command line arguments, so that part is covered, and for games you do pretty much what you would do in any other language.

<comment><USER7> Thank you! Indeed, the question was "how" would I do it, so let us consider it:

Operating system in Prolog: Non-trivial, i.e., like in Java. Command-line tool: Pretty simple: My main predicate receives command line arguments. There are countless such examples already, included in the SWI-Prolog distribution (for example). And, as you say, for games I would do pretty much the same as in any language also in Prolog.

In my view, this still leaves the same doubt about these questions: Can we distinguish Java from Prolog in any way by answering them?

</comment></comment></comment></comment><comment><USER37> I've never messed around with it beyond toy problems, but I recall Norvig saying in one of his books that it was trivial to code up NP hard problems in Prolog and other logic constraint languages without realizing that you did so.

</comment><comment><USER38> I have used Prolog a few times in a profession setting. When you are using it for the right problem, it is perfect.

To use it in a more general purpose sense, I think you need a couple of things.

First, you need some really great training and or books showing practical examples as well as how to overcome common issues with performance.

Second, you need more people contributing the some of the open source options like SWI Prolog.

Third, I think you need more ready to use bindings for the popular languages out there. SWI Prolog provides a C interface, but if you had an interface to say Node, Go, Rust etc that was simple to install with some good examples, you could reach more people.

</comment><comment><USER39> I don't know about general-purpose, but I've seen Prolog implementations for specific logic problems. Most recently, chalk [1], a Prolog interpreter designed to be used in the Rust compiler's trait system. So I wouldn't say it's not popular, but the areas it's used in are probably not what most programmers deal with every day.

[1]: [https://github.com/nikomatsakis/chalk](https://github.com/nikomatsakis/chalk)

</comment><comment><USER40> I would say the problem is pretty similar to why isn't Haskell more popular?

both have a different/specific (as in non-mainstream) thinking way, and it is not easy to switch from common programming languages to these. and since it isn't easy, most people don't go deeper on them

from a company point of view: if it's hard to find a good Prolog/haskell developer, then they will be more expensive, so they stick with the common Java/C/C#/Python/Ruby/JS stack

</comment><comment><USER41> I tried programming in prolog and read some introductionairy books. However, no book talks about how you would define more complex 'types' objects. How would you model the following domain in prolog:

Comment: Attributes: text, points

User: Attributes: name, emailAdress(as a struct of first part, domain, top- level-domain)

Admin(a special user): additional Attributes: set of rights(can delete, can hide, can modify)

Finally, there is an n-1 assocation between Comment and User and I want to make some queries about this domain.

<comment><USER7> There are several ways to do it. One straight-forward way is as follows:

We can represent _comments_ by facts like:

        comment_id_user_text_points(3, 1, 'hello!', []).

I do not know what exactly you mean by "points", so I have simply supplied an empty list (fourth argument) in this case. Note that there is an ID for the comment, and an ID for the user that posted the comment. Therefore, we say that this is a _relation_ between users and comments and their text and points, usable in all directions.

Each user can likewise be represented as follows, relating a unique ID to a name and e-mail address:

        user_id_name_email(1, 'randomUser1122', [random,'ycombinator.com']).

For _admins_ , I can simply add additional facts, relating user IDs to _rights_ like this:

        admin_id_rights(1, [delete,hide]).

Now, we can simply post _queries_ over these facts, such as:

        ?- user_id_name_email(ID, _, _),
           comment_id_user_text_points(_, ID, Text, _).

and obtain, on backtracking, all comments for any user.

This is all completely analogous to how you would represent such data in any database system. It's more convenient in Prolog though for several reasons.

<comment><USER41> Wow, modelling it like in a relational DB is a great idea! Thanks. Your trick of adding names of the properties like "_id_user_text" is neat. In the past, I tried a similar solution like but I would always forget which property is at which position.

How would you make sure that the rights of admins are only delete, hide, and modify (and not e.g. walk, talk, chalk) ? If I use

      admin_id_rights(Id, Rights):- numeric(ID), sort(Right, SortedRights), subset(SortedRights, [delete, hide, modify]). ,

then I obviously have added all possible admins.

Moreover, how would you then 'create' objects without adding them with asserta. Assume that all the user, admins, comments are written to a text file which should be queried. I can easily read them into some nested compounds with DCGs. However, I would like to create objects(e.g.like Java's new) to check that they adhere to the contraints of my model.

<comment><USER7> The naming trick makes clear what each position means: The order of arguments follows that of the name's components. So, if the name contains id_user_text, then the arguments are also in this order: ID of comment, ID of user, and the text. This is a simple mnemonic technique I use for naming important predicates.

As to your first question, we are now talking about (database) _integrity_ constraints. So I would first state which rights are admissible at all by clearly defining what we consider a right. For example, in this concrete case:

        right(delete).
        right(hide).
        right(modify).

Next, I _describe_ the situation that an admin was inadvertently assigned a "bad" (i.e., not actually existing) right:

        user_bad_right(ID, R) :-
             admin_id_rights(ID, Rs),
             member(R, Rs),
             \+ right(R).

Now, I can ask Prolog: _Are there any bad rights assigned_? I do this by simply posting the most general query about this relation:

        ?- user_bad_right(ID, R).
        false.

I conclude: _No_ , there are no bad rights assigned.

As for _creating_ objects: This is a _good_ case of using the dynamic database, i.e., predicates like assert/1 and assertz/1\. The database is very good for frequently _retrieving_ information, but not good for frequently _updating_ the information. This is a fitting situation: Comments are presumably only posted once, and in that case, you can simply add such facts to the database.

But you can of course also make all this explicit, and first construct a _term_ of the form comment_id_user_text_points(3, 1, 'hello!', []), and then reason about such terms (instead of reasoning about the asserted facts). Note that this term looks exactly like the fact syntactically, due to the homoiconic nature of Prolog. Therefore, you have many ways to reason about your data. You can even write all such terms to an external file, and simply consult all facts (and even rules) it contains by invoking consult/1 _dynamically_.

<comment><USER41> Thank you for all you great tips. Do you know any good book(except Craft of Prolog, Prolog for AI) or good code on github following this principle?

<comment><USER7> Thank you for your interest!

Since Prolog is now gaining more traction, I am adding to my favourites all Prolog links which I consider noteworthy or recommended reading. Please see my profile for more information, and also for future updates.

<comment><USER42> On GitHub, you may want to check out [https://github.com/AppliedLogicSystems/ALSProlog](https://github.com/AppliedLogicSystems/ALSProlog)

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> You would probably realize pretty soon if you try writing anything meaningful with Prolog.

In my experience Prolog is conceptually the coolest, but practically the worst when trying to get anything done.

Basically, writing a program in Prolog is like solving a puzzle. Nobody wants to solve an additional "puzzle" on top of their already existing problem they set out to solve by programming. (Unless they're doing it for fun)

</comment><comment><USER44> I attended, but can't claim much comprehension of, Chris Martens' talk on logic programming at Strange Loop 2013. If you're interested in the world beyond Prolog, worth a watch.

[https://www.infoq.com/presentations/linear-logic- programming](https://www.infoq.com/presentations/linear-logic-programming)

</comment><comment><USER45> Some previous blog posts on this topic, from a few years ago:

"Who Killed Prolog?" by Maarten van Emden. [https://vanemden.wordpress.com/2010/08/21/who-killed- prolog/](https://vanemden.wordpress.com/2010/08/21/who-killed-prolog/)

Posits that the huge hype put into it by the Japanese Fifth Generation Computing Project, which it failed to live up to, essentially killed off interest in the language, which it never recovered from.

"Why did Prolog lose steam?", a sort-of reply I wrote. [http://www.kmjn.org/notes/prolog_lost_steam.html](http://www.kmjn.org/notes/prolog_lost_steam.html)

Posits instead that much of the low-hanging declarative fruit has been picked off by other, more specialized languages, ranging from SQL to production-rule systems to even LINQ, so Prolog no longer is the default go-to declarative programming language.

</comment><comment> nv-vn Having tried Prolog for a problem that it's relatively well-suited for, I found that all the advantages Prolog gives fall away very quickly. There's a lot of finicking around with weird organization of your code just to get things to work, despite being "declarative." For example, trying to rely on libraries to solve parts of the problem for you can be really strange because you can be 99% of the way to solving your problem, but not being able to edit/inline that code will create problems. As an example, trying to use a sorting function on an uninitialized list can't really do anything to help you, but if you inline that same code it can fix it because you're declaring properties of the list in-place.

<comment><USER46> >> trying to use a sorting function on an uninitialized list

That would give you an error, and rightly so. You can't really expect to sort what's not there. Or am I misunderstanding your comment somehow? I don't quite understand what you mean by "inlining" and how that can help sort a list of no-values?

<comment> nv-vn The way Prolog is "declarative" is that it bridges the gaps between assertions about the properties of a result and actions used to achieve those properties. For example,

        p(X) :- sorted(X).

is saying both (the imperative) "p(X) = sort(X)" and (the assertive) "a sorted X has property p(X)". To solve for P(X), one only needs to find an X such that X is sorted. This makes it difficult to say: "I expect input that, when sorted, has this property" because there is no clear meaning when X is uninitialized. Yet if you expand the meaning you can become "more explicit" about it and convince Prolog that what you're saying is true.

<comment><USER7> To express "I expect input that, when sorted, has this porperty", you have to use slightly more modern language features that are called _constraints_.

For example, let us _describe_ sorted lists of _integers_ :

        sorted([]).
        sorted([L|Ls]) :-
                maplist(#=<(L), Ls),
                sorted(Ls).

Here, I am using the CLP(FD) constraint (#=<)/2 that works correctly in all directions, whether or not its arguments are already instantiated to concrete integers. Such constraints are available in all widely used Prolog systems. You can try the above in GNU Prolog, for example.

Now the point:

Exactly as you say, the predicate works for _concrete_ lists of integers that are already given:

        ?- sorted([1,2,3]).
        true.

        ?- sorted([2,1,3]).
        false.

And _moreover_ , it also works if the integers are _not_ given, for example:

        ?- sorted([X,Y,Z]).
        Z#>=X,
        Y#>=X,
        Z#>=Y.

We can even ask for example:

        ?- sorted([X,2,3]).
        X in inf..2.

This means that _if_ this relation holds, than X is at most 2.

We can obtain concrete solutions with _enumeration predicates_. For example:

        ?- Vs = [X,Y,Z], sorted(Vs), Vs ins 1..3, label(Vs).
        Vs = [1, 1, 1], X = Y, Y = Z, Z = 1 ;
        Vs = [1, 1, 2], X = Y, Y = 1, Z = 2 ;
        Vs = [1, 1, 3], X = Y, Y = 1, Z = 3 ;
        Vs = [1, 2, 2], X = 1, Y = Z, Z = 2 .

And maybe most strikingly, we can also use this in the _most general_ sense, where we ask: _Is there any solution whatsoever_? The system _generates_ answers in this case:

       ?- sorted(Ls).
       Ls = [] ;
       Ls = [_28] ;
       Ls = [_170, _176],
       _176#>=_170 ;
       Ls = [_1194, _1200, _1206],
       _1206#>=_1194,
       _1200#>=_1194,
       _1206#>=_1200 .

Note that all these considerations lead us to the conclusion that "sorted" is a rather bad name for the relation, since it implies that "something has been sorted" and thus encourages a rather _imperative_ view. A better name would be ascending/1, denoting a relation that is true _iff_ its argument is a list of ascending integers, whether or not they are already known.

</comment></comment></comment></comment><comment><USER47> In my opinion there are mainly three reasons why Prolog is not popular.

The reason is that declarative languages in general are not as immediate as imperative languages. Nothing intrinsic about declarative languages themselves, this has to do mostly with the fact that we are taught and we are exposed to imperative languages first and then we hear about other more "exotic" paradigms.

Second issue. In a sense, the elegance of the language has been the biggest weakness. The academics loved to play with conceptual matters. A lot of effort went into papers on semantics and mapping different types of reasoning but not much into tools, IDEs, or compilers. The community didn't make enough libraries, built the right abstractions and software engineering practice. Every time you start a project in Prolog you are starting from scratch. Also, the elegance of the language is the reason a lot of people approaching Prolog get quite demanding. "It's logic programming so why do we have to use a cut?". Yet most programmers have no problems with the quirks of C++ or Java.

The third one is Prolog hasn't found it's excellence area. C, Go, Scala, Java all have their on strengths and scenarios where they are the best candidates. Prolog would make in theory an excellent candidate for representing complex domains based on rules, covering a module of a larger piece of software. It would be perfect to represent the rules of a board game or the knowledge of a chatbot, but for a number of reason that's no happening. How does the reasoner scale with larger datasets? Will it be hard to manage? Is there an example of something similar being attempted?

In my very personal opinion, as a community we should learn from these lessons, take the best bits of Prolog and make something new. At Grakn.ai ([https://grakn.ai/](https://grakn.ai/)) we are working on a graph database that uses an inference layer that is based on Prolog's resolution, maybe worth having a look. The idea there is that Prolog maybe shouldn't become a great general-purpose language but its bests parts must be used as a base for the next advances in knowledge representation and reasoning.

<comment><USER7> Grakn was also recently posted on HN:

[https://news.ycombinator.com/item?id=14471238](https://news.ycombinator.com/item?id=14471238)

In that thread, I show how you can express the sample relation in Prolog. Maybe you can go into more detail, either here or in that thread, on the advantages of Grakn over Prolog for such cases?

<comment><USER47> Someone from my team replied. Thanks for taking the time to start the discussion on the comparison, we have a few people with a computational logic background here and we plan to publish a blog post on the topic soon!

<comment><USER7> Perfect, I am looking forward to reading the blog post! I hope it will also mention Prolog as an important influence.

As to your second issue above: Please note that there are _many_ collections and even entire books that describe _antipatterns_ of Java, C++ and many other programming languages. In my experience, programmers from these communities quickly learn to avoid these antipatterns. In the Prolog community, this happens more slowly, but it does happen too. There are very good reasons to avoid !/0 and other impure constructs in logic programs. In my view, the key issue is to find and teach better constructs that should be used _instead_ , and the best alternative language constructs are still waiting to be discovered.

In this spirit, I fully agree with you that we should keep Prolog's best aspects, and extend them as far as we can into the directions we need.

</comment></comment></comment></comment><comment><USER48> Perhaps what is needed is a Prolog-derivative language which is nicer to use. There is a number of declarative languages available, but my personal favourite would be Picat [http://picat-lang.org/](http://picat-lang.org/) A disadvantage of Picat would be though that unlike SWI Prolog, it doesn't have any sort of package management system, and doesn't have a general means of using FFI to call into C libraries.

<comment><USER7> Picat is a very interesting development. Note though that it, at least currently, omits some key features of Prolog such as the _homoiconic_ syntax, and definite clause grammars (DCGs).

</comment></comment><comment><USER49> I couldn't find much use in Prolog when I tried it. At first it was neat how you could express simple problems, then I learned how one used ! for everything else. It felt like instead of working on a solution, I had to work on what the solution isn't.

It's a very specialized system in my view, so there is no hope of it ever becoming general-purpose. But maybe that's because I don't know enough of Prolog.

<comment><USER7> Have you been exposed to more recent research on Prolog language constructs?

In particular, I recommend the following publication:

[https://arxiv.org/abs/1607.01590](https://arxiv.org/abs/1607.01590)

if_/3 and other declarative predicates like dif/2 are more general alternatives and likely good solutions in the cases you mention. They are still quite recent, at least if we ignore the fact that dif/2 was even available in the very first Prolog system, sometimes called Prolog 0.

</comment></comment><comment><USER46> Prolog is already a general-purpose language. So is any Turing complete language, by definition. Whether it's a "great" such language or not is kind of a personal tastes thing.

As to why it's not more popular, I've thought about this very ofen and I don't have an answer. What I know for sure is it's never going to become more popular until people move on from that silly soundbite about its "general purpose"-ness, which never made any sense to begin with.

People program "general purpose" stuff in languages that are much worse for "programming in the large" than Prolog. Most of the big operating systems are written in C, large swathes of game code is in some assembly language or other, about 60% of enterprise code is in Java and most supercomputing code is in FORTRAN fer chrissake. Not to mention, all of the internet is in javascript, a language that was originally meant just for writing small snippets of code to manage buttons and text fields and stuff. You're not going to tell me that javascript is "general purpose"?

Prolog is already a general-purpose language. All you need to do is have a look at the library section in the Swi-Prolog documentation. Besides the usual suspects (constraint logic, tabling, lambdas and such and of course parsing all possible text-based formats ever in time dt) we find a bunch of diverse libraries:

An http package for all your client/server needs [1]

A library for opening web-pages in a browser in a system-agnostic manner [2]

A library for command-line parsing [3]

An RDF parser and a semantic web library

A package manager [5]

A random numbers generation library

A library for manipulating the Windows registry [7]

A library for solving linear programming problems [8]

A thread pool management library [9]

And a whole lot of support for a bunch of other stuff like corouting, multithreaded applications, a profiler, terminal control, an ODBC interface, an interface to Protocol Buffers, bindings to zlib, GNU readline, and so on and so forth.

In what sense is all that not "general purpose"?

______________

[1] [http://www.swi- prolog.org/pldoc/doc_for?object=section(%27pa...](http://www.swi- prolog.org/pldoc/doc_for?object=section\(%27packages/http.html%27\))

[2] [http://www.swi-prolog.org/pldoc/man?section=www_browser](http://www.swi- prolog.org/pldoc/man?section=www_browser)

[3] [http://www.swi-prolog.org/pldoc/man?section=optparse](http://www.swi- prolog.org/pldoc/man?section=optparse)

[5] [http://www.swi-prolog.org/pldoc/man?section=prologpack](http://www.swi- prolog.org/pldoc/man?section=prologpack)

[7] [http://www.swi-prolog.org/pldoc/man?section=registry](http://www.swi- prolog.org/pldoc/man?section=registry)

[8] [http://www.swi-prolog.org/pldoc/man?section=simplex](http://www.swi- prolog.org/pldoc/man?section=simplex)

[9] [http://www.swi-prolog.org/pldoc/man?section=threadpool](http://www.swi- prolog.org/pldoc/man?section=threadpool)

<comment><USER50> GPs issue seemed to be that it wasn't a great or popular language for general use, not that it isn't a general purpose language.

<comment><USER46> The question asked is "what would it take for Prolog to become a great general-purpose language". That sounds like they think it isn't. If that wasn't meant OK, but that's definitely what it reads like.

<comment><USER50> Yes. The mistake is thinking "is not currently a great general-purpose language" implies "not currently a general-purpose language".

<comment><USER46> Sorry, but that's not a mistake. That's the common-sense reading of the title. Your reading is much less likely.

<comment><USER50> Your reading makes the word "great" superfluous. Its not "common sense" to read a qualifier out of the question asked.

<comment><USER46> That _literally_ is what common sense is _all_ about.

</comment></comment></comment></comment></comment></comment></comment><comment><USER51> If you're into Clojure et al or at least datomic you've probably used some subset of prolog (qua datalog).

Clojure also brings with it logic and relational programming which is likely the go-to choice of the Clojurist for expressing work-flow or permissions management type problems. Not exactly Prolog but it's the same difference.

</comment><comment><USER52> Is there a particular book that covers Japan's 5th generation fiasco, from a technical point of view?

<comment><USER7> I once asked a retired Japanese computer scientist why the 5th generation project had failed. He said: "What do you mean 'failed'? All my former colleagues who had worked on this project went on to become full professors!"

Also, I once attended a talk by a Japanese researcher who was intimately involved in the project. One significant phenomenon at that time was that commodity hardware was progressing much faster than had been anticipated, in the end eclipsing the specialized designs that were being worked on.

There are other reasons too, and here I can only say that Prolog as it is today had very little to do with the outcome. In fact I think this would be a great follow-up question to the present discussion!

<comment><USER10> "One significant phenomenon at that time was that commodity hardware was progressing much faster than had been anticipated, in the end eclipsing the specialized designs that were being worked on."

This is exactly what happened. A slow language like Prolog on OK hardware that accelerates it can't compete with a fast language like (not-Prolog) on highly- custom, top-of-the-line hardware that accelerates it. It can't in the general case and plenty times not in the special case. Now, that was when Moore's Law was in full swing. There's potential now for that pendulum to swing in reverse for something like this.

</comment></comment></comment><comment><USER53> 1\. 2\. There were too many fully incompatible dialects of Prolog. I recall Lisp-like Micro-Prolog. Turbo

</comment><comment><USER54> I've wanted to use Prolog in JavaScript and Java projects before but I could never find robust Prolog implementations for either. I wouldn't want to use Prolog for a GUI or be tied to binary implementations of it but it has its uses.

</comment><comment><USER55> Because its only first order so its really tedious. So you can say that if a > b and b >c then a > c, but you can't say if a op b and b op c implies a op c then op is transitive.

<comment><USER7> This is not the case: Prolog has several _higher order constructs_ like the call/N family of predicates, maplist/[3,4] and foldl/N.

Your particular example of transitive relations is one of the most elementary examples that are typically solved in basic Prolog courses as exercises, when defining _reachability_ : B is reachable from A if there is an arc between A and B. Transitivity can easily be defined by a rule, as you correctly mention. For instance, let us take your example:

      fact(a > b).
      fact(b > c).

      transitive(A, B) :- fact(F), F =.. [_,A,B].
      transitive(A, C) :- fact(F), F =.. [_,A,B], transitive(B, C).

Here are all solutions:

        ?- transitive(X, Y).
        X = a,
        Y = b ;
        X = b,
        Y = c ;
        X = a,
        Y = c ;
        false.

Note that the operator ">" is _not_ mentioned in the definition of transitive/2\. Instead, I am using the meta-predicate (=..)/2 to reason about _all_ functors that can arise, making this a quite general definition of transitive relations.

We can also reason explicitly about the relation, by making the functor (which may, or may not be defined as an _operator_ ) available as a predicate _argument_ :

      transitive(Op, A, B) :- fact(F), F =.. [Op,A,B].
      transitive(Op, A, C) :- fact(F), F =.. [Op,A,B], transitive(Op, B, C).

Now we can ask queries like:

        ?- transitive(Op, X, c).
        Op =  (>),
        X = b ;
        Op =  (>),
        X = a ;
        false.

and also in the other direction:

        ?- transitive(Op, a, Y).
        Op =  (>),
        Y = b ;
        Op =  (>),
        Y = c ;
        false.

And we can also ask in the most general way possible, where all arguments are fresh variables.

</comment></comment><comment><USER56> Because it's more appropriate as an embedded DSL, or low-level on which to create a DSL, than a general programming language?

</comment><comment><USER57> You don't use a _language_ , you use a _compiler_ and a _runtime_.

Maybe prolog has just not found the right context to run in?

</comment><comment><USER58> Take a look at ASP (Answer Set Programming) For me it worked a lot better than prolog

</comment><comment><USER59> IMHO, SAT/SMT solvers does mostly the same, so why would you designate separate PL for this task, when you use these tools or libraries?

<comment><USER7> SAT is about a very special case of logic, namely _propositional_ logic, where every variable stands for exactly one of only two possible truth values. Finding satisfying assignments in propositional logic is indeed already a computationally hard task, and it is good that we have efficient SAT solvers for such use cases, allowing us to solve a large variety of combinatorial problems nowadays.

However, Prolog lets you tackle not only propositional logic, but tasks that go far beyond this, belonging to a logic called classical _first order_ logic, of which propositional logic is only a subset. In first order logic, we reason about predicates _between_ terms, and this lets you tackle much more complex tasks, far beyond what SAT/SMT solvers can solve for you.

In fact, first order logic is so powerful that it lets you describe everything you can _in principle_ perform with a computer. It lets you describe how a compiler works, for example. Or how numerical integration works. And all other computations you have ever seen computers perform.

In short, Prolog is a programming language, and can in fact even be used to _implement_ a SAT solver, which is impossible to do with just a SAT solver. Many Prolog implementations even _ship_ with a SAT solver as one of their libraries.

There are also even higher-order constructs in Prolog, such as predicates that let you invoke _other_ predicates, making programming in Prolog very expressive and convenient.

<comment><USER11> > first order logic is so powerful that it lets you describe everything you > can in principle perform with a computer

Not quite sure what you're referring to here, but induction schemata seem to be a notable exception. There's a reason higher-order logic is often preferred for software verification.

I guess FOL is adequate if you're allowed to have an infinite number of axioms, but that doesn't seem very satisfying (pun intended).

<comment><USER7> I am referring here to the fact that first-order logic is sufficiently expressive to describe how a Turing machine works, making FOL Turing-complete and thus, as a special case, making every computation you can carry out on a computer expressible in FOL, as a first-order formula that is satisfiable _iff_ the TM accepts the input.

</comment></comment></comment></comment><comment><USER60> Short answer: because intelligence isn't about solving propositional logic.</comment>


ODesk offers benefits plans - <AUTHOR> http://www.odesk.com/w/benefits

<comment><AUTHOR> I think this is a great move on their part. My company uses oDesk. We have a large pool of contractors through them for human judgements, but also outsource some non-critical development to oDesk contractors.</comment>


Righthaven.com Taken Down for Invalid Whois - <AUTHOR> http://www.domainnamenews.com/legal-issues/righthavencom-invalid-whois/9232

<comment><USER2> While I am in NO WAY defending Righthaven (they had it coming, really), these draconian domain rules are ridiculous. Having to pay £5 (or whatever it is now) to hide your personal information on your domain is truly evil.

But obviously Righthaven doesn't care about their domain because if I recall correctly, GoDaddy sends three notifications before they suspend your domain.

<comment><USER3> >Having to pay £5 (or whatever it is now) to hide your personal information on your domain is truly evil.

Eh, when the domain name system was set up, it was designed with businesses and academics in mind. People who don't expect or want to be anonymous. The idea was that individuals would get services through a provider's domain, so the whole system assumes less privacy than one would expect out of a product one uses to run one's own email.

Really, I would personally be happy to give my customers a discount if they were willing to post contact info publicly. I mean, I wouldn't force the issue, because I know a lot of my customers really do want privacy, but my costs for hosting someone who says "hey, this is who I am, send abuse complaints to me" through rwhois on the IP or the like, and who handles those complaints without my help are lower than my costs otherwise.

I mean, I certainly understand and think it's okay that some people want to be anonymous, but you need to understand that you put yourself in a more expensive group by wanting that anonymity.

Now, is that 5 pounds per customer worth of 'more expensive' for a domain registrar? probably not. Abuse expenses are a little like insurance... 99% of your customers won't get any complaints, or the complaints they get will be resolved painlessly, but a few will be quite painful and eat a lot of time and money. (unless you take the 'kick off everyone who complains' approach.)

I haven't implemented such a 'discount for using your own realname and your own abuse contact' yet, in part because I'm afraid customers will see it as anti-privacy, so I'm still feeling out the idea, I'm just saying, there is an economic justification for it.

</comment></comment><comment><USER4> As much as RightHaven might have been asshats, this sort of precedent concerns me.. I've had domain information that has been _years_ out of date before I realized it.

I wonder what degree of "correctness" they need.. if I leave off an apartment number, is that bad enough? If I renew for 3 years and don't bother updating in there, can I get shut down?

<comment><USER5> Worry about your e-mail address and keep it functional and responsive. They don't care about an apartment number.

<comment><USER4> But technically an apartment number being wrong is also "invalid whois information." If it's just selective enforcement, that's a whole other pain.

<comment><USER6> The apartment analogy is .. erm "apt". Why do we effectively rent domains, and not really own them?

</comment></comment></comment></comment><comment><USER7> Uh oh, this could be a bad sign of things to come for grey/black hat SEOs. Providing invalid WHOIS information is common practice among SEOs because it can help boost rankings when it appears like all your interlinked sites don't look like they are owned by the same person. If this is the beginning of a crackdown, there will be more drama to come.

<comment><USER8> There's no evidence of a crackdown, or even if there were, the fact that they were able to nab a rather notorious troll doesn't mean black hats who have been keeping their heads down will be vulnerable.

</comment></comment><comment><USER9> Wow, I get emails every week about updating my details but this is the first time I've ever seen a domain taken off because of it

<comment><USER10> If the email sent doesn't bounce, then it doesn't necessarily raise a flag.

</comment></comment><comment><USER5> Wonder what was invalid. E-mail bouncing, maybe?

        Last Updated on: 12-Feb-11

        Administrative Contact:
            Gibson, Steven  email@example.com
            Righthaven LLC
            9960 West Cheyenne Avenue
            Suite 210
            Las Vegas, Nevada 89129
            United States
            +1.7025275900      Fax -- +1.7025275909

Slow down, there is no bad precedent here since black/gray SEOs know the risk when they falsify WHOIS data. Domain seizure for falsifying WHOIS has gone on for a long time. Every registrar reminds you of it constantly and it is your responsibility to keep it updated. There is not much active checking either (if any) and in my experience domains are only taken if they are actually reported through WDPRS and even then it is a long shot.

I dont think GoDaddy would suspend a domain without repeatedly trying to contact the registrant either and if they do, time to move. Make sure the e-mail details at your registrar and on your domains actually work, respond to them, and you should be fine.

This makes a case for not having your domain registration e-mail be handled by that domain too</comment>


US imposes new tariffs on $200B of Chinese goods - <AUTHOR> https://www.bbc.co.uk/news/business-45555749 <comment><USER2> I have a sideline building open source hardware, I build and warehouse in China and sell all over the world .... I don't see these tariffs, I don't send the US govt money each time someone orders something, I just send stuff by mail to customers, they're the one doing the importing and end up paying local taxes in whatever country they live (just as I pay taxes importing stuff here in NZ when appropriate).

People seem to forget that this is a really just a new tax that's being paid by Americans

<comment><USER3> Agreed. However do you see the 'retaliatory' tariffs imposed by China? At least, I hear from US media that China is apparently imposing similar tariffs, wondering if the categories are similar (or if they even have as large an impact as the US ones).

<comment><USER4> These tariffs aren't new to China however. Do import duties ring a bell? Countries like China and India have been imposing (and raising) them on various products for many reasons (mostly protecting local industry, generating employment, etc).

Import duties in the US however, have been relatively non-existent. To give you an eg: A non local made car that costs $60k in the USA costs $150k++ in India (and duties make petrol here more expensive too).

</comment></comment></comment><comment><USER5> Is there a simple chart somewhere that shows what are the old and new tariffs for the most commonly imported items. I'm just confused with hearing these large generic tariff news. Something like PCs- was 10% now 25%, Tshirts- was 10% now 50%, etc.

<comment><USER6> This looks like something NYT will come up with soon. They usually make pretty good infographics

<comment><USER7> meanwhile other recent tariff deltas available here: [https://www.usitc.gov/tariff_affairs/tariff_databases.htm](https://www.usitc.gov/tariff_affairs/tariff_databases.htm)

</comment></comment></comment><comment><USER8> Can someone explain in plain English what the actual consequence of this will be?

<comment> village-idiot Goods that are purchased from China will rise in price. If China decides to retaliate, and they will, anyone who sells to China will see sales drop and losses pile up. Since the Chinese are likely to target based on American politics (think rural red states), the US government will probably step in and offer emergency loans or cash if it gets bad enough, pushing US deficits higher.

There will also be some strange third order effects for Europe and other trading partners, but it's beyond my skill with economics.

<comment><USER9> China will quickly run out of American exports that they can selectively (politically) tariff. In fact, they will eventually run out of ANY goods that they can tariff that are not already already tariffed much before the US does due the huge trade imbalance.

<comment><USER6> But the US has a trade surplus over China in Services exports into China. Presumably those will get tariffed.

Also, US made products that relied on chinese intermediate products will go up in price, passed on to consumers.

Those same US products will not be export competitive in other countries (because input costs increased with tariffs) and thus China can now export to places that US used to export to.

Trade is not that simple and usually needs negotiations to be win-win.

<comment><USER10> "Goods exports totaled $129.9 billion; goods imports totaled $505.5 billion. The U.S. goods trade deficit with China was $375.6 billion in 2017."

"Trade in services with China (exports and imports) totaled an estimated $75.0 billion in 2017. Services exports were $57.6 billion; services imports were $17.4 billion. The U.S. services trade surplus with China was $40.2 billion in 2017."[0]

Seems to be an order of magnitude of difference, setting aside possible tariff rates.

[0] [https://ustr.gov/countries-regions/china-mongolia- taiwan/peo...](https://ustr.gov/countries-regions/china-mongolia- taiwan/peoples-republic-china)

<comment><USER6> And after the tariffs what do you expect will happen to goods and services going from the US to China?

<comment><USER10> I expect prices to go up (across the board on such goods) in China, and US companies who are more price sensitive will get hit harder on their upcoming 10k's than others, predictably.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I find it funny and scary that the US think they can win a trade war. The only outcomes I can see is 1) China wins 2) it ends in war because why the hell not. Everything the US does ends in war.

<comment><USER12> You dont understand China. Just as one example look at baby formula situation.

</comment></comment><comment><USER13> I'm having a surprisingly difficult time finding a nuanced view of these policies. On the one hand, china is taking advantage of us and is in part rotting our our middle class and blue collar workers. On the other hand, this could spark economic turmoil. Can anyone chime in here? Or is this beyond the scope of economics? (Not to dig on the field, bit we were told NAFTA we be great, look at the poverty in Mexico as a result.)

<comment><USER14> The consensus among economists is that it's a terrible idea which will hurt everyone. Often this sort of trade war is a precursor to real war.

Trade is not a zero sum game.

[https://www.bloomberg.com/news/articles/2018-05-02/economist...](https://www.bloomberg.com/news/articles/2018-05-02/economists- invoke-great-depression-in-warning-to-trump-on-trade)

<comment><USER13> The people enacting these policies (Trump admin) argue that what we currently have is not trade, given how the Chinese have manipulated the markets, it is a one sided agreement. Free trade requires both sides not place restrictions on the others. Would you say this is true? Sometimes I feel like economic theory is like psychology, it seems real, seems like it has truth, but counter examples are abundant?

<comment><USER15> It's indeed not free trade, since the playing field is tilted massively in favor of the US, by controlling the global currency.

</comment></comment></comment></comment><comment><USER15> This will hasten the move away from the dollar.

I hope that this allows the EU to trade prime matters and other goods in Euros, since interests are alligning perfectly.

</comment><comment><USER16> This actually looks like the start of the distanglement between the US economy and the Chinese economy. What will likely happens next (my best guess) is

1.) 40-60 percent of a company's supply chain moves out of China

2.) China restricting the movement of capital/equipments out of China (similar to what happened with Korean companies last year)

3.) China growing homebrew competitors to the foreign companies leaving, part of the 'made in 2025 in China' strategy, via state enterprises or state spendings in startups. China will also make US companies' operation in China very hard, either with license restrictions, or increased local ownership.

4.) China will disincentivize Chinese consumers from purchasing US (or foreign) products. Via propaganda, state media, others. This would be hard, as Chinese consumers prefer higher quality, higher brand value, and higher perceived value products.

5.) China will have to target US farmers with tariffs, as there isn't much US imports to tax otherwise. Plus, there is the face saving situation.

6.) US will increase the tariff coverage to all Chinese imports, either triggered by tariffs on US farmers, or any other targets.

7.) China local governments will make a mistake of seizing a US owned corporate asset, or prevent a factory from shutting down by its owners. This will escalate the urgency for US companies to move out of China.

8.) 70-100% of company's supply line will be out of China

9.) Eventually, most direct trades between both countries shrink. Down to a significant level where it starts to drop gdp for both countries (China way more than US)

10.) China will have no choice but to embrace its lost decade, ala Japan. It will tighten controls on its citizens. It will try to contain high inflation and high unemploment rate. It will try to unwind its debt for the next 10-20 years.

</comment><comment><USER17> Is anyone here curious about where the tariffs income will be spent?

<comment><USER6> Bailout (buying votes) for more farmers who will lose export markets?

<comment><USER17> For me protectionnism could be a good thing environmentally like adhelas said. It could be a good measure if you use this tariffs to improve equality, distributing this equally through the population. Sadly nobody knows here the income will be spent.

<comment><USER15> How is equality achieved towards the Chinese workers?

<comment><USER18> By reducing imports from China, China will need to invest in their local market too and by doing that they will need to improve chinese worker conditions.

<comment><USER15> Great. I hope the EU follows through and reduces US services imports to strengthen the local economy.

I thought trade was good? Haven't I been hearing that from US officials for over 50 years?

<comment><USER18> Yes, and in the last 50 years carbon emissions have skyrocketed, while wages have stagnated. We are depleting the resources of the planet and polluting at an unbearable pace. We have to change the economy and protectionism for me can be a good measure. If protecting the environment or health is good, why is protecting the economy bad? What is the opposite of protecting? attack? If so, why does protecting something lead to a trade war? should not it be to attack an economy? This area is full of self-righteous words like "free market" or "trade war". We cannot question something that is free? And a war is something that has to be fought at all times? We need to see through this.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Some, maybe dumb, thought.

Imposing tariffs and therefore reducing the goods that are transiting to (and from) the US across the globe is not, indirectly, ecologically good?

Less goods transiting, less transport to bring them across oceans, less container ships, less oil…

<comment><USER15> This applies to trade in all directions.

Funny how the US has been advocating for trade while it was "winning" (read, giving worthless papers for real goods). Since now we are hitting a wall (competing economies asserting themselves, and willing to be freed from the dollar), and since the US prsident seems to disregard, or not aware, of the massive advantage that the dollar means for the US economy, a trade war has been started.

This war will either be won by the US on the short term, or the dollar will be dismissed as international currency.

<comment><USER20> > giving worthless papers for real goods

> This war will either be won by the US on the short term, or the dollar will > be dismissed as international currency.

Remind me what the Yuan, Yen, and Euro are backed by? Or are you saying that the world will go back to the gold standard?</comment></comment></comment>


Scaling Guild Wars for massive concurrency - <AUTHOR> http://www.codeofhonor.com/blog/scaling-guild-wars-for-massive-concurrency?

<comment><USER2> Always enjoy these articles. I do think that the simulation strategy deserves a bit more discussion, and the pitfalls of replays are glossed over slightly.

Simulating players gives you the benefit of end-to-end testing much more easily (for example, it tests your login flow and disconnect flow, both of which are often written without much care for performance). It also practically demands that you write a scripting console for your game, which is an invaluable resource for error testing, debugging and development both by your engine and content developers. It's true that human players are more unpredictable than bots, but that's not a drawback, because you want to stress-test the hottest part of your game. For these purposes, you can write a small test level (think an arena) and have bots spawn at either end and run towards each other, attacking until they die. This isn't at all representative of how players will play the game but it will very definitely catch performance regressions.

Replays depend on two factors, deterministic playback and unchanging content. Deterministic playback is possible (though extremely difficult) to achieve, but it really has to be a priority from the beginning, and it has to have its own testing suite and fixing regressions has to be a priority. It's impossible to retro-fit it onto an existing game (sometimes by design, as non-determinism occasionally is mistaken for randomness). Unchanging content is, obviously, unlikely to happen during development and is much more likely to be possible during betas, but during those time periods you have much more time to devote programmer and content developer time and attention to ancillary features like expanding bot programming.

<comment><USER3> The upside for the simulation problem is that many multiplayer games have something approaching bot AI to begin with - enemy AI - so you can use that as a starting point for those sorts of tests. I'm not sure if that was ever done at scale for GW testing, but it would have been possible...

My understanding is that the replays were possible because the game engine was architected from the beginning with the server 100% in control of game events and the clients relying on message-passing to communicate with the server. This means that the recording captured on the server is a definitive recording of what actually happened in the game. Clients could desync, so a replay might not reproduce that, but otherwise they were pretty accurate.

I'm not sure how the unchanging content problem was solved. I think everything was revision-controlled aggressively enough that it would have been possible to set up a local server instance using old content, and it's also possible that most ordinary changes (altering a texture, a map, etc) wouldn't actually change the results of a replay. Definitely a challenge, though.

Replays came in handy later on for other features (like letting players watch others' PvP matches in-game) so they probably ended up carrying their weight in terms of development effort. I do wonder if they felt like a burden initially, though, before their value became clear...

<comment><USER4> Dealing with the many scenarios that could break replays was problematic, but being able to run several instances of the same game at the same time and compare them occasionally for desyncs can help alleviate that. For example, using a pointer value (address) as a hash table or sort key means that depending on allocation order, iteration of game entities may be different from one run to another.

</comment></comment></comment><comment><USER5> Great read.

I disagree with him on bots, though. CCP has a highly evolved bot system which is tied into their build system, so that unit tests can include player behavior. This isn't directly relevant to load testing (although CCP does that with bots as well), but it certainly demonstrates why bots are worth the effort.

And if you've got a full-fledged QA department, bot writing is a good QA engineer task. This is also a decent way to give ambitious QA guys a coding task that doesn't have the potential to affect customer-facing game play.

Without violating NDAs I can say I've worked at MMO companies that found bots invaluable for load testing. Replays will definitely catch things that bots won't, but if you're thinking about how many players you can fit in a zone, etc., etc. bots are great.

<comment><USER4> Pat's speaking for himself here, of course, as evidenced by the fact that bots were crucial for load testing GW2 (they ran on Amazon EC2, even, so that they could scale dramatically high.)

</comment></comment><comment><USER6> A very interesting read, but I'm missing one step:

Game recording is established as a favorable way to make games better, to avoid a crappy beta experience or problems right after launch.

How are you going to get decent recordings in the first place? Playing with a couple developers seems a lousy way to jump start a good selection of games, is it? How is this chicken and egg problem solved? I miss a way to bootstrap the process, load a good set of (varied, representative) replays?

<comment><USER2> A game the scale of GW will have a dedicated QA department with at least a half-dozen testers, who are constantly playing the game anyway.

<comment><USER3> This is pretty much exactly how it worked when I was there. I imagine when the team was smaller, they leveraged a combination of developer recordings + recordings from volunteer testers (the game had a group of volunteer testers in the high hundreds by the time I started working on it).

In particular QA recordings got used a lot to reproduce particularly tricky bugs and race conditions, since players usually weren't savvy enough to spot them.

The volunteer tester group was also useful for load testing, since it gave us a way to throw a hundred or so players at one of our development servers and record all of them simultaneously. It gave a reasonable approximation of what the load might look like on a single production server and it meant we could also capture recordings of how the servers (and clients) behaved under load instead of just having 4-8 developers playing on them.

<comment><USER5> Any comments on the infrastructure for capturing the replays? Did everything get recorded? I'm used to recording all actions, ability uses, etc. but recording movement isn't something I've seen done all that often and it seems like it'd be another order of magnitude of data.

<comment><USER4> Think of a web server with a fresh SQL database with no data (other than whatever is pre-populated there by the installation.) Simply record all incoming messages to the server over a period of time and save it to disk. Then, when you want to replay that recording, start with a fresh database again and replay all the messages. Assuming your system is deterministic (no race conditions, generally not relying on a wall clock [there are tricks for this, since it's a harder problem[1]]) and you're good to go. The key is designing everything to support this from the beginning.

[1] Done right, you can play a minutes long recording back in seconds, which is very useful for trying to fix a bug and verifying it against a known-bad replay.

</comment></comment></comment></comment></comment><comment><USER7> I was confused about the part where he mentions a rack full of 1Us was generating too much heat and the solution was to put less servers in a rack. I can't think of a situation where there is nothing at fault besides the servers. The chillers should be able to keep up with 1Us like that, and it's likely there was something else going on.

The situation we're running into at my job is with double density servers (i.e. Dell C6105's). The problem we're having with heating double density servers. Maybe somebody with more experience than me can explain why cooling 1Us would ever be a legitimate problem?

<comment><USER8> "I can't think of a situation where there is nothing at fault besides the servers. The chillers should be able to keep up with 1Us like that, and it's likely there was something else going on.

...

Maybe somebody with more experience than me can explain why cooling 1Us would ever be a legitimate problem?"

The situation in server labs, hardware and infrastructure-wise was much worse seven years ago. Is it that hard to imagine?

<comment><USER7> I was in high school 7 years ago so yes, it is hard to imagine because I really don't know how things used to be. I do appreciate the condescending tone though.

<comment><USER8> It wasn't consdescension, the design and supporting environment really was that bad.</comment></comment></comment></comment>