Typos and grammar errors in "failing-in-haskell"

[phlummox]

Hi,

I noticed some typos and grammatical errors in the "failing in Haskell" blog post, which I think distract a reader from the points being made. (I should say, though, that the post is certainly much better English than I could write in Dutch, or indeed in any other language.) Here are the ones I spotted:

• "Plenty people" should probably be "Plenty of people"
• "how to achieve above properties" should probably be "how to achieve the above properties"
• "safes so much debugging time" should probably be "saves so much debugging time"
• "By which we mean in immutable memory computations" should probably be "By which we mean immutable memory computations" (no need for "in")
• "consdired pure" should presumably be "considered pure"
• "one wonders if this could changed" should be "one wonders if this could be changed"
• "you could factor this out and more typesafe" is not grammatical, though I don't know what's intended. "be more type-safe", perhaps?
• "It's more difficult to recover from an exception then it is" should be "It's more difficult to recover from an exception than it is"
• "If it's important that an error is handled correctly" should be "If it's important that an error be handled correctly" ("be", here, is in the present subjunctive mood)
• "is more preferable" should just be "is preferable"
• "exceptions like above are good" seems incorrect, and should probably be something like "exceptions like those described above are good", or similar
• "If that's to much work" should be "If that's too much work"
• "although it's type" should be "although its type"
• "recover ability" (here and here) should be "recoverability"
• "match on string" should probably be "match on a string"
• "tell what you're talking about to throw" is ungrammatical, though I'm not sure exactly what was meant. Perhaps something like "properly describe the context of the error"?

I hope you find these suggestions helpful in improving the post, and making it more accessible to readers.

I see also that you suggest readers "Let [you] know if [they] disagree, or need help with this", but couldn't spot a "comments" section – is there any suggested forum where readers can comment, if they need help or would like to discuss the post further?

[phlummox]

One other thing you might want to consider is whether "vague" is exactly the term you're after (for instance, here and here).

It's true that in non-technical language, "vague" can be defined as meaning "Of words, language, etc.: Not precise or exact in meaning" [OED]. So one might think that if something isn't precise, it must be vague. However, in software engineering and computer science, "vague" usually seems to be given the same meaning it carries in linguistics and philosophy - namely, some predicate is vague when it is not clear in all cases whether it's satisfied or not. Thus, it's not exactly the same thing as "not precise".

When discussing exceptions, I think that "overly broad" is perhaps more what you're after. "Vague" seems to imply that there can be uncertainty as to the fact of whether (in some particular case) an exception was thrown or not – which I don't think is true in any programming language! "Overly broad", by contrast, just means that we've made a poor choice of type (or class, for OO languages) for the exception - semantically, it could cover a multitude of sorts of situation, and it will not be clear to a caller which of them was the case.

[jappeace]

Thank you!

I appreciate this, you clearly put a lot of effort into this review. I'll go trough your suggestions tonight.

[phlummox]

Quite alright - before programming, my first job was doing proofreading, so it takes very little time.

[jappeace]

These changes were already applied