The FAQ of comp.lang.prolog is maintained as a Prolog source file

I used to enjoy hacking with Prolog, and I used Swi-Prolog when experimenting with the semantic web, in the sw’s early days. My only real problem with Prolog is that I have only been paid to use it for one intense six week project and a few one or two day gigs. I compare this to getting lots of work with Common Lisp, Java, Ruby, Haskell, Python, etc. Contact me if you have Prolog work you want done :-)

Swi-Prolog really is an amazing ecosystem.

wtetzner2• 6 years ago

Sorta weird that the path ends in .txt but the URL returns HTML, even if you use

    Accept: text/plain

Would be nice if it could provide either based on the Accept header.

simplify• 6 years ago

Prolog also has some really impressive debugging tools. It allows you to pause execution, change the code, and then resume execution from an earlier point in time.

Michael Hendrick's "Production Prolog" talk gives a demo of this (at 12:17) https://www.youtube.com/watch?v=G_eYTctGZw8

brian_herman• 6 years ago

My teacher talked about prolog in college in my programming languages course at UIC. It was really cool to see him talk about his thesis.

https://cs.uic.edu/profiles/joe-hummel/

djsumdog3• 6 years ago

I think the last time I touched prolog was in University. Looking back through my class assignments, I think we discussed prolog but didn't actually write anything in it. The only assignment I see from that era was writing our own First-Order-Inference engine (really basic implementation; lots of limitations):

https://github.com/sumdog/assignments/tree/master/csc4240-pr...

rho49• 6 years ago

Story of my life. In my opinion the best tool for basically all jobs is usually the main programming language of your project / team / company. Everyone can read it, change it and run it. It can do everything. It has the best tooling support. The best IDE, which everyone has installed, licensed and knows how to operate. It is hopefully compile- and type safe. It is hopefully under source control. And hopefully a mainstream language, so you can find tons of help and resources online.

But for some reason, every f* new task is always first solved with some interpreted weakly typed scripting language, shell script or batch file, config file, xml programming, open source tool or web service. Unversioned, and with the weakest tool and team support imaginable. Probably a separate git repository with separate login credentials is created somewhere along the way as well.

YeGoblynQueenne7• 6 years ago

I feel your pain. For me the worse case of this is web dev, where there's a different language for every task: html, CSS, javascript, SQL, your back-end language, XML, JSON, and so on.

But, Swi has my back on that, too:

https://www.swi-prolog.org/FAQ/PrologLAMP.txt

  Can I replace a LAMP stack with SWI-Prolog?
  
  Yes, you can, and you'll be happier for it.
  
  LAMP is short for the following open source components to realise a web
  server:
  
      Linux
      Apache
      MySQL
      PHP
  
  In this picture, Linux provides the OS, Apache the web server, MySQL the
  database and PHP server-side scripting facilities. In fact, most of these
  components can be replaced. One can replace Linux with almost any other OS,
  Apache with Nginx, MySQL with PostgreSQL. PHP is similar to ASP.
  
  There are also larger replacements of this stack, such as Tomcat, which
  replaces both Apache and PHP. Similar architectures are available for Python
  (django), Ruby (Ruby on Rails) etc. As we will see below, this is the picture
  into which SWI-Prolog fits.  

  The SWI-Prolog web framework
  
  The SWI-Prolog web framework (obviously) does not replace the OS. It does
  replace Apache, PHP and to some extent MySQL. We could refer to the stack as
  LP (Linux Prolog). Below, we point at the various libraries that make up the
  stack and relate them to the LAMP components they replace.

You can't quite replace html/css/js of course, since the browsers depend on them- but they can be embedded in Prolog easily. I believe the http library in my other comment here has facilities to do this.

Also- if you ever need to write a parser for some topsy-turvy ad-hoc markup language some third-party is using that you are forced to process, Prolog is probably the best language to do this, thanks to its Definite Clause Grammars notation that's basically BNF, except that it's not restricted to context-free grammars:

https://en.wikipedia.org/wiki/Definite_clause_grammar

martinlaz• 6 years ago

We could refer to the stack as LP (Linux Prolog).

Nice pun (not sure if intended).

choward• 6 years ago

Please don't format your comments like this. Nobody is going to read it on mobile.

hn_throwaway_99• 6 years ago

While I generally agree with your comments, I am currently working on a project with a React front-end in Typescript and a Node back-end in Typescript, the first time I've ever had the same primary language everywhere. It is a HUGE productivity boost, and most importantly makes it much easier for anyone on the team to review and understand pretty much any area of the codebase.

Folks should not underestimate the benefits of having a single primary common language everywhere.

zeveb2• 6 years ago

In my opinion the best tool for basically all jobs is usually the main programming language of your project / team / company.

I read a wonderful article some time ago (here maybe?) arguing exactly this, and positing that any language unsuitable for replacing every other language in a company is insufficiently powerful. As I recall, by 'language' the author meant every single computer language: shells, interpreted scripting languages, compiled languages, perhaps even markup languages.

IIRC, the author came from a Lisp background, which shouldn't really be surprising: so far as I am aware only Lisp and maybe Forth would do a decent job at all those tasks.

StavrosK2• 6 years ago

The obvious counterpoint is that then you'd have to rewrite every single tool in every language people used.

I don't care about extending most of my tooling, I just want it to work. I'm not going to spend years rewriting Terraform in Rust just because I don't use Go in my company.

_jal2• 6 years ago

I get where that is going, and agree with the sentiment. But this assumes that companies, engineering teams and problem domains all perfectly overlap.

I'm a systems guy in a Java shop. Ignoring obvious nonstarters like trying to shove Java into early Linux boot, this still implies I should be hiring Java programmers for systems engineers. Which, no, not only don't I care, doing that would select for a very small subset of available candidates.

A nice thought experiment, but not practical.

vorpalhex• 6 years ago

I was with you for the first paragraph, but not the second one.

Yes, you should use a relatively small toolset and use it well. Whether that toolset is prolog or JS or bash or whatever depends entirely on your needs and requirements and will vary from team to team.

If bash scripting meets your needs, then use bash scripting! There's nothing wrong with it. Likewise for clojure or C# or any other tool.

rho49• 6 years ago

In my opinion there is everything wrong with bash scripting. As per the 1st paragraph, I would argue to use your main language instead.

dkarl2• 6 years ago

Totally with you, except you need to choose your primary language carefully if you want it to scale up and down like that. Don't expect people to write little command-line tools and one-off scripts in C or Java. You'll see an apparent lack of tooling for little tasks, as people hoard their secret scripts. And it's really important to get people to check code like that in, as then it will be subject to PRs where bugs will be spotted, documentation requested, and general awareness of the code's existence raised.

Also, junior people will translate "code I will never be able to check in anyway" to "perfect opportunity to play around with that new language I want to learn" and then you've got them making the usual mistakes as noobs in that language.

Spivak• 6 years ago

Don't expect people to write little command-line tools and one-off scripts in C or Java

Assuming you’re a C/Java shop, why not? You get to leverage all of your coworkers code to make that little CLI app. The whole thing will probably be “parse args and then call an existing method.”

Then that little tool is part of your app, callable wherever your app is, stored in Git, testable with your existing tools, etc.

madhadron• 6 years ago

Don't expect people to write little command-line tools and one-off scripts in C or Java.

Why not in Java?

mhd3• 6 years ago

It can do everything.

For some weird value of 'It'. People went way overboard, but early Java really was as expressive as a stone mask.

veeralpatel9792• 6 years ago

You're right, maybe the tool or script would be more maintainable if it was written in the company's main programming language.

But also, a developer may not even write it if he or she feels pressured to do this.

Here's a thought experiment: say you're seeding data into your local database server using the `mysql` CLI.

- Would you write and check in shell script to do this, so coworkers can use it? Probably yes.

- Would you write a Python script to do this? Probably no.

- Would you write a Java or C program to do this? No way.

rho49• 6 years ago

No thought experiment necessary. On my first job, someone created Python scripts (hot & new then) to initalize our warehouse databases. Checked in, too (good!). Became a huge maintenance hassle and forced everyone to learn Python on the side. I fail to see why you would not check in a script, no matter what language... And yes, I would, have and do write database initialization "scripts" in my main language all the time.

NaNtales• 6 years ago

This reminds me of the C++ coding standard used at game company Splash Damage which is maintained as a compilable source file (+ header)[1].

[1] https://github.com/splash-damage/coding-standards

tetron• 6 years ago

I was really hoping this would be structured as a set of assertions which would then be used to generate answers in response to queries.

subjectsigma• 6 years ago

I don't know if he browses this site, but wanted to give a quick thank you to Markus Triska - the posted website and his YouTube channel are both simple but informative Prolog resources. He's also made many contributions to SWI-Prolog and a new experimental flavor called Scryer. Would encourage everyone to give it a quick look, especially the fantastic reif and ediprolog tools. Thanks Markus!

The FAQ of comp.lang.prolog is maintained as a Prolog source file

Related Stories