You tell me it does cool things. Great, show me. I've looked about on the various pages and can see only one example and I don't understand it:

    text.md:0:10: wallace.uncomparables Comparison of an uncomparable: 'unique' can not be compared.

The tool is in a perfect place to show this off as it's text.

1. Writing isn't coding. In coding, you can do various types of "cargo cult programming" and "copypasta" and what-have-you -- in other words, as long as the code runs you don't necessarily have to know why or how a programming idiom or convention works, or how/why expressing it one way in code is better than expressing it another way in code. This definitionally untrue with writing. If you don't know the why/how of something, then it's better for you to botch it and let the reader attempt to parse it so at least they know what they're dealing with and how to interpret it ("oh, this guy's a non-native speaker, so I'll adjust my reception accordingly" or "ah, this person is kind of clueless about the whole sexist language thing, which is good info for me.").

2. 90% of writing style advice falls into one of two categories: a) hotly debated, and b) totally wrong. Most of it is in the latter category, and this includes Strunk & White (just use google for numerous takedowns of that text). I looked through the PR queue and saw that it consists of eager coders finding style advice from various sources and trying to work that into the tool. That is terrible, terrible, terrible... This will guarantee that the tool will represent a collection of awful writing advice gleaned from dubious sources and wielded with unforgiving ignorance.

This tool may be a terrible idea, but the idea of automated prose linting is not terrible. Most beginner to intermediate writers have tics, and as an editor I often have a couple of writer-specific find/replace things I do when I get a new piece from a particular writer (e.g. "this person uses 'however' when she means 'but', and this person overuses these four business jargon terms, etc.). If editors were able to easily compose and execute writer-specific linters from within something like Wordpress, that would probably be pretty great.

But this particular command line tool is destined to be either totally unused or massively abused.

I'm sorry, I hate to be mean... or, actually, there is a small part of me that enjoys playing Mr. Party Pooper when I see a mob of enthusiastic programmers trying to tie down some great cultural Gulliver with a thousand tiny little automated, black-and-white rules.

This positively screams for a online interface to test drive.

> detecting grammatical errors is AI-complete, requiring human-level intelligence to get things right.

(emphasis mine)

First, there's a problem of usage. When in CS we say that a problem is class-complete (like NP-complete), we mean that the problem belongs to the class (which in this case is true, because human-level intelligence can check grammar), but also that it is class-hard, which informally means "at least as hard as the hardest problems in class", and more formally means that any other problem in class can be cheaply reduced to the problem, and so finding a suitable solution to the problem is identical to finding a suitable solution to all other problems in class. Not only checking grammar not known to be "AI-complete" then, we don't even know that human-level intelligence is necessary to solve it.

But the reason this bothers me even though I fully understand the statement was made informally, is a little deeper than that: we don't even know what "human-level intelligence" (or intelligence in general) is, let alone what AI means. That people refer to AI as if it's a thing rather than a very vague notion, clouds how people think of AI research as well as intelligence. I would have simply said "we don't know of good algorithms to dependably check grammar, and this appears to be a very hard problem that may require intelligence".

I ran it on a couple 800 word emails and it didn't catch anything except me using 2 spaces instead of 1 in one place. I also ran it on my city's sidewalk maintenance ordinance, and it didn't report anything.

[0]- http://www.hemingwayapp.com/

Prose isn't code.

Many key elements of good writing are based around the idea of knowing the rules, and then carefully breaking them.

It sounds really awesome but it's very hard to tell if it's going to be more annoying or more useful. Maybe it would be useful to have some example linting errors on the homepage.

Either way, I really love the idea!

EDIT: I must be blind - they say about ST plugin (although they don't link to it). https://packagecontrol.io/packages/SublimeLinter-contrib-pro...

Have copy on web site be intentionally incorrect, red-underlined with (small modals? tooltips?) that show what's been corrected/suggested by the tool.

Is there any word on business model / the intentions of the developers? Is it something that's being open sourced and then integration assistance would be commercialised?

Could you include a sample .proselintrc? rc files tend to have very different opinions on how to be formatted: dictionaries, JSON, bash-argument syntax, and so on. (EDIT: Ah, found one: https://github.com/amperser/proselint/blob/cd428bb0ecc5530c1.... Can’t quite get it to ignore butterick, though.)

I find it a little curious that you use a Markdown example and lint for curly quotes and unicode ellipses by default (butterick), since Markdown discourages such pre-formatting in its syntax, but that’s just hairsplitting, of which I can tell by your swelling Issues count that you have plenty of as it is. :)

Looking forward to some formatting/syntax highlighting in the CLI output, but I know you have your hands full as it is.

Nice idea, but you need to catch homophone errors.

After testing this against a dozen of my blog posts, I'm not terribly impressed with the output. I get more immediate value out of MarkedApp's keyword drawer and word repetition visualization.

To the author(s): Your website, as far as I could tell, doesn't tell me how to install it; I had to go to GitHub to realize it was pip-installable. You should consider adding that to the main page.

Bug report — it told me I had too many exclamation marks in a Markdown file with a number of images in it.

re 2, you'll see at http://proselint.com/approach/ that one of the guiding principles of Proselint is that we defer to experts. In practice, that's meant almost all the advice comes from Bryan Garner's usage guide, Garner's Modern American Usage. He is a careful compiler of advice and you'll find that he is almost never "totally wrong", and when his advice is debated, he knows it, notes it, and provides a thoughtful discussion.

re 1, we think of Proselint as eventually being useful as a training tool, a way to learn the conventions. Note that natural languages are large, with so many low-frequency terms that nobody can learn the whole language. Why err if an automated tool can help? Consider for example demonyms, what you call people from a certain place. How many people know, for example, that people from Manchester are Mancunians, not Manchesterians? Rather than call someone by the wrong name, with Proselint the voice of an expert gently corrects you, and you learn a cool new word.

We aren't a mob of programmers, we are three people who love language, respect it, and think we're 2% of the way to making a great tool, one that The New Yorker could run over its stories to flag issues that its own editors would flag anyways. (In fact, we've done this, running Proselint over a corpus of highly vetted text, and have found numerous issues.)

> This tool may be a terrible idea, but the idea of automated prose linting is not terrible.

So which is it? The idea of the tool is prose linting, and you've now stated both that you dislike it quite a bit, and that it's not terrible.

Part of what I think you may be missing, is that it doesn't need to be an all inclusive set of generally terrible, conflicting suggestions. With code style checkers we've already mostly solved this problem, by both storing metadata regarding the source of the rules, and allowing this metadata to be referenced when making custom rulesets. Perl::Critic[1] is a good example of this. It allows you to use the default ruleset and select a severity of criticism, or it allows an organisation (or individual) to create their own custom ruleset to enforce how they want their code to look.

Keeping this in mind, what if the default ruleset was curated to have select rules from multiple sources, but allowed you to easily take a source and use its rules? For example, if I want to write using Strunk & White today, that might be as easy as a command line flag, or downloading a specifically compiled ruleset. If I want to use something else, the same. If I want to make my own custom ruleset based on rules from multiple rulesets and a few of my own thrown in, that should be possible too.

1: https://en.wikipedia.org/wiki/Perl::Critic

1) Editing fiction by Terry Pratchett -- not too useful. 2) Editing a newspaper article -- maybe it would catch a few typo-level issues that crept in under deadline pressure, but a professional writer wouldn't lean on it. 3) A non-native speaker of English running meeting minutes through it before blasting out the e-mail -- that has a lot of utility. (Actually, the "I went to engineering school because I dislike writing." native speaker of English would benefit from linting that e-mail, too.)

You dislike this tool the same way welders dislike computer welding or the same way truck drivers will dislike automated driving.

Everyone wants to believe their job is so complex that a computer will never be able to perform the same task adequately. Is critiquing a sentence really as complex as driving a car in heavy traffic? Or playing chess? Or finding faces in photographs? Or winning on Jeopardy?

You look like my wife complaining of GPS devices because sometimes they error or take us to dangerous places. It is just a took, you can just ignore its recommendations.

This could be a benefit in industries where the goal is to have homogenous writing that meets a given set of specifications/standards. Some ideas:

1. Peer-reviewed scientific writing and/or abstracts

2. Manuals

3. Materials written for a subset of language (EFL, pidgin, children's books)

4. Documentation

But still, it corrects incorrect things that my spell checker doesn't see, like inconsistent spacing and 'goofy approximations' like (R) for ®. (Depends on your definition of incorrect, but I personally would not mind at all if these things were homogenized for everyone, it would not take any richness out of the English language).

What I'd like (--help doesn't list such an option) would be to be able to enable some checks with a flag while disabling other parts (the ones that contain suggestions you can elect to break).

First, much of the advice is that certain word sequences are problematic without suggesting any particular replacement text. There are a few reasons for this (including the computational natures of error-detection vs. solution-recommendation problems). The reason most relevant to your concern is that solution-recommendations are more likely to produce a homogenizing effect because they have a driving effect, wherein using a particular set of words is deemed superior to another set of words. Much in the way that the diversity of life-forms has arisen because of selective pressures, by eliminating the least fit combinations of words, the native variation in writing can flourish all the more readily.

The goal is not to homogenize text for the sake of uniformity, but rather to identify those cases that have been identified by respected authors and usage guides as being specifically problematic. Any text that is sufficiently artful and compelling to have not been specifically addressed by these sources should not be able to be caught by the linter. Novelty will continue to introduce new usages, and some of them will be poor. Authors identified as trustworthy may point these out, but this will only be in retrospect. If you do not trust a guide's point of view, our strongest recommendation would be to turn off the modules associated with that guide. You can see some of the module names and a high-level description here: http://proselint.com/checks/.

Finally, I will modify a quote in the Foreword[^fn2] by Robert Bringhurst in The Elements of Typographic Style (version 3.2, 2004) > [Language usage] thrives as a shared concern — and there are no paths at all where there are no shared desires and directions. A [language user] determined to forge new routes must move, like other solitary travelers, through uninhabited country and against the grain of the land, crossing common thoroughfares in the silence before dawn. The subject [of proselint] is not [stylistic] solitude, but the old, well-traveled roads at the core of the tradition: paths that each of us is free to follow or not, and to enter and leave when we choose — if only we know the paths are there and have a sense of where the lead. That freedom is denied us if the tradition is concealed or left for dead. Originality is everywhere, but much originality is blocked if the way back to earlier discoveries is cut or overgrown.

[^fn2]: Only because we are on the topic of historical traditions and stylistic guides, it should be mentioned that a foreword – according to book design tradition – would be written by an individual other than the author about the author, the book, and usually the relation between them. In this case, the section in Bringhurst's masterpiece labeled "Foreword" would likely be better described as "Preface" or "Introduction". Given his knowledge of book design, I shall assume that this was a conscious departure from the road of tradition, even if I cannot appreciate the new view that it offers.

I was writing some C earlier and my linter warned me about "incrementing a void pointer". However, I understood the context better than my linter, knew that I'd be compiling with gcc (which allows void pointer arithmetic), so I ignored the warning and carried on. My code compiled and ran nicely.

When it comes to static analysis, I think (creative) writers, like programmers, wouldn't care about warnings. This is already true of spell-checkers (e.g. my letter-writing character is English, but my text-editor's yelling about "colour").

For a skilled writer who takes time to write "proper" prose, probably not very useful.

But for me, as a non-native english speaker who writes a lot of short english texts (emails, documentation, HN comments and so on), it could probably help.

For example, since I write both US and British English every day, a consistency warning is certainly helpful. I would also like a linter to help the flow of text, for example by pointing out when you aren't mixing up your sentence lengths in a good way. Oh, in that last sentence I accidentally missed that I used first person in the sentence before that! A linter as a chrome plugin would have pointed that out.

I can imagine a tool like this making it much easier for journalists to follow a newspaper's style guide or something similar.

That said, I think there's a better way to approach this. Rather than linting based on a list of rules, I'd prefer a more technical approach that highlighted actual issues, such as garden path sentences, ambiguous pronouns, doubled words, etc.

While "$10 USD" may be redundant in a newspaper published in the USA, it's immensely useful and arguably preferable when writing blog posts, emails and other text destined for the "World Wide" Web. While USD is commonly used as and many are comfortable with its use as a "common denominator" when pricing something on the Internet, it's still very important to be clear "what dollars do you mean" in this context.

People in Australia might disagree. As might people in Bermuda, Colombia, Canada, Hong Kong, Argentina, ...

https://en.wikipedia.org/wiki/Dollar#Other_national_currenci...