Exactly this — and it is true about any human language. They were built for humans who are capable of interpreting things given the context. Try covering every single case in English and you have a lengthy legal document which no one wants to read — and it still has some ambiguity left.

If you want an example of what English would look like if used for programming, take a legal document and multiply it by 100.

Well there's one way to have both: just write all your logic in a language that compiles to native.

You've just described the field of formal methods. For software with strict requirements of correctness, correctness is sometimes proven mathematically.

It's not that a rigorous approach to software development is impossible, it's more a question of when it's really worth doing. At present, formal methods are very costly to use. I don't think it's always necessary to go all the way to full formal verification for software development to count as rigorous, though.

Related reading: They Write the Right Stuff, from 1996. [0]

> efficiency is obscure at modern coding levels

Depends on the domain. There are plenty of domains where efficiency doesn't much matter, on modern hardware. Game engines are still tuned for efficiency, and will continue to be.

[0] https://www.fastcompany.com/28121/they-write-right-stuff

That much it was clear they weren't saying. What was being said was that prolog is just about the last lang you'd do this in. Aside from that, I think everyone else was aware that this was an experiment.

To add:

I think this is a great approach. The last highly up voted article suffered from being the same ol' hello world intro to prolog. It's fun to see a real world problem tackled.

Is it any easier to do that than to “program”? In my mind that’s the exact same thing, just a different, less syntactically strict programming language. Writing good specification is crazy hard, and it usually incomplete, so you end up going back and forth with the human compiler (the programmer) to get a common understanding.

One might even argue that a cleaned up, domain-specific language actually helps mutual understanding. It’s not always the case that written text is easier to comprehend — see for example math notation.

This is very true!

By its limitations the tool in question requires churning more code and adds more steps between the “REAL problems” you solved in your minds and the actual implementation of those solutions in-code.

If languages are just irrelevant tools and you have but to focus on the “REAL problems” to solve it all, there’s no reason not to use a turing tarpit. Why are you not doing that?

Anecdotal irony: not 24 hours ago a colleague and I had to reverse engineer a hairy mess of deeply nested if/then/else clauses that should not exist that turned out to be composed mostly of tautologies. I definitely wish to throw books at some people, preferably of the steel-bound, razor sharp edged kind.

Conclusion: you're not drawing Karnaugh tables daily in front of you, but having manipulated the fundamental rules of logic has trained your neural net and makes you much more effective at solving logic problems in a wink and not write crap code, and also simply able to debug stuff efficiently, if at all. I am regularly aghast at people drawing completely invalid conclusions from broken "common sense" logic propositions (A=>B therefore B=>A, or various other syllogisms).

Computer Science is more than just programming. There is a lot of formal theory underpinning this area that has nothing to do with circuits, transistors and microprocessors. CS departments shouldn't just be concerned with training programmers, but also scientists.

> Assume that A implies B. What can we say about `not A' and `not B'?

Maybe I'm missing something but there's no "implies" operator in programming languages and it isn't used this way in casual language so why would you expect software engineers to understand a very precise definition of an operator they don't use?

I've taught formal logic classes and people new to it including programmers always have problems with "implies". Formal logic isn't intuitive and needs to be taught.

This is arguably wrong. Thinking in Prolog is much easier than knowing how to solve a problem beforehand. In Prolog you just state the facts and known rules, but you have no clear idea what would be the best way to solve it. Prolog solves it for you then, if possible. No intelligence needed. A "dumb" friend of mine on the 80ies only used Prolog for his work and was very happy with it. Lisp, Pascal or C was too hard for him.

The problem with Prolog is mostly that you'll through too hard problems at it, mostly with exponential complexity. Tiny changes have huge influences then, it either works or not. Also the tabling and SAT/SMT integration sucks.

Evidence is rare in our profession, but IIRC what little we have suggests no.

> If not, does it suggest we should be aiming to use more expressive languages, that can get more done in less lines?

Yes, it absolutely does. I recommend pursuing that approach.

I am not hopeful about that. As a counter example look at parsing. We have studied this for over 50 years. We have really good theory. We even have a good way to do specifications (EBNF). And we even have parser generators such as yacc.

Yet despite this, for reasons of flexibility, performance, and/or good errors, pretty much every production compiler is using a hand written recursive decent parser.

Most problems in computing don’t have nearly the formal theory and study that parsing does. If we can’t make parsing work in the real world, I am not hopeful about the other stuff.

Ouch. Oh dear, that sounds horrible.

>> Btw, have you tried Mercury?

I've picked it up a few times but I keep coming back to vanilla Prolog. It's great but I'm a bit scared by the tiny amount of adoption. I know it's kind of ironic: low adoption feeds back on to itself.

>> Any ideas on why it's worth keeping around or would you use an alternative today?

I do a lot of nlp for university, and although I use Python for all the machine learning stuff, the text processing capabilities of Prolog are beyond any comparison with anything else.

For instance, everyone uses regular expressions for tiny bits of parsing and string manipulation. Prolog uses a sort of pattern matching, unification, that is like regular expressions except without any special syntax and Turing-complete.

For language processing, most interpreters have something called Definite Clause Grammars. In short, it's syntactic sugar that lets you declare a grammar, except the grammar is also a parser, that recognises and generate strings (because Prolog). They make developing a parser a piece of cake.

Also, Prolog runtimes are essentially fast, in-memory relational databases, with added reasoning (and no SQL). I can think of many applications that could use that sort of thing. Plus, the language itself is the database, so there's no object-relational impedance mismatch and whatnot.

>> Might try to read some of it this week if I get spare time even though idk Prolog anymore

Thanks, I appreciate that. But please keep in mind: 5 years ago and embarrassing :)

I think this is an excellent point. I've been coming to this same conclusion for some time.

For a lot of use cases a less powerful but more predictable language is probably what we need. State machines and DSLs go some way towards this but I don't think that's the full solution either.

Maybe something based on a restricted APL language, either way it sounds like a good PHD project to me.

The same is true of most programming languages - they were all made for humans. Math has the advantage of being to prove formally that it solves the problem, but that isn’t a requirement for most software.

> If we tried to express the same ideas in C++, we would very quickly get completely lost.

Same is true for many things that you can express in C++, but not in Math.

Math used this way is essentially just another programming language - with massive advantages in some circumstances, and massive disadvantages in others - I can’t find any argument in this article as to why it is a better bet than any other language.

Hi nick.

To my experience, this is not at all the case. Prolog was "slow" in the '70s, when nothing was as fast as C. Nowadays, it's not just the case anymore. Try a modern Prolog compiler like YAC, with tabling and everything.

What kind of high-performance code were you trying to write, that didn't go as fast as you like? If it's something interesting I'm all for helping out.

Understanding (mutual) and communication seem to be the big & hard problems to tackle. Software reflects these issues clearly, even down to the detail. You can sometimes look at a particular chunk of code and understand how it got there from refining assumptions (etc.) or the lack thereof.

In terms of technical solutions I think one could just look at modern, more powerful concepts, like writing proofs and advanced typed systems in the static world, generative testing, controlling state via FP, gradual typing in the dynamic world etc. A whole host of bugs can be found w/o writing over-specific handcrafted tests.

You do not need to be a mathematician to appreciate declarative programming.