flock_user_sanity_check.md

https://developers.googleblog.com/2017/09/how-machine-learning-with-tensorflow.html

Even with an augmented and enriched training set, 
there is no substitute for images created by end-users in a variety of environmental conditions. 

Even with an augmented and enriched training set and test code, there is no substitute for code written and read by end-users in a varitety of conditions.

Even though this paper is

• organized,
• symmetric along abstractions,
• includes formal proofs,
• explicit definitions,
• and implicit applications,

there is no substitute for being read, pondered, and written by end-users.

We knew that scans would sometimes result in an inaccurate code prediction, 
so we needed to provide a user-experience that would allow users to quickly correct these predictions.

We knew that implementations would sometimes result in languages that are too small, too big, too specific, too ambiguous, etc., so we needed to provide a user-experience that would allow readers and writers to quickly recognize and correct these mistakes.

• Recognition is enabled mainly though: small size of the core language, explicitness of the core language, strict bounding
• Correction is enabled mainly though the categorical symmetry: making it easier to predict and implement code to share results

Optimizing for maximum performance
To meet user expectations around performance, we established a few ambitious requirements for the product-code OCR pipeline:

It had to be fast: we needed a one-second average processing time once the image of the product-code was sent into the OCR pipeline

It had to be accurate: our goal was to achieve 95% string recognition accuracy at launch with the guarantee that the model could be improved over time via active learning

It had to be small: the OCR pipeline needs to be small enough to be distributed directly to mobile apps and accommodate over-the-air updates as the model improves over time

It had to handle diverse product code media: dozens of different combinations of font types, bottlecaps, and cardboard fridge-pack media

To meet and exceed user expectations regarding performance, we established a few ambituous requirements for Flock:

It has to be fast

• Flock compiles to bare term-rewriting expressions, which support strict performance, size, and type constraints out of the box.
• This means you can compile to low-level operations and control how far a program can get from that sweet-sweet low-level performance
• This lets you control many of your performance and complexity requirements with a single natural number

It has to be accurate

• Flock's type system is a highly-symmetric categorical model which supports indexed gradual dependent typing out of the box.
• This lets you control many of your accuracy and complexity requirements with a single natural number

It has to be small

• Flock is a tiny language. If it's not small enough for your application, Flock works great when broken up into tiny pieces.
• Where can you make cuts without losing benefits? All listed explicitly in the paper
• How can you connect the pieces to make a larger chunk of Flock? All listed explicitly in the paper

It has to handle diversity

• Flock is built so that its internal models are as diverse and tightly-connected only where it counts.
• How can you expand/contract along a connection in Flock? All listed explicitly in the paper