5 ms·
This is a reference to the "Can programming be liberated from the von Neumann style?" from 1977. It argues for functional programming, making the point that the
by woolion 2y ago
This is a reference to the "Can programming be liberated from the von Neumann style?" from 1977.
It argues for functional programming, making the point that the imperative style is more common for efficiency reasons, as the programming model is close to the computer architecture.
It aims to be a general thought framework inviting to step a step back on some notions that have been (hastily?) accepted in the programming world.
It makes the same analogy that Prolog (or logic programming languages in general) have been strongly influenced by the resolution algorithm. In practice that means that if you write a non-trivial program, if performance is not right you'll need to understand the execution model and adapt to it, mainly with the pruning operator (!). So while the promise is to "declare" values and not think about the implementation details, you're railroaded to think in a very specific way.
I personally found that frustrating to find good solutions essentially unworkable because of this, in comparison with either imperative or functional paradigms that are significantly more flexible.
As a result, Prolog-style programming feels limited to the small problems for which it is readily a good fit, to be integrated into a general program using a general-purpose language.
I may be wrong on this, but of the 50 people that learned Prolog around the same time as me, none kept up with it. Meanwhile, other niche languages like Ocaml, Haskell and Scheme had good success.
Rethinking the language foundation could remove these barriers to give the language a broader user base.
- PaulHoule 2y agoThe way you write imperative programs in Prolog by exploiting the search order, using cuts, etc. seems clever when you see it in school and do a few assignments for a comparative programming languages class (the only 3 credit CS course I took) but it is painfully awkward if you have to do very much of it.
- YeGoblynQueenne 2y agoIt isn't. I do most of my programming in Prolog, I write oodles of it daily, and it's not a problem. You learn to think that way easily. The argument is basically that Prolog is not 100% declarative and that if we jump through a few hoops, and translate it all to functional notation, we can make it "more declarative". But let's instead compare the incomplete declarativeness of Prolog to a fully-imperative, zero-declarative language like Python or C#. We'll find I believe that most programmers are perfectly fine programming completely non-declaratively and don't have any trouble writing very complex programs in it, and that "OMG my language is not purely declarative" is the least of their problems. I hear some old, wizened nerds even manage to program in C where you actually can drop to the hardware level and push bits around registers entirely by hand O.o
- Pearledlang 2y agoReally interesting to hear! I was quite hooked to Prolog in a previous life. Then the limiting factor was the tooling, for really practical use. Could you tell a bit about your Prolog environment?
- agumonkey 2y agoseconded
- YeGoblynQueenne 2y agoI use the SWI-Prolog IDE: https://www.swi-prolog.org/PceEmacs.html https://www.swi-prolog.org/PceEmacs.html I suppose it is a bit spartan, but it has a ton of functionality that I find indispensable [1]. For example, when I place my cursor on a variable in the editor it highlights all the variables that unify with it in the same clause, and it will highlight singleton variables in a different colour so you can catch errors caused by typos easily. It is also aware of things like imported predicates, undefined or dynamic predicates, multi-file predicates etc, and will highlight them accordingly. It has some (limited) auto-complete and code-expansion etc. and a status line that gives you very good information about the kind of term you have your cursor on - where it's defined if it's a predicate, its name and arity and how many clauses etc, basically much of the information you can get from querying the program database with various program inspection built-ins. Some of my colleagues use VS Code to write Prolog instead and I keep shaking my head and grumbling about the errors they keep making that they wouldn't if they used the SWI-Prolog IDE instead. Kids, these days. In my youth, we wrote all our Prolog on Notepad! And compiled on Dos! (nope. never) SWI also has a graphical debugger, which however I never use: https://www.swi-prolog.org/pldoc/doc/_SWI_/xpce/prolog/lib/gui_tracer.pl https://www.swi-prolog.org/pldoc/doc/_SWI_/xpce/prolog/lib/g... I know some people swear by its name but I prefer the textual debugger. Again this one looks a little spartan :) More goodies in SWI: cross-referencer: https://www.swi-prolog.org/gxref.md https://www.swi-prolog.org/gxref.md And profiler: 1 ?- profile(between(1,10,_)). ===================================================================== Total time: 0.000 seconds ===================================================================== Predicate Box Entries = Calls+Redos Time ===================================================================== between/3 1 = 1+0 0.0% true. And lots and tons of facilities for debugging and error handling, unit testing, all sorts of libraries, a package manager etc. ________________________ [1] You can customise the IDE colours too. There's a dark theme: https://www.swi-prolog.org/pldoc/man?section=theme https://www.swi-prolog.org/pldoc/man?section=theme There's some screenshots here: https://swi-prolog.discourse.group/t/questions-about-ide-themes/6817 https://swi-prolog.discourse.group/t/questions-about-ide-the...
- tannhaeuser 2y agoIt might be a reference to that 1977 paper in name, but unlike that Backus paper using math to make its point, this reads like a shallow ad for using the Curry language. The central (and only) point is merely an example of rewriting a Prolog predicate for appending lists into Curry but without even the claim of generality. The rewritten Curry functions however trivially fix determinacy and variables to input and output roles when the entire point of logic variables in Prolog is that they're working either when bound to a value upon entering a predicate call, or can get bound to as many values indeterministically as needed until the procedure terminates succesfully (and then even more on backtracking over failed subsequent goals). The paper also glosses over the concept of unification here. I sure hope the referenced detail papers come with more substance. The paper title doesn't even make sense? So he wants to "liberate" Logic Programming from predicates? Predicate Logic is First-Order Logic ... ie what YeGoblynQueenne says in another comment. From a mere practical PoV, who is the author even addressing? Prolog, from the get go, was introduced with NLP, planning problems, and similar large combinatorical search spaces in mind and is used for the convenience it brings to these applications. That FP could theoretically be more broadly used is completely besides the point; Prolog's focus is its strength.
- gatane 2y agoAt Uni, we had to implement the same project on different paradigms/languages. We had to do goddamn Paint on Prolog. Yup.
- Guthur 2y agoIt's possible that new execution models can be found. Tabling is one such execution strategy that many prolog implementationsc already provide.