Here are some thoughts and I try to stop as I don’t want to be on this carousel.
Do not underestimate the power of (perceived) familiarity. Any language that looks anything like C will have a much better chance of not being immediately discarded. (ifs, fors, whiles, enums, functions, that kind of stuff)
Do not underestimate how difficult it is to find people who have both a firm theoretical foundation and are experienced programming practitioners. I am not saying there aren’t any, but it is just very difficult to get hold of them.
Do not overestimate the importance of your choice of a programming language or a technology in the current state of affairs. Yes I do believe that they are very important, but I don’t know that there would be enough good empirical research that would inform us when it comes to making the decisions.
These are my opinions and nothing else. I am always excited to know more about the last point I made (how the tools we use influence how we work).
I think the broader relevant area is macros – and, quite like LISP – it could be an important selling point.
For example one of Scala’s selling point is embedded DSLs – which touches on the non-functional requirements you indicated, such as making code more readable, reuse more systematic, etc – perhaps this can be positioned equally well for Prolog with DCG a classical example.
I still believe that one unique selling proposition of (SWI-)Prolog is programmer ergonomics. I have a rough idea of existing scientific research that would hint towards this. In order to show it so that I personally am satisfied I would need time and resources that I do not know how to access. Either way, the end result will not be that “Prolog is the best language for A and B and C” but rather “here are some results that show how humans can be more efficient in understanding and expressing their intent (hehe) while building a complex system”. Coincidentally some of Prolog’s existing features might (or might not) be part of this.
I am not sure what you are arguing for or against …
Let me get back to my original question:
What does it take to provide a clear entry point into (SWI) Prolog for a professional programmer working on commercial solutions.
I suggest making accessible a list of novel features included in (swi) Prolog along with a compelling value proposition …
Can this be done – or is (swi) prolog, along with all other Prologs, a lost cause for broader adoption – and only useful for teaching and academic research into logic programming techniques.
I personally, think that Prolog has tremendous potential when its value proposition is clearly articulated and barrier of entry significantly reduced – not(only) for the beginner – but for the professional developer.
" Rust is a statically-typed programming language designed for performance and safety , especially safe concurrency and memory management. … Rust solves problems that C/C++ developers have been struggling with for a long time: memory errors and concurrent programming. This is seen as its main benefit."
This is why a programmer is going to choose Rust: its focused - by design – on system programming that requires memory safety and concurrency.
Any C/C++ programmer whose code caused security vulnerabilities and crashes with commercial costs in the tens of millions and more – will want to choose Rust.
This all sounds nice and dandy until you actually start trying to use Rust to write programs. As @j4n_bur53 says you might replace “Rust” with many a language and be shocked how true the statement still holds.
Rust is popular because of the hype. There I said it. It might have good sides to it, too, but we don’t have the tools to tell what it is about Rust that is better than anything else that we might have.
And I can’t help but remember the punchline of the old programmer joke (rephrasing):
“Using this language is an adequate punishment for inventing it”
But, Prolog is not designed neither for performance nor for memory management (as a key purpose its designers had in mind – i.e. the nail) – its designed for something else – to Program in Logic …
And the motivation to program in logic was – i think – AI – and the believe that human-like reasoning can be captured in logic. So, Prolog could serve as an underpinning language for formalizing knowledge based human-like (symbolic) reasoning.
But, today, Prolog is a general purpose language that can benefit developers in ways other languages can not …
Of course you design for performance – otherwise the language is unusable.
But, the person who came up with Prolog didn’t say – i want a new performant language … he said – i want to program in logic – i want to capture language semantic in logic …
I still don’t understand what you are arguing for or against …
Clearly, other languages have similar features – language designers borrow from each other generously.
(SWI) Prolog in its modern form has a unique set/mix of features not found in other languages – and the language in 1977 and today is different enough, with novel features such as tabling, etc.
The question is – and i repeat – what is the key value proposition for (SWI) Prolog for the professional in its modern “reincarnation” … or stated differently what ToC would capture what needs to be known to work professionally for the professional programmer.
The most likely correct answer is either (or both) “none” or “many”. When I decided to go commercial I’ve had discussions with several people circling around the question as to what the USP is and (thus) on what we should concentrate. We looked through applications we knew about, both commercial and research. We looked through publications that cite SWI-Prolog. It is really hard to find anything that even just resembles something relevant that applies to a reasonable number of such applications.
The key factors to the success of SWI-Prolog are probably it being by far the most comprehensive system (most features, libraries, ports, etc.), its robustness and support. Few people use a large part of all the features though. “Easy to use” is also frequently mentioned. Some people even claim it to be “fast”. Your mileage may vary. There are applications where it does a great job as well as applications where it does not (notably small, static and mostly deterministic programs).
There are surely aspects of the system that need a good tutorial. I don’t think there is single ToC that fits all though.
Smart pointers is a runtime feature whereas in Rust ownership checks are a compile time feature – that makes it a different kind of animal and a unique value proposition amongst current languages …
re: Rust
Rust is clearly interesting to me, but its limitation with double linked pointers is disappointing to me – also, Rust performance isn’t clear to me yet, and the learning curve is very steep.
Also, how well Rust integrates with Prolog needs investigating – including the rust based FFI that was mentioned on the list some time ago …
So for my purposes I am still undecided whether to use Rust or not …
Erlang solves these problems and handles concurrent programming across multi cores and multi machines. (And even has a poster child for efficiency and scalability, both in hardware and the small size of the engineering team: WhatsApp)
And Erlang handles the problem of upgrading running code, which remains a huge problem in large distributed systems.
So, you’d think that Erlang would be the hot new programming language. But it isn’t.
I can think of a few reasons, but (at the risk of sounding elitist) the biggest ones are: most programmers aren’t very good and most software engineering managers aren’t very good. In the old days, we joked that nobody got fired for buying from IBM. Nowadays, nobody gets fired for using a C-like language. (Also, the majority of programmers “typically spend their careers maintaining mainframe computer code at insurance companies … don’t even like to program but have discovered that by the simple technique of leaving out the comments–clues, labels, and directions written in English–they are supposed to sprinkle in among their lines of computer code, their programs are rendered undecipherable by others, guaranteeing them a lifetime of dull employment.”)(*)
BTW, an argument can be made that both Python and JavaScript are LISP in a C-like syntax.
(*) Cringely’s Accidental Empires uses the term “lumpenprogrammer” to describe the majority of programmers in Chapter 2 – there’s a lot wrong with that essay (including sexism) but it’s mostly correct in observing that good programmers / software engineers / software designers are a tiny tiny fraction of the people who work on computer systems.
When I worked on telephone switching software at BNR, we weren’t sure of what kinds of concurrency would work best (as I recall, we had 3 different kinds of concurrency controls). Almost everything ended up being done by message passing with timeouts, using references for large messages (essentially, an optimization over message copying).
The argument of “you should have lots of options” is appealing, but it’s not clear that it’s correct. On the other hand, the “lots of options” feature helps in selling the product – people don’t like the message “we know what’s best for you” even if it’s true.
Probably Prolog (and Erlang, and other non-C-like languages) feel like “we know what’s best for you” to the vast majority, and also look like writing in Devanagari instead of a Latin alphabet, and are rejected based on emotional reactions.
I think you described the novelty of Rust very nicely here …
Note that the problem Rust aim to solve at compile time is undecidable, hence the compiler errs “on the safe side” – i.e. can be more constraining than necessary
I’ve made some progress on the wiki front: I’ve got a default installation of MoinMoin running at https://www.seatavern.co.za/ (I’m using an old domain name I registered for a hobby “What’s on in Cape Town” website decades ago. Since I no longer live there, it’s a vacant parking place for now).
Installing an open source wiki wasn’t quite as easy as I hoped, mainly on account of Centos 7 refusing to allow nginx to talk to a Unix socket by default (as I discovered after a couple of wasted hours thinking it had to do with permissions or the location of the socket file…)
My next snag is opening it to user registration. The only way I’ve figured out so far is to manually give everyone who would like to contribute an account with a command line tool
I hope there’s a better solution. A reason I like MoinMoin is content is simply stored as flat files, making it easy to migrate to another server whenever.
I’ll spend the next few hours replacing the default MoinMoin content with some simple SWI-Prolog recipes to hopefully move things along.