the-power-of-prolog VS nx

Prolog is excellent for bikeshedding, in fact that might be its strongest axis. It starts with everything you get in a normal language such as naming things, indentation, functional purity vs side effects, where to break code into different files and builds on that with having your names try to make sense in declarative, relational, logical and imperative contexts, having your predicates (functions) usable in all modes - and then performant in all modes - having your code be deterministic, and then deterministic in all modes. Being 50 years old there are five decades of learning "idiomatic Prolog" ideas to choose from, and five decades of footguns pointing at your two feet; it has tabling, label(l)ing, SLD and SLG resolution to choose from. Built in constraint solvers are excellent at tempting you into thinking your problem will be well solved by the constraint solvers (it won't be, you idiot, why did you think that was a constraint problem?), two different kinds of arithmetic - one which works but is bad and one which mostly works on integers but clashes with the Prolog solver - and enough metaprogramming that you can build castles in the sky which are very hard to debug instead of real castles. But wait, there's more! Declarative context grammars let you add the fun of left-recursive parsing problems to all your tasks, while attributed variables allow the Prolog engine to break your code behind the scenes in new and interesting ways, plenty of special syntax not to be sneezed at (-->; [_|[]] {}\[]>>() \X^+() =.. #<==> atchoo (bless you)), a delightful deep-rooted schism between text as linked lists of character codes or text as linked lists of character atoms, and always the ISO-Standard-Sword of Damocles hanging over your head as you look at the vast array of slightly-incompatible implementations with no widely accepted CPython-like-dominant-default.

Somewhere hiding in there is a language with enough flexibility and metaprogramming to let your meat brain stretch as far as you want, enough cyborg attachments to augment you beyond plain human, enough spells and rituals to conjour tentacled seamonsters with excellent logic ability from the cold Atlantic deeps to intimidate your problem into submission.

Which you, dear programmer, can learn to wield up to the advanced level of a toddler in a machine shop in a mere couple of handfuls of long years! Expertise may take a few lifetimes longer - in the meantime have you noticed your code isn't pure, doesn't work in all modes, isn't performant in several modes, isn't using the preferred idiom style, is non-deterministic, can't be used to generate as well as test, falls into a left-recursive endless search after the first result, isn't compatible with other Prolog Systems, and your predicates are poorly named and you use the builtin database which is temptingly convenient but absolutely verboten? Plenty for you to be getting on with, back to the drawing boar...bikeshed with you.

And, cut! No, don't cut; OK, green cuts but not red cuts and I hope you aren't colourblind. Next up, coroutines, freeze, PEngines, and the second 90%.

Visit https://www.metalevel.at/prolog and marvel as a master deftly disecting problems, in the same way you marvel at Peter Norvig's Pytudes https://github.com/norvig/pytudes , and sob as the wonders turn to clay in your ordinary hands. Luckily it has a squeaky little brute force searcher, dutifully headbutting every wall as it explores all the corners of your problem on its eventual way to an answer, which you can always rely on. And with that it's almost like any other high level mostly-interpreted dynamic programming / scripting language.

There is also AI that isn't machine learning. One could use formal logic to state rules and facts about the world and infer things from that. This sounds attractive but the main issue is that you need to build and maintain all of this knowledge. Most oldschool AI falls into this category. There's also fun programming languages like Prolog that are deep into this school: https://www.metalevel.at/prolog

There's a nice book[1][2] about Prolog, with modern characteristics. Moreover, there are things like ProbLog[3] and DeepProbLog[4] that allow you to use probabilistic reasoning and power of machine learning. I am personally looking forward for Scryer Prolog[5] to achieve its goals.

[1] https://www.metalevel.at/prolog

[2] https://github.com/triska/the-power-of-prolog

[3] https://github.com/ML-KULeuven/problog

[4] https://github.com/ML-KULeuven/deepproblog

[5] https://github.com/mthom/scryer-prolog

I had the same troubles until I encountered Markus Triska's modern perspective on revitalizing Prolog: https://www.metalevel.at/prolog.

The Power of Prolog [0] is a fantastic blog/video series covering everything from basic syntax, theoretical basis, modern features and idiomatic constructs.

I highly recommend it if you want to get the gist of Prolog and its modern features.

If you want a tour of Prolog, you can watch the video with that name [1].

[0]: https://www.metalevel.at/prolog

[1]: https://youtu.be/8XUutFBbUrg

I've gone through The Art of Prolog, most of The Power of Prolog, and a good chunk of the P-99 problems, and I have to say I'm simultaneously fascinated by and sceptical of Prolog. For some problem domains, implicit search is a very desirable property, and I can definitely see Prolog shining in that case. There are also many desirable properties and possibilities that are often reiterated, but concrete examples of how they would work are often missing. It comes down to: how does "production Prolog" look? A talk on Strange Loop by Michael Hendricks on exactly that topic was really helpful (especially w.r.t. some useful tools and libraries: func and yall are really great, and I still need to check mavis), but it still leaves me wondering on a couple of things.

Pretty much every Prolog book is quite good, but if you have the money or a local library with a copy, I really like Programming in Prolog by Clocksin, or Art of Prolog by Stering and Shapiro. If you want to follow a web resource, the standard suggestion is Markus Triska's The Power of Prolog.

Does nx not work for you? https://github.com/elixir-nx/nx/tree/main/nx#readme

It is historically not great at number computing. This is being addressed by a relatively new project called Nx. https://github.com/elixir-nx/nx

It is not the right choice for CPU intensive tasks like graphics, HFT, etc. Some companies have used Rust to write native extensions for those kinds of problems. https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...

José from the Livebook team. I don't think I can make a pitch because I have limited Python/R experience to use as reference.

My suggestion is for you to give it a try for a day or two and see what you think. I am pretty sure you will find weak spots and I would be very happy to hear any feedback you may have. You can find my email on my GitHub profile (same username).

In general we have grown a lot since the Numerical Elixir effort started two years ago. Here are the main building blocks:

* Nx (https://github.com/elixir-nx/nx/tree/main/nx#readme): equivalent to Numpy, deeply inspired by JAX. Runs on both CPU and GPU via Google XLA (also used by JAX/Tensorflow) and supports tensor serving out of the box

* Axon (https://github.com/elixir-nx/axon): Nx-powered neural networks

* Bumblebee (https://github.com/elixir-nx/bumblebee): Equivalent to HuggingFace Transformers. We have implemented several models and that's what powers the Machine Learning integration in Livebook (see the announcement for more info: https://news.livebook.dev/announcing-bumblebee-gpt2-stable-d...)

* Explorer (https://github.com/elixir-nx/explorer): Series and DataFrames, as per this thread.

* Scholar (https://github.com/elixir-nx/scholar): Nx-based traditional Machine Learning. This one is the most recent effort of them all. We are treading the same path as scikit-learn but quite early on. However, because we are built on Nx, everything is derivable, GPU-ready, distributable, etc.

Regarding visualization, we have "smart cells" for VegaLite and MapLibre, similar to how we did "Data Transformations" in the video above. They help you get started with your visualizations and you can jump deep into the code if necessary.

I hope this helps!

> I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language?

Because Rust brings none of the benefits of the BEAM ecosystem to the table.

I was an early Elixir adopter, not working currently as an Elixir developer, but I have deployed one of the largest Elixir applications for a private company in my country.

I know it has limits, but the language itself is only a small part of the whole.

Take ML, Jose Valim and Sean Moriarity have studied the problem, made a plan to tackle it and started solving it piece by piece [1] in a tightly integrated manner, it feels natural, as if Elixir always had those capabilities in a way that no other language does and to put the icing on the cake the community released Livebook [2] to interactively explore code and use the new tools in the simplest way possible, something that Python notebooks only dream of being capable of, after a decade of progress

That's not to say that Elixir is superior as a language, but that the ecosystem is flourishing and the community is able to extract the 100% of the benefits from the tools and create new marvellously crafted ones, that push the limits forward every time, in such a simple manner, that it looks like magic.

And going back to Rust, you can write Rust if you need speed or for whatever reason you feel it's the right tool for the job, it's totally integrated [3][4], again in a way that many other languages can only dream of, and it's in fact the reason I've learned Rust in the first place.

The opposite is not true, if you write Rust, you write Rust, and that's it. You can't take advantage of the many features the BEAM offers, OTP, hot code reloading, full inspection of running systems, distribution, scalability, fault tolerance, soft real time etc. etc. etc.

But of course if you don't see any advantage in them, it means you probably don't need them (one other option is that you still don't know you want them :] ). In that case Rust is as good as any other language, but for a backend, even though I gently despise it, Java (or Kotlin) might be a better option.

[1] https://github.com/elixir-nx/nx https://github.com/elixir-nx/axon

[2] https://livebook.dev/

[3] https://github.com/rusterlium/rustler

[4] https://dashbit.co/blog/rustler-precompiled

(including docs and tests!): https://github.com/elixir-nx/nx/pull/1090

I'll be glad to answer questions about Nx or anything from Livebook's launch week!

I think that experiment is taking shape with Elixir:

https://github.com/elixir-nx/nx

However the issue here at Nx https://github.com/elixir-nx/nx/issues/490 is already closed.

Outside of that, Elixir can be used for data pipelines, audio-video processing, and it is making inroads on Machine Learning with projects like Livebook, Nx, and Bumblebee.