Comment by dwohnitmok | Hacker News Reader

Comment by dwohnitmok | Hacker News Reader

This list is pretty FP-biased (even Scala, despite being a hybrid language, is mainly well-known for the FP bits it brings to the table rather than any new innovations on the OO side).

There's a lot of other mind-expanding non-FP programming languages. Here are some ones I'd suggest.

For new high-level ideas of programming semantics:

1. Prolog: This teaches you how to program without the notion of "execution" at all. Even in pure FP languages, there is still the notion of "calling" a function which roughly corresponds to a notion of "execution." (yes eventually execution creeps in as you start working with IO, but unification is still a very different way of thinking about programming than function/procedure calls)

2. Forth: RPN on steroids. The semantic foundation of a lot of other esolangs.

For lower-level ideas of how computers work and how programming relates to that (but that don't introduce very different programming semantics):

1. Smalltalk: The usual exemplar of image-based programming. Even if the actual programming model is not terribly esoteric, the way of interacting with the machine being programmed is a very different way of programming than the usual batch-oriented programming model that occurs with a compiler or interpreter constantly being spun up and spun down.

2. Assembly: Again, not terribly esoteric, and not all that interesting from a CS perspective, but it's extremely useful for a working programmer to understand what things compile to.

3. Racket (a modification of Scheme I suppose and not fully outside of FP as a result): You'll never be afraid of creating a DSL again (whether you should of course is a different manner).

Something I always wondered about Prolog: if you're not defining how the program executes (but rather, what it should do), how do you know if something (a constraint) you're asking for is extremely expensive under the hood? Sure you can run the program and see how long it takes, but if your program is based on real-time data it seems like it would be difficult to have any idea if your program will consistently yield proper results in a reasonable amount of time.

Do I misunderstand something about how Prolog and other constraint-based programming languages work?

Nope you're totally right that at some point you have to understand how the Prolog engine actually tries to evaluate things. This is not just for performance, but as I allude to in the case of IO, sometimes necessary for correctness. Usually this is just knowing that Prolog does backtracking, but it can be more involved depending on your performance needs. But often for a complicated enough project you will find yourself resorting to cut quite a bit.

What I meant by execution is more around how it feels to program in Prolog. So many things that feel like "hmmm I need to call this function and then this function here", etc. in other programming languages are just "oh, I just need to substitute a variable here" in Prolog. It's a very interesting world to remove the entire concept of "return" from your lexicon (e.g. a function returning a value).

You can optimize the search, a naive solution would brute force all possible solutions. But you can cut the search short, so adding cuts in the right places will speed it up even tho it doesn't make it pure. You can also memoize results. The difference between a naive and an optimized solution in prolog is orders of magnitude difference.

Prolog appeals to me a lot. In my company we work a lot from written requirements (if X does this, then Y needs to be that). I feel Prolog could fit well with this.

Prolog matches up really well with AI, it just needs the killer library/tools

I really don't understand how/why Prolog (or something Prologesque) isn't more popular and easy to use (extremely linked of course) especially embedded within other languages/frameworks.

It was amazing to me ('mind-expanding' indeed) at university but didn't seem practical then nor now.

The closest I can think of that has solid usage is Terraform (or HCL, but mostly as incarnated in tf). Having studied a course with Prolog certainly gave me a grip on (and liking of) Terraform early on in my encounter with it, and people's struggle with it often seems to come from procedural vs. declarative. Oh and VHDL/Verilog of course. But I've written all that now so I'll leave it! (And they're more outside the sphere of those to whom Prolog could be of benefit, as I see it.)

Then use it, it's easy to interoperate with SWIProlog, you can even have it as serve up a RESTful API.

Your intuition is correct. We're working on a project where 3rd party developers will write their logic in Prolog, which is a boon for both security and ease-of-writing.

Here's a good video explaining some of this, as well as a nice introduction to the language & and how you can use it in your own projects: https://twitter.com/ThePrologClause/status/15006425339400233...

This is exactly what we are using it for on classic.com. Except the rules come from a CMS. Code size dropped 80% going from Python manually written evaluator to Prolog. Give it a shot!

You used quotes around "execution" a lot. I think a better term would be control. SQL, regex literals and so on work similarly, they are declarative while avoiding explicit control.

An opposite would be something like an FSM, or one of these DAGs that people do visual scripting with. These are declarative ways to describe very explicit control.

I initially wrote the word "declarative" but I don't really like it. It implies an objectivity and absoluteness that doesn't align with the subjectivity inherent in trying to tie code to a programmer's intentions. That is what is declarative for one developer or one set of circumstances may smack of being overly procedural for another (see e.g. what opinions you'll get if you tell a population of programmers that regexes are declarative).

To be more specific, SQL and regex literals still don't really capture the magic of Prolog which is unification. It's a heady thing to realize that telling a machine facts and asking it for information is fundamentally the same thing! Just a matter of whether you pass a constant or a variable.

To compare with SQL, it would be as if you did away altogether with the notion of separate `SELECT` and `INSERT` statements and the same prepared SQL statement could be used to mutate the DB or return data just based on what you pass to the `?` parameter.

Reply on news.ycombinator.com