Erlang's syntax isn't representative of Prolog's. It was originally implemented in SICStus, sure, but Prolog lets you add your own operators, and Erlang added a

Erlang's syntax isn't representative of Prolog's. It was originally implemented in SICStus, sure, but Prolog lets you add your own operators, and Erlang added a ton on top of the (rather clean) Prolog syntax. How would Ruby (or whatever syntax you like) look if you made a DSL by adding every operator that wasn't already in use? You know all the problems with the ambiguous ; , . stuff that Katz gripes about in that post? Prolog terminates every clause with a period, and all related rules just occur in sequence. Prolog has a read function, much like read in Lisp - "read the next complete (s-expression|Prolog clause) from stdin". The original Erlang compiler needed to read all of the alternative clauses for a function in one go* , so they strung them together with "," and ";", which are Prolog's and and or operators. (They could have fixed this when they started self-hosting, but probably had other priorities.) In practice, it isn't a problem (and Erlang has many perks to make up for those minor syntactic irritations!), but that can't be blamed on Prolog. It's sort of like if you used Lisp's (read) to load more expressions, but since your compiler needed you to read a whole module at once as an implementation detail, you used [ and { pairs instead of parens. Yuck! In Prolog, that sort of code looks like this: parent(terach, abraham). parent(abraham, isaac). parent(isaac, jacob). parent(jacob, benjamin). Note the conspicuous lack of semicolons. * I'm reading between the lines here, so if Robert Virding swoops in and tells me I'm wrong, Hello Robert! :) If anything, the reason that Prolog isn't good for entire applications is that it's fundamentally a rules/database query language. It's awkward for stateful / procedural code, but if you treat it like (say) a much more sophisticated SQLite, it will be good to you.