I learned Mercury from Ralph Becket's Mercury tutorial (which is the first link under the documentation section of the site). There are code examples throughout the book that show how the language can be used.

Mercury started out as a subset of Prolog, and is still very Prolog-like. The Mercury compiler is written in Mercury, and that's how it was originally bootstrapped. So anyone that knows Prolog should feel reasonably comfortable writing code in Mercury.

One major difference is the type system, which feels more like Haskell than Prolog (where everything is an atom). Another is the way it handles predicates/functions that can generate multiple outputs - there are no cuts (!), and if a predicate can generate multiple values then it should be declared as such. These type and mode declarations allow the compiler to generate much more efficient code than a Prolog interpreter.

>> One major difference is the type system, which feels more like Haskell than Prolog (where everything is an atom).

Everything in Prolog is a "term", that can be a predicate, a constant or a variable. Constants are predicate symbols (called "functors"), numbers, or character strings of the form [a-z][A-Za-z0-9_]& (where & is the Kleene star that I don't know how to enter in HN comments), or any string enclosed in single quotes, ''. Variables are upper case letters. And predicates are atoms followed by a vector of terms in parentheses, their arguments.

There is often confusion on the matter, because all constants are considered "atomic" and people sometimes use the term "atom" to refer to all atomic constants (where the distinction is clear from the context; allegedly). However, numbers are not atoms, so the following is true:

  ?- atomic(1).
  true.

While the following, false:

  ?- atom(1).
  false.  

There is even more confusion sown by the different use of first-order logic terminology in Prolog. For example, in FOL, a "term" is a constant, a variable or a function given as an argument of a predicate, while an "atom" is a predicate symbol followed by a vector of arguments in parentheses. Perhaps the difference is partly due to the fact that it is ground atoms (i.e. without any variables) that are the most often discussed in FOL, and since constants are ground, they end up being called "atoms" in Prolog.

Then there's the fact that, in Prolog, it's impossible to distinguish between a constant and a predicate symbol or, indeed, between predicates with 0 arguments and constants. Perhaps as a result of this, Prolog accepts predicates as arguments to predicates - since it can't distinguish between 0-arity predicates and constants, it has to accept predicates as arguments, but then, it has to accept n-arity predicates as arguments. Which means that, in principle, it's a FOL language, but in practice, it is actually second-order. Maybe then the reason why predicates are known as "terms" in Prolog is because they can, actually, take the place of terms. But, I don't know for sure.

Anyway, there's a lot of terminlogical confusion around Prolog :)

> Mercury is a logic/functional programming language which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features.

This sentence on the front page succinctly tells me exactly what to expect: the main programming paradigm (logic, functional) and its main strength (performant declarative programming). So I can imagine the language pretty well. I might not know the syntax at all, but yet I can imagine, on an AST level, how known snippets might look like. In any case showing a snippet of Hello World doesn't say much about the language itself; it at best conveys some information about syntactic choices that one gets used to very quickly.

I actually consider this statement very poor. It only appeals to programming language nerds with a wide array of experience. I see a ton of languages make this mistake, of telling me a bunch of features or properties of their language, expecting me to be interested in them for their own sake.

In order to understand this value proposition, you have to know what logic programming, functional programming, and declarative programming are and the relative strengths and weaknesses of each. Also it has a bunch of qualifiers that don't add much to the description. I know what static analysis is, but what is advanced static analysis? You also seem to have intuited that the language is performant, but that is not at all implied here.

A better statement to me would convey exactly what kind of workloads I might want to use Mercury for. As a user, I have something I want to get done, be that processing data, writing a game, or writing a network driver. I don't care about static analysis or logic programming per se. But I would if you told me it would make writing my game easier.

You probably are not the target audience then, its not that the author owes you a personal favor of any kind let alone tie everything in a bow and land it on your lap.

Plenty of people got something out of that page.

The page in general is okay. IMO they should actually lead with the second paragraph, which does mention performance, and some things you might want to do with it. They should combine that with the call out that's strangely floating off to the side that states "Mercury is a general purpose language intended to support the creation of large, reliable and efficient applications."

Here, I'll give it a shot:

"Mercury is a general purpose logic programming language that supports the development of large, reliable, efficient applications through static program analysis and a tunable execution algorithm"

From this one sentence I get the what (logic programming) why (for large reliable apps) and how (static analysis, customizable execution). Now I'm interested.

Yeah, what I was referring to when I mentioned marketing and communication design in another thread. You don't have to make false claims, you just have to shape your wording and content in order to target the right people in a more reliable way.

You can't simply judge a new language by looking at it's surface, as there are not only different languages, there are different coding styles. And then there's probably frame-works on top. So it's very unlikely that the examples will be in the style you would prefer. I think the only way to judge a language is to use it full time for at least one year, but even then you will probably just have scratched the surface. Unless you care for things that can be measured, like speed and performance. Which in case you could probably bend and twist most languages using transpilers or meta - to suit your preferred style.

> I think the only way to judge a language is to use it full time for at least one year, but even then you will probably just have scratched the surface.

In theory, that sounds nice. Have you spent a year on Rust, Go, Elm, and Crystal? If not, then what if one of them is the perfect language for that problem you're trying to solve? How can you make the right judgment call when starting a project if you haven't spent a year using each of these and more?

In reality, that's a completely absurd approach for the first-level approximation people need/want when they discover a new language... surely you realize this. People need to be able to see the big picture before they'll know whether they want to dive into the details.

There are literally thousands of programming languages. Many are created each year. How can anyone afford to spend a year, full-time, on each language to discover the truth of each language? They can't.

So I agree with dotdi:

> Unfortunately, the documentation, FAQ and User Guide all failed in succinctly giving me the information I need: what can it do well, what does a known snippet look like implemented in <Lang>, how does it compare to other languages, etc.

The programming language is not going make or break most projects. Hence the standard advice is to use a language your developers already know.

Picking an obscure language that none of your developers know well is usually not the right decision, even if the language has certain advantages over the ones you already know.

Marketing and good communication design is important though, if you want to actually reach new users. If somebody can't get the gist of what you're about from a glance, they are far less likely to invest a year into giving it a solid try.

Mercury is probably developed and maintained by a very small, even single-perrson team, at this point, so there's most likely an issue of how to best allocate resources. Perhaps the language designers just can't afford a sleek, web-based documentation system, such as other languages have.

Let's also not forget that, just because someone understands how to design and implement a really cool programming language, doesn't mean they understand how to perform "marketing and good communication". And vice-versa. These are often very different skillsets, like designing a racing car and actually racing it.

Again, it's not a given that a small team will have both those sets of skills readily at hand. Which of course, can stunt its growth, further compounding the problem.

I don't mind that it has or not a sleek documentation or just plain html. I just want one or two snippets of code in the main page.

I tried reading the docs (in the html version), and the first example is in the fourth or fifth page.

There is a tutorial in pdf format, that pretty much starts with hello world:

https://www.mercurylang.org/documentation/papers/book.pdf

  :- module hello.
  :- interface.
  :- import_module io.
  :- pred main(io::di, io::uo) is det.
  :- implementation.
  main(IOState_in, IOState_out) :-
    io.write_string("Hello, World!\n", IOState_in, IOState_out).

Is the problem that this is pdf, rather than html?

I usually try the html version first if available (and I asume that the pdf version is equal).

Yeah. One thing I don't do when looking at new languages is downloading PDF files. Actually, having documentation as PDF is a big alarm bell. I think about myself browsing PDF files if I ever end up using the language and flee in terror. Why ever invest time in formatting documentation to generate PDF?

Mercury also has HTML documentation, which is the way to go. However it's missing code samples in the home page and it's not like everybody knows about Mercury. Compare to https://www.ruby-lang.org/en/ which instead is pretty well known and still has code to show at the very beginning of the home page.

Some people prefer to print it out and read it on paper. But if you prefer to read it as a web document, why not convert the PDF to HTML !? I understand there are so many programming languages to choose from so you need to filter them out somehow, but I do not think filtering by documentation formatting is a good heuristic.

A language whose only documentation is paper or PDF (it's not the case of Mercury) is not a language that's going to thrive in this age. It's probably a waste of time to get involved with it. This is why I use documentation format as heuristic.

Additionally, ALL marketing/landing pages should back up their claims with evidence. It doesn't have to be much, but there's definitely bonus points where a short motivation is provided with links to further reading.

It doesn't have to be hard evidence exactly, but if you're claiming that something is easy, fast, "modern", what makes it so?

I concede that you can get away with it to some extent by splicing in "intended to be" in the sentence, but it still places on the visitor the burden of figuring out the "why" behind the marketing.

Oh yeah! Definitely agree with this!

I think the problem is you think everyone else know as much as you do, meanwhile the average programmer are not writing compilers and certainly don't have 30 years of field experience doing so. You imagine any serious programmer would look at your implementation and see where it's better then existing solutions, meanwhile the average programmer is blissful of not knowing the edge cases or at what scale her current tools fail. So sadly you should spend as least 50% if not more of your time at marketing and communications.

Exactly. I agree, not because of vanity, but because if a language fails to market itself well, it's probably not going to succeed in becoming adopted, and adoption breeds support in the form of open source libraries and job prospects.

Most devs don't have the time to pick up esoteric hobbyist languages because they're clever.

One can get a lot of information from examples which otherwise require a lot of literary explanations. Some examples worth more than thousand words.

> You can't simply judge a new language by looking at it's surface

I completely agree. But you also have to at least try to sell it to me. I don't have time to download the compiler, try some examples, build a little side project to find out "nope, don't like it".

> what does a known snippet look like implemented in <Lang>, how does it compare to other languages

https://rosettacode.org/wiki/Mercury

> Unfortunately, the documentation, FAQ and User Guide all failed in succinctly giving me the information I need: what can it do well, what does a known snippet look like implemented in <Lang>, how does it compare to other languages, etc.

What snippet in a purely functional programming language would be simultaneously intelligible and communicate the power of FP to someone who knew only imperative programming? I can't think of a single one that would be meaningfully representative of idiomatic FP. Making sense of FP from IP requires hard work to change your thinking on control flow and data flow.

Mercury is a constraint logic programming language. It's a fundamentally different paradigm, so you're asking for something exactly like what I described above. If you're familiar with constraint LP, then you don't need this sort of snippet, and if you're not familiar with it, I don't think any such snippet would be intelligible to you without hard work.

> What snippet in a purely functional programming language would be simultaneously intelligible and communicate the power of FP to someone who knew only imperative programming?

Propaganda about "the power of FP" was not what your parent was asking for. They were asking for code snippets. They were not asking for a program that shows off all the power of the language.

For whatever it's worth, here is Fibonacci: http://rosettacode.org/wiki/Fibonacci_sequence#Mercury and FizzBuzz: http://rosettacode.org/wiki/FizzBuzz#Mercury

> Mercury is a constraint logic programming language.

Nope. No constraints here. Also, you can mostly ignore the logic part and use it like a functional programming language.

> They were asking for code snippets. They were not asking for a program that shows off all the power of the language.

Talk about missing the main point of my comment. Code snippets that simply embed other paradigms are typically non-idiomatic or just syntactic noise if you're not familiar with the syntax. Code snippets that show off the problems for which the language is perfectly suited are unintelligible to those that don't understand the paradigm. Code snippets simply aren't all that useful if your language has a fundamentally different paradigm.

> Nope. No constraints here.

Strange because they published a paper about adding constraints years ago [1].

[1] https://www.mercurylang.org/documentation/papers/padl_solver...

> Talk about missing the main point of my comment.

I didn't miss your point. Your point was invalid. You were assuming that OP was entirely unfamiliar with functional or logic programming, and that functional or logic programming snippets would be unintelligible to them. You had no reason for these assumptions.

> Strange because they published a paper about adding constraints years ago

Ah thanks, I did not know that. The point above still stands, though: Adding an extension to what calls itself a "logic/functional" language does not make it into only a constraint logic programming language.

> You were assuming that OP was entirely unfamiliar with functional or logic programming, and that functional or logic programming snippets would be unintelligible to them. You had no reason for these assumptions.

No I didn't. I exhaustively covered all cases: "If you're familiar with constraint LP, then you don't need this sort of snippet, and if you're not familiar with it, I don't think any such snippet would be intelligible to you without hard work."

The first clause says that the high-level description as a LP language suffices if you're already familiar with such a concept and so snippets aren't of much use, and if you're not, then a snippet wouldn't help you anyway.

> You are still going on about constraints

Seriously? I merely quoted my original text to demonstrate a completely unrelated point, so you're the one harping on this unnecessarily.

> Also, before, you were going on about functional programming as if OP was not familiar with it: "What snippet in a purely functional programming language would be simultaneously intelligible and communicate the power of FP to someone who knew only imperative programming?"

Right, the point being made is clarified by the text I quoted. If you're familiar with it then you don't need it, and if you're not then it wouldn't help you.