14 comments

[ 3.3 ms ] story [ 39.0 ms ] thread
The response by jan makes a point that I think should be more widely appreciated:

>> Learning any language in enough depth will take time away from learning something else. So you need to figure out your priorities first.

> I doubt that will hold. In my understanding (but I might be wrong) this has been disproved for natural languages, i.e., (most) children learning more natural languages do not perform worse on their mother tongue except for a brief period were they tend to mix languages.

> Likewise, learning Prolog provides you with a different perspective on programming that, once understood, can be applied to other languages as well. For example, I tend to put a lot of “knowledge” in data structures and use a small program using this data to do the job rather than using endless if-then-else, also when programming in C or JavaScript (my main imperative languages).

I'm reminded of Richard O'Keefe's comment, in the context about a decision about which PLs to teach in 1992, "Rob Hagan at Monash had shown that you could teach students more COBOL with one semester of Scheme and one semester of COBOL than you could with three semesters of COBOL."

https://news.ycombinator.com/item?id=28337973

That quote is spot on. My university is currently experimenting with a course called "programming paradigms" which focuses on functional and logic programming and comparing them to mainstream paradigms (procedural, object-oriented). I think it's a great idea to have such a course on first year.
> In my understanding (but I might be wrong) this has been disproved for natural languages, i.e., (most) children learning more natural languages do not perform worse on their mother tongue except for a brief period were they tend to mix languages.

More than that, for each related language you learn, the nth additional is easier. After French, Italian and Spanish, you will be able to read Portuguese almost fluently, without any specific study. People like that who write/speak often do mix things up, admittedly. But it tends to go away with regular exposure. To carry forward the metaphor, I'd argue most if not all computer languages are closely related in the same way Spanish and French are.

I can't find it but I remember reading an interview with Phil proctor from the firesign theater. After firesign, he went on to do a lot of voiceover work and specialized in languages and accents. He said that for him once he had a few languages under his belt, the other ones all came very easily, even the ones with really distinct lineages, not just the romance languages.

I kept this in mind as I've continued my education in computer programming, and it's true. Once you get familiar with three or four different languages, even the weird ones come a lot easier.

Like every $LANGUAGE in every $YEAR:

- because you need it,

- because you want it.

Simply this. Different languages are different tools for different applications. If your application requires or would be easier to write/read or perform better in some fashion in a given languages, then (in my opinion) its worth it to learn the language
Prolog is a declarative programming language. If you haven't tried it a bit already, you probably won't realize where it would be useful. I've seen that with friends on side projects, writing complicated rule resolver engines that they'd get for free if they embedded prolog into the project.

So you might consider learning the tool enough to understand when and where to deploy it.

After a substitution:

> Like every Python in every 2021.

Learning Prolog for "mind expansion" feels weird in 2021.

As a language (at least SWI-Prolog), it's missing some niceties that I took for granted: e.g., a function's output is always to a C-style output variable, all "context" variables must be passed around in recursive calls, etc.

There are several well-regarded books on Prolog that also feel quite antiquated in their concerns: authors taking pains to build elaborate conventions around function naming and argument ordering, etc.

Aside from its unusual features, Prolog really feels like a language from the early 90s, with a small, static standard library you might memorize, and authors offering "helpful tips" around functions with slightly different names in "commercial systems."

I think it's incorrect to think of prolog's execution model in terms of "functions" and "output". So I don't think the nicities you're hoping for are applicable in prolog (at least not in their straightforward definition).

Though I agree that prolog seems like it came from the 90's; I especially agree with that "functions with slightly different names" bit.

O'Keefe's The Craft of Prolog happily describes function arguments as "input" and "output." I'm taking the liberty to say "function" instead of "functor," because the latter is more obscure. And there absolutely is a distinction between conceptual inputs and outputs, because many functions can find instantiations only for some arguments and not others. For example, I can query `length([a, b, c], N)`, but not `length(X, 3)`.
Eh? Your Prolog system must be broken…

?- length(X, 3).

X = [_1586, _1592, _1598].

?-

Very well, if you insist on ignoring the broader point in favor of the specific example, then replace `length` with `is`. We can unify `X is 3 * 3`, we cannot unify `9 is 3 * X` (at least not in SWI-Prolog v8.4.1). Therefore, we can call the thing to the left of `is` the output and the thing to the right of `is` the input.