Wanting to expand PrologHub into a more rounded community service I thought it’d be great to revamp Learn Prolog Now! into an interactive online book with a little more modern design.
By the terms of the original license, this version is also shared under the same Creative Commons Attribution license, meaning once this work is done it’ll be easier to maintain in the future, especially seen as we’re moving the content into Prolog from Latex. For example a more robust lpn.swi-prolog.org version with SWISH would likely only require changing one file. Under the Attribution license, contributors will be attributed!
Chapter 1 is available as a preview here: lpn.prologhub.pl, checkout the interactive code and quizzes.
If you’d like to help, take a look at the Chapter 1 objects. You can pick a chapter from the book, and create section1.lgt, section2.lgt (These are the numbered headings in the chapter), and section4.lgt (The practical session), following the same pattern as in Chapter1. (section3.lgt being the quizzes is a bit more tricky, but you can always extend leaf_section as a placeholder if you’re feeling brave).
To do this is mostly a case of copying and pasting (learnprolognow.org is handy here), and putting in the appropriate markup. We have \inline_code/1, \static_code_block/1, \code_block/2 and \code_query/2 components declared here: code_components.
Doing this will be a huge help, freeing up time to spend on implementing all those tricky quiz types. Plus, we’ll have a version of Learn Prolog Now! that other languages will be envious of…
I’ll have to disagree with that. That is not disagreeing with what else you suggest or offering to help with your ideas.
IMHO many people are able to self-learn a procedural programming languages like C or Basic because it is like learning how to follow a recipe. Object-Oriented concepts build on procedural so is a standard progression in programming paradigms. Some even make it further on their own to functional programming, but many never make it on their own to Prolog and many who do try to self-learn Prolog fail. Even some of us who take Prolog as a university course consider that we did not successfully learn Prolog. If I had not had help in trying to fill in the parts I did not get correctly in the class, I would still not be using Prolog to this day.
I think there are many people out there who desire to learn and use Prolog, or who have to use Prolog but would like to use it while enjoying it instead of struggling with it. Those people also need help and so by starting at the lowest level and constructively working up is how I plan to contribute. That doesn’t not mean I will not not help others in this endeavor of adding learning material, but that the bottom-up constructive approach will be my main focus.
I dont disagee with you, it is for beginners in Prolog, but not for beginners in programming.
I think it is very unlikely that someone completely new to programming will choose prolog as a first language. Python, Java, Javascrip or C++ is much more likely… With each having functional extensions.
For professional programmer you can build on the functional approach and focus on key paradigms such as relational programming.
How about we outline what is needed to make this discussion concrete.
For adoption in industry you cant target junior staff but the staff that makes language choice decisions.
Every semester I’ll have in influx of student traffic. I should provide a good service for them and encourage them to stick with it. This same service will be suitable for all beginners.
With more people sticking with Prolog we’ll have more people wanting to use the language. These people will know the basics but find themselves wondering how to use it in their domain. So after LPN! they’ll need domain specific tutorials, like web, data ETL, AI, CLP, etc. After this they’d be ready for some junior role in industry, but these are notably absent in Prolog.
Starting alongside domain specific tutorials and working towards senior roles, Prolog programmers wish to learn how to code well. This is where deep dives into existing projects, how to use particular libraries and code-alongs come in. This is where I view a structured investigation of pengines would go. The blog captures the unstructured things.
My aim is to capture more beginners and to support them all the way through. My hope is that increasing the number of competent and passionate Prolog programmers will be reflected in industry simply because more people want to use it and are capable of doing so.
To accomplish this with PrologHub, we’re starting at the beginning. How far we can go depends on how much time can be dedicated to it, which is why it’s all open source.
For something close to my vision in a language with similar difficulties that’s improving its lot, check out Monday Morning Haskell
Facing the same challenge in Logtalk - how best to help new users learn the language - some things that proved to make a difference are:
A short tutorial highlighting the main features. I opted for a “Learn X in Y minutes” tutorial. There’s also one for Prolog with room for improvement (hint, hint, …). These short, one page, tutorials can be read in minutes and are great for curious people wanting a quick taste of a language. They can work as a motivator for more in depth leaning materials such as Learn Prolog Now!
Explain what’s different compared with other languages/paradigms. The biggest challenge here in my case is to explain how declarative OOP differs from traditional imperative OOP. For Prolog, that could mean explaining logical variables, unification, backtracking/non-determinism, homoiconicitywhile comparing with imperative languages. This is already available in some Prolog learning materials but not (?), IIRC, with a strong emphasis in comparing.
Explain the lingo/jargon, again comparing with other languages/paradigms. The same technical term (e.g. variable) often have different meaning in different languages. This can be quite confusing for new users. Of course, also provide an easy to find glossary.
Looking at the material, i, unfortunately, find it hard to follow – the tutorial show how to use a construct, but not what practical problem the construct comes to solve, and how it fits in a bigger picture of problem solving
For example, to show that a list can be encapsulated in an object construction, help use them, but doesn’t explain why and in what situation one wants to do this, and not, say, use a standard Prolog module.
I guess i favor learning through larger problems where constructs use is shown in solution development context.
For example, how to make client code of the list object oblivious of the particular subclass of list object it makes use of, which helps make the client code more stable, while allowing to vary the kind of list (and list implementation?) to use.
thank you,
Dan
p.s. btw, i think it would have been better to have a category example that does not use assert / retract to record properties but rather a relational approach – such as by use of assoc. just, so to convey today’s best practices by way of other examples as well.
Would using, say, an assoc, be the right way to have changing values in an object?
No tutorial can be everything for everyone. A short tutorial aiming to give a quick taste of a language doesn’t target problem solving in general. For that, other material exists (with, of course, ample room for improvement). An example closer to actual problem solving is the collection of sample implementations of design patterns already mentioned. Some interesting cases can also be found in StackOverflow (search for the logtalk tag). E.g. Structuring SWI-Prolog Code into Modules for Unit Testing of Multiple Algorithms and Data Sets - Stack Overflow
P.S. There isn’t such a thing as a “standard Prolog module system”, although it continues to be a persistent myth. Wishful thinking, I guess.
Some of the bundled examples are not trivial and can help showing that. More upcoming blog posts also will focus on non-trivial problem solving.
The SO answer linked above highlights some of the technical solutions to do that. Happy to followup but in a different thread to avoid going off topic in this one.
I assume you mean the tutorial in the Handbook. Agree, that tutorial, including that particular example, is quite old (almost +20 years!) and much better examples exist.
Indeed, this is the book as written by Patrick Blackburn, Johan Bos, and Kristina Striegnitz, who say this in their license notice:
The authors would like to maintain backwards compatibility with the printed, published version of LPN. That is, ideally numbers of chapters and exercises shouldn’t change, but still allow for the possibilities to add new exercises, sections or even chapters.
The authors have left scope for updates and edits, and we’re forced to change the number of exercises to make the auto-marking work. Should we make edits in the HMTL though, they shan’t be reflected in the Latex, which would be a technical barrier to an updated second edition of the printed book, perhaps not an insurmountable problem.
But my main reason for not editing is that the transfer to termerized HTML is a monumental task, hence my request for collaboration. I do not wish to burden collaborators with the extra responsibility of editing the content. To do so would not only discourage contribution, but it would result in a product that reads like every chapter is written by a different author.
The first step in this project, as in all software projects, is to get the thing working. With that accomplished it will be a relatively easy matter to maintain, such as editing or adding a chapter. It will also be easier to add new features, such as my dream of it being able to track user learning for users.
That would be really great. The current lpn.swi-prolog.org works as a rewriting proxy on the original site. That is not really ideal. The re-writing injects a JavaScript file and analyzes the code sections on the page, trying to figure out what is a program and what are example queries on that program. This is pretty tricky. Worse, sometimes you have to combine multiple source code fragments or even replace a clause in a previous code fragment to get the final code for running the examples. Ideally this should be annotated with the code fragment and then if the JavaScript is included in the main side, you’ll have a perfect interactive SWISH side (SWISH isn’t embedded there, the lpn site simply calls out to swish.swi-prolog.org).
Do you plan to include sufficient information to make it possible to create the program and exemple queries reliably? One crude solution might be to have an optional \hidden_code or something similar, so the rule becomes
If we find a sequence code, hidden code, queries, send the hidden code to SWISH
for code, queries send code to SWISH.
Of course, the web side should ot show the hidden code (pass on using display:none)
In working with the site (LPN with SWISH), that was one of the main problems I had with many examples that did not work correctly in SWISH and one of the reasons I choose not to pursue working with LPN with SWISH.
This really requires human annotation to get right. Note that we can validate the entire book for consistent SWISH annotations quite easily if we knew the answer to each query. Even without it is not hard to write a little javascript that sends the code fragments and their queries to SWISH and check they actually run.
I’d be happy to help with some of that. Note that if the entire pipeline works it is a great thing to have and extend/reuse for teaching more advanced Prolog.
The one file is the one containing all of the code components.
(the html_write: prefixes are so they can work with Logtalk objects, this is one of the first things I’ll change in the optimisation phase, so they’ll all be in one object)
We denote an inline bit of code and a static code block, which aren’t supposed to be interactive. (\inline_code//1, \static_code_block//1)
For interactive bits of code we have \code_block/2, which takes a unique ID for that code block, and some code. We then have \code_query//2, which takes that ID for the code to be queried and a query. The final block is \code_query//1, which is for a query that doesn’t need any additional code. An example pairwise use is in section 1, lines 23 and 32
The unique ID should mean that we have no need to search for sequences, when we find a query: look up the code with the matching ID and send it to SWISH.
I have not yet encountered an example that needs hidden code, but I imagine I’ll just add a \hidden_code_block//2 component and allow a \code_query//2 to accept a list of IDs.
Looking at the github repo, the README says “It’s probably possible to write a parser that’ll take the Latex and spit out termarized HTML, but it might prove to take longer.”
It is probably not a priority, but SWI-Prolog comes with its own Prolog based translation from LaTeX to HTML in packages/ltx2htm. This is used for the documentation. It differs from the standard tools to do so (at least, when I wrote it) in trying to do a high level mapping rather than a low level one that produces hard-to-read HTML. The thing consists of a C LaTeX tokenizer that creates a giant Prolog term and a Prolog converter. The code is really old though and mainly maintained to keep the documentation pipeline running. I guess I’d design in differently now
