Insidious Optimizations II: Machine Text

>Your blog article doesn't contain any code or empirical data so you can expect it to be rightfully ignored.

That doesn't usually seem to stop them.

>Provide a reference implementation in a widely-used language. I would pick C or Rust. The code should be under a widely used open source license, have high test coverage, and be fuzzed.

I suppose I could go ahead and start writing an initial implementation in Common Lisp; it would likely be under a new article, though. I use the AGPLv3, don't need tests, and don't need fuzzing.

>Provide size and performance benchmarks of real-world datasets. You assert that English words can be encoded compactly so try encoding Wikipedia, Project Gutenberg books, or the text files in the Calgary Corpus.

I prove they can be encoding compactly, but I suppose a more concrete example would help, sure.

>Compare your proposal against state of the art compression algorithms like PPM or LZMA.

I can compare file sizes.

>Fork a text editor application and change it to use your reference implementation. What are the effects on editing latency and RAM usage?

This would be a bit much for me at this stage, and editing text as opposed to reading it is still under consideration; it would likely be implemented with characters and a simple notice when invalid words are created, varying.

>Shared dictionaries were tried in the 1980s (e.g. Spellswell Word Services) but failed in the marketplace. What's different now?

I can't find any information on this, but if it was being sold then I take it that it was proprietary, which would help explain it. Anyway, Microsoft products are dominant, which is evidence that the ''Free Market'' isn't a judge of quality.

In any case, it's nice that something I submitted received any attention whatsoever. Usually, my work goes entirely ignored, but that's hardly the only good work Hacker News doesn't like or understand and so ignores.