Getting Started With Scryer Tutorial

[dougransom]

A guide for new to Prolog or new to Scryer to get started. Covers a few simple things that might help newbies save some time.

[Skgland]

Getting started might also be a good place to list toplevel keybindings i.e. #3155 / #3154

[jjtolton]

So @dougransom I think this is well intentioned but you might not realize that you walked into a minefield. The school of thought that Scryer Prolog belongs to is the absolute strictest there is, and there will be no compromising on that. I have jokingly referred to it as "Vegan Prolog" (though that joke is not too popular with anyone besides me 🤣 ), but I reiterate the joke just to emphasize how seriously that is taken -- but I think it is more properly described as Neoclassical Prolog. This means we celebrate the discipline of the absolute best and most rigorous techniques and inspire each other to reach for that same level of mastery.

The goal of making it accessible to newcomers is welcome. And I appreciate your "defense against the dark arts" approach. But you will find that the pedagogy here is aligned with the message of the content: state what holds, not what doesn't.

In regards to making it accessible to newcomers, I would contend that there are three kinds of newcomers:

1. Individuals with little to no experience in programming
2. Experienced programmers seeking to learn a new language
3. Experienced technical professionals (scientists, engineers, or programmers who are required to use this for work)

I believe in the case of group 3, they primarily want cut and paste examples, and in the absence of that they want extremely clear and easy to use documentation, and ease of use features.

In the case of group 2, they are most likely looking for the correct "idiomatic" usage of the language -- not just how to "write Python in Prolog".

In the case of group 1, which I think is whom you are primarily focusing on:

I think that hands on tutorials are far superior to documentation, as they must "experience" the language rather than reason about it. My experience and background in education and teaching programming has made me a strong believer in Constructionism -- Repetition, drills, and so called Études lead to the development of abstract thought which cannot be communicated directly.

You can feel free to look through my forum posts and find that I was and often still am wrong-headed and belligerent, so I don't mean to say any of this to be discouraging or say that none of this is welcome. Rather, in spirit of the Neoclassical tradition, I would encourage you to take a look at some of our best works and thinking:

• https://www.youtube.com/@ThePowerOfProlog
• https://www.metalevel.at/prolog

Two things -- first, you will find that contributing to the official material is -- deliberately -- a very high bar (more on that in a second). Secondly, once you do embrace that Neoclassical spirit, I think you will find that changing the approach in your tutorial from "how do we align with what people are used to seeing" to "how do we align people with what they should be seeing", you will find that a much easier sell.

Now then -- as a final note, I am still learning myself, and many things I do which I am unsure about how to align with the best standards but I am interested on making progress towards nonetheless. For example, my Scryer async library photon, or my Scryer Python library ScrPy -- I have these as libraries that are adjacent to Scryer but contribute to the ecosystem. The type of feedback you can get for an adjacent project is generally more constructive even if not directly aligned than trying to put an unaligned project directly into the standard.

So again I do hope you receive this with the Neoclassical spirit in which it is intended, which is to inspire you towards the same standards towards which I myself have been inspired. If you have any questions which might be better answered more transiently than on public discussion feel free to get my email from my GH profile or join the IRC chat!

[dougransom]

I think that hands on tutorials are far superior to documentation, as they must "experience" the language rather than reason about it. My experience and background in education and teaching programming has made me a strong believer in Constructionism -- Repetition, drills, and so called Études lead to the development of abstract thought which cannot be communicated directly.

Completely agree with this, wouldn't hurt to have a series for exercises for Prolog newcomers to go complete, roughly in line with the Power of Prolog.

[dougransom]

Getting started might also be a good place to list toplevel keybindings i.e. #3155 / #3154
Agree, can it wait for an update?

[Skgland]

Content wise this looks good to me.
The examples are a bit artificial, but that is to be expected if they are tailored to show a specific issue/thing.

Other than that see my other comments for a few syntactic/stylistic nits.

Getting started might also be a good place to list toplevel keybindings i.e. #3155 / #3154
Agree, can it wait for an update?

What kind of update? You mean as e.g. a follow up PR? Yes, that would be fine. Better incremental documentation/teaching-material update than getting stuck such details.

[Skgland]

Déjà-vu, the same two sentences are already above in lines 189-190.

[Skgland]

Line break two words into a sentence is a bit odd, breaking after the end of the preceding sentence would be less jaring.

It might make sense to use semantic line breaks i.e. make a line break at the end of every sentence (point 4. after ., ? or !).