Just because of performance issues. No other explanation needed really. same reason why it took some time for pure functional programming to take off too. The time for Prolog will come.
IMHO it's worth learning about Prolog as a way of looking at the world -- for instance Isabelle and Lambda Prolog are essentially logic programming engines, albeit with more sophisticated terms and unification algorithms.
[2] https://www.hpl.hp.com/techreports/Compaq-DEC/PRL-RR-36.pdf
There is even a new language that allows to embed logic programming inside of "regular" (imperative/functional) programming code. Forgot the name though.
I mean, of course, minikanren is also implemented somehow, using lambda, but usually one would not want to rebuild the things minikanren offers.
I have not yet tried to use minikanren inside an otherwise "normal" program, but I suspect it will just work.
[1]: https://invidious.baczek.me/watch?v=5vtC7WEN76w (video id 5vtC7WEN76w)
As for modes, I'm not convinced they are really needed? I do feel they take away a lot of the beauty of Prolog, and a lot of the incentive to think in relations. (Or at least, I fear they do. I haven't actually programmed in Mercury. Would be happy to be proven wrong.)
As for modes, well! 1. they were needed for at least one Uni of Melbourne person to receive their PhD degree, and less facetiously 2. they are needed for efficient code generation. They can be inferred for this purpose. One use case you may consider is enforcing the correct dataflow in a DCG. Otherwise they are handy for preventing calls to predicates that would not terminate.
I've never programmed in Mercury but it really looks like an ML to me. It was beautifully engineered in the late 1990s and it's a shame it hasn't received more attention. Its FFI influenced the development of Haskell's.
a_list_processor([H|T], ..., ):-
process_list_head(H,Xs)
,process_list_tail(T,Ys)
, ...
To be pedantic, almost nobody is using a pure functional language even modernly. Almost all languages that support functional programming are hybrid systems at this point in time, and still have anti-functional constructs such as classes and objects.
I dare say, it would be very difficult to maintain a large system that was purely functional. Some of the concepts revolving around OOP are indeed quite good and lead to better organized, more easily understood codebases.
The future is probably a hybrid approach, not a pure approach as some advocates would prefer.
Yeah every non academic language (that I know of) has escape hatches.
Still, you can (and many do) write your code in a 99,99% pfp style in e.g. Scala.
However, a Data Class without mutability and without functionality (besides accessors) is in-line with PFP.
Like I said, most modern systems are hybrids - taking the best of all paradigms instead of aligning with a singular paradigm as was done in the past.
Those are valid things to do even in pfp.
data classes are technically similar or even identical but conceptually a different thing (though of course also useful and needed).
And when exactly did that happen? And no, I am not about imperative languages incorporating some functional programming stuff. When did a "pure functional" PL become mainstream and widely used in professional software engineering?
Because as far as I can see, I see imperative languages dominating pretty much every field.
I don't think that contradicts my understanding of "take off".
The languages are not widely used. Rhey play a minor role at specialised applications in the industry. Almost everyone who learns programming uses imperative languages.
So what exactly is the definition of "take off" here? Because, other than Haskell having a bit of media-echo a couple years ago, and an army of fans promising things like "the future of programming", I don't see any takeoff.
Okay, let's do the comparison.
LLMs became a big story less than a year ago. Since then, they are, among other things, powering the fastest growing app of all time. They are poised to take over pretty much every NLU functionality, products are being developed every day that wouldn't be able to otherwise, and major players in the industry throw billions at them. Their, and other ML achievements, impact on society are estimated to be so profound, that they have caused ripples in international politics, rekindled debates about UBI, made geopolitical positions about chip maufacturing and AI research even more relevant, and set lawmakers all around the globe scrambling to figure out how to deal with this new reality, regarding everything from copyright laws to regulations.
So, what is going on in the purely-functional-PL space?
Well, the flagship of these languages, Haskell, had it's stable release 12 years ago. Since then, the only software product that I can name without googling that's written in it, is pandoc. The language is currently Number 34 on the Tiobe index. In fact, I am not sure any of the current top20 could be called "purely functional", which would place these languages below Scratch, Fortran, and Classic Visual Basic in terms of that index.
https://www.tiobe.com/tiobe-index/
Regarding usefullness, what have purely functional PLs demonstrated? That they can be challenging to use coming from an imperative background, and that they can be a drag on performance. On the plus side they offer ... yeah, what exactly is it they offer, that imperative languages adopting some of their features, like functions as first class objects, cannot?
So I have a hard time seeing any indicators of an impending take-off for purely functional PLs.
But the topic of this discussion is PURE functional programming. See the following quote:
"same reason why it took some time for pure functional programming to take off too."
The reason why my argument above is built around PFP Languages, is because they are the only ones where pure functional codebases seem to exist from my PoV. I am happy to change my mind if you can point me towards major projects written in a PFP style in non PFP PLs.
Yes, exactly. It is NOT about "pure functional programming languages" nor is it about (what's nowadays called "functional programming" features). But you seem to be talking about those two things.
> So when did that happen? Almost every codebase I see is imperative, either procedural or OO. They use mutable state, they use functions with side effects.
Then maybe you need to broaden your horizon. I've worked exclusively(!) in different code bases over the last 5+ years that followed a pure(!) functional style, maybe with very few exceptions for performance or sometimes to make things simpler since it was not Haskell.
For example, look at the adopters of ZIO: https://github.com/zio/zio#adopters
ZIO is a PFP library for Scala (even though they don't market it as that to be more beginner-friendly, but read the documentation and you'll see that it's essentially an IO-monad on steroids). And it is a rather new one but already got lots of traction. And even typescript has now fp-ts which is used much more than I expected myself.
Of course, being a ZIO adopter does not necessarily mean the whole codebase is using ZIO (and hence following a PFP approach) but the chance is high and I personally know two more companies that use ZIO and are not in the list, so there are very likely much more companies that use ZIO. Also, those companies were using a PFP style pretty much everywhere, in every team (backend only though). So it's not like there was just one project in that style or something like that.
When I compare that to 10 years ago, there was pretty much nothing besides Haskell and Haskell is, as you correctly said, not very prevalent in visible production projects. But checkout the list and to your surprise you might find some familiar names in there.
How does "uses a library for async and concurrent programming" indicate a high chance that an entire codebase follows a PFP approach?
> (even though they don't market it as that to be more beginner-friendly, but read the documentation and you'll see that it's essentially an IO-monad on steroids)
?