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