The Mercury programming language

It's a wrapper around the native process just to simplify passing command-line arguments. (There is also a persistent process mode for speeding up batch processing of many small documents).

The browsers don't specialise in PDF generation, and we do :)

I'm not the guy you asked but I've been using PrinceXML to produce PDFs intended for customers of our client (e.g. invoices, terms and conditions, itineraries, etc.). Sure, we could just display the HTML and let either the customer or the sales agent press "Print to PDF" but it's not very user friendly—non-power users may not know that "print to PDF" is even an option—nor is it particularly practical for batch processing.

Full disclosure: If I'd had my way we would have used LaTeX templates to produce the PDFs but the previous developers had already implemented the HTML->PDF flow, so we just replaced the old, defunct service with Prince, which did a surprisingly good job, IMO.

Prince is pretty powerful when it comes to print-specific stuff. We care about pagination, making tables look good across page breaks, footnotes, great justification, table of contents, non-sRGB color space handling, crop marks, etc. Also having great accessibility annotations (often mandatory for government documents). These are things that web browsers are less concerned with - print-to-PDF is more of an afterthought, where as for us it's our main area of focus.

That's not even close to what you get with a good HTML -> PDF export, which can include anything from proper pagination, page margins and TOCs, to orphans handling and other such concerns.

The Synfony project use princexml to generate their documentation (including The Book) and it's phenomenally good.

https://symfony.com/doc/current/index.html#gsc.tab=0

Select offline, The book, 4.2 and it generates the book on the fly.

> "How is this different/better than taking <random web browser> and hitting "print"

If you have to repeat this process 2000 times, it becomes time consuming. It doesn't scale for a single user needing 2000 pdfs to do the process manually.

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.

> 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.

> 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".

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

>> 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 :)

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.

> 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.

Mercury is great at basically the same problems you would solve with Prolog, but has added purity markers that help your code not have exponential slowdowns caused by hard to discover bugs.

It's a Turing complete programming language. There are, literally, no programs you can't write in it.

Anything, web servers, systems programming, video games, etc. Its more of a different way of programming and thinking, using logic variables and unification to solve problems. Once you wrap your head around logic programming, its pretty easy and very powerful.

Mercury's selling poings are: - runtime performance (automatic parallelization, very efficient due to logic programming understanding and rewriting sequenced operations) - static typing (in an ml style / like OCaml) - logic programming (unification of lvars)

As a language it fills an interesting niche as logic progamming language typically aren't dyanmically typed or high performance (ie Prolog, most miniKanren implementations).

Paul Bone has some good talks on Mercury if youre interested (heres some slides from an intro talk to Mercury https://paul.bone.id.au/pub/pbone-2015-mercury.pdf)

That's very funny - why don't you post it on HN?

I want to point out that Mercury is an eager language, so it's more like ML than Haskell. It does have the ability to backtrack and execute in reverse, which is kind of magical in the way people think Haskell is.

I wanted to learn it recently, but couldn't find enough example programs.

Yes, uniquenes types for IO (with proper syntactic sugar) really felt powerful, elegant and correct all at the same time.