Hacker News Reader

Comment by haspok | Hacker News Reader

Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot."

Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax.

Also, there are those kinds of problems where in Prolog you can express and solve them in a few lines, in other languages you struggle a lot (and at the end you just reimplement half of the backtracing engine anyway - see Greenspun's tenth rule). Why it is not more commonly used in banking / finance is one of the greatest mysteries of life.

View on HN

I think the thing to remember that it all started as an interpreter written in Prolog in which we could develop our ideas on what the real problem was and the right semantics of a system for solving them. As we went along our "language" evolved as well and became less and less Prolog and more functional as we removed much Prolog semantics, added functional "stuff" and developed the final syntax.

We had along the way also looked at concurrent logic languages. So by the time we had a language and design rules how to use it most of Prolog had disappeared, though some of its syntax still remained. This language was, of course, Erlang.

While Prolog was a nice base on which to develop our ideas it was never the language we would have used in real life.

It’s really delightful that we’re able to get the thoughts of someone who was there and involved in the genesis of the language.

Thank you for all the time you’ve taken to explain the “why” of Erlang!

(For those unfamiliar, go check out “The Erlang Rationale” and some of rvirding’s posts elsewhere, e.g., on the thread at https://elixirforum.com/t/the-erlang-rationale-by-robert-vir...)

If you want more, from someone else who was there, check out Joe Armstrong's "History of Erlang" paper:

https://dl.acm.org/doi/abs/10.1145/1238844.1238850 -- canonical link and has a video of the related talk (streamable and downloadable).

(Sadly, without ACM membership, the paper itself is paywalled; there are copies of it online though, e.g. https://www.labouseur.com/courses/erlang/history-of-erlang-a... ).

Erlang as a programming language for writing fault-tolerant systems has quite little in common with Prolog, except the syntax. That is, the semantics of Erlang vastly differ from Prolog.

Elixirs syntax is only Ruby like in that it’s very readable IMO. Any similarity with Ruby stops there.

Well sure but you could be more clear.

Block parameters, implicit parentheses for certain method/function calls, uppercase significance, symbolic significance for brackets.

Elixir doesn't have blocks as a separate concept like Ruby. The "blocks" are just syntax sugar for passing keyword lists of code to macros.

What do you mean by "symbolic significance for brackets?"

I’m not sure the word for it, but brackets only ever mean two things, to my knowledge. Hash or Block, in Ruby.

I spent many years in perl, so I’m of the opinion visual indicators for datatypes are actually a good thing at the point of instantiation/composition.

Not sure how to properly word it

Oh, are all the paren/bracket types interchangeable in Perl? I've never used Perl.

Yea, each set of them ([], (), {}, <>) has a very distinct meaning in Elixir.

Well in perl there’s a concept of sigils.

my @num = (1, 2, 3);

my $num = 25;

say $num[1];

So that last line prints 2, which is obvious by looking at it, but can be difficult in more complex code when you’re overloading names by the way the variable is accessed.

Everything in perl is a rabbit hole of details, as an aside.

Anyhow, I just appreciate that the symbols always mean the same thing. Takes a load off of my brain. Like a single character type annotation, kinda.

backtracking isn't hard to implement, though. Depth-first search is more or less what it is. But erlang lost most of the prolog ancestry, backtracking isn't there, for example. BEAM has a lot of concurrency neatness though, hard to reimplement or even mimic in languages not specifically tailored for from ground up.

I think Elixir's Ruby-like syntax is one of the many things that make it great.

Comparing the two, I think Prolog may be easier for handling databases (I like Ecto, but it can be a little complex to set up and get right). Both Elixir and Prolog handle pattern-matching, but I think Elixir's syntax is nicer to work with. Of course, this is subjective. Both are great at handling list data. IO is consistently easy with Elixir whereas it can be difficult at times with Prolog.

Elixir and Erlang allow you to create supervision trees which can watch code and automatically and quickly recover from unexpected errors. Prolog's error handling and recovery can be slow. The overheard of calling a goal through catch/3, for instance, is quite significant compared to Elixir/Erlang.

Have you seen gleam.run? It’s pretty neat.

I preferred the alpha syntax, which was ML-inspired, but it’s decent in its current incarnation.

I’ve always though the beam was really nice for building programming languages, and clearly that is true, as there are now more than a dozen targeting it.

Thank you for this! I love elixir and Erlang but I hate elixir’s syntax, so Gleam looks really cool!

Are you aware of other beam-targeting languages?

Have I got a link for you!

https://github.com/llaisdy/beam_languages

See you down the rabbit hole!

I will put in a good word for PureScript for the beam with `purerl`. It's my go-to for writing BEAM code nowadays. Notably PureScript tooling including LSP, package management, etc., just works, so you are able to just get to work in internalizing the way OTP and other Erlangy things are expressed in a statically typed, pure language with much better facilities for functional code than any other BEAM language.

https://github.com/purerl/purerl & https://purerl-cookbook.readthedocs.io/ for more information. Join the PureScript discord and the #purerl channel if you want help.

What sort of things do you write with it? You don’t use it professionally do you?

I'm writing proof-of-concept applications in it for our company currently. Our core technology is Erlang (and Elixir), so the jump isn't comparatively as ridiculous as a Java shop suddenly writing PureScript on the BEAM. I trust code written in PureScript far more than I do code written in Elixir and there are already at least 2 companies using `purerl` in production with the majority of their code in PureScript.

With that said, I've been writing Elixir since 2015 and have worked with Erlang & Elixir since a couple of years after that (+ Haskell), so I'm both much more likely to use niche languages and I'm also well versed in using the BEAM. PureScript with `purerl` actually matches Erlang much better than Elixir does, since Elixir spends half the language and standard library trying to not be Erlang, so I find that it's a better match than Elixir even as a citizen of the BEAM, and the type safety is something I've wanted on the BEAM since I first wrote production BEAM code.

All in all I've been blown away by how solid `purerl` is. The runtime is Erlang, the language is excellent; it's what I dreamed about Haskell being but couldn't quite get.

What's the mistake in going with a Ruby-like syntax? I don't necessarily disagree in terms of wider adoption (though I personally really really like the syntax) though the context is unclear around your statement.

No one can clarify? Did I get downvoted for saying I like Ruby syntax or that I didn't understand the context? I don't understand how pattern matching and Ruby syntax have any correlation. I've never heard of any pattern matching possible in Erlang that was made impossible in Eilxir due to Ruby-like syntax. Am I wrong?

Reply on news.ycombinator.com