A tutorial for the Mercury programming language(sebastian.graphics) |
A tutorial for the Mercury programming language(sebastian.graphics) |
"I don't know why anyone would choose to learn this unless they're a very specific kind of masochist"
Well, there are all types in the computer science community, so to each their own. The quote from Alan Perlis in 1982 is definitely interesting too:
"A language that doesn't affect the way you think about programming is not worth knowing"
I'm sure this made a lot of sense in 1982, but it most definitely is not true now. As a mathematician doing a fair amount of numerical analysis, I must know several programming languages, all of which do roughly the same sort of thing, simply because important implementations of certain algorithms are historically spread across multiple languages. God help me if there is an important implementation of something in Mercury that I'll need to decipher one day...
But Mercury is not a language of the same paradigm as those (imperative, array oriented maybe). It's a logical programming language which I must guess, you probably never used any language of this category. In fact many features of logic programming languages never made to mainstream programming languages or they're behind some uncommon libraries.
I guess that is my point; all of the languages I know are of the same paradigm, but I need to know them all for work. So I disagree with the assertion that only languages of a different paradigm from the one you know is worth learning.
It's one of those languages where I'd love to see the mainstreamification of some of its ideas, but as is, it just seems too clunky.
https://github.com/bctnry/gentle-introduction-to-mercury
I'll write more and finish this book in the future, and I'm definitely writing my response to some of you's replies in the book.
I think you're taking that statement too literally, and way too seriously. Many of the epigrams are a bit tongue in cheek, and that one is too.
https://gwern.net/doc/cs/algorithm/1982-perlis.pdf - Full list as a PDF
127 is instructive here:
> 127. Epigrams scorn detail and make a point: They are a superb high-level documentation.
Don't take them literally and act like they're gospel truths you must live your life by. That's not what Perlis was going for with them. Just like you shouldn't take DRY (don't repeat yourself) literally. You should use judgement.
If you need to learn Fortran to write your numeric code, even though Fortran isn't teaching you anything, you should learn Fortran. You have a job to do. But if you don't need to learn Fortran for work, and it has nothing to offer over the other languages you know, why bother with it? That's the key point of the epigram.