diff --git a/c/todo.txt b/c/todo.txt
index 0c10ddf62..453c47709 100644
--- a/c/todo.txt
+++ b/c/todo.txt
@@ -10,15 +10,11 @@ TOP-OF-LIST SUMMARY
! rh/fedora/centos mlr-3.5.0 or mlr-4.0.0
-* doc section on programmability spectrum (perl to asic) & how much effort is/isn't worth putting into miller. & maybe
- shouldabeen pickalanguage w/ I/O support and API.
-* in why-miller: list the intersection points. perf; multifmt; math+strings; expressive/programmable; compact notation; pipe-friendly.
-
? call for use-cases? (go first.)
* dsls deps still not quite right?
+
* lrec get followed by put/remove: getext variant returning node for unlink, valpoke, or null == append to avoid
double-searching.
-
* reduce parameter-marshaling by pevalbag; measure perf delta (suspect negligible)
* typed overlay -> mlhmmv rather than lhmsv
* 64-bit lengths for containers. test with 5-billion-integer-seq data.
diff --git a/doc/content-for-originality.html b/doc/content-for-originality.html
index 9caa5d8f7..d3664a83d 100644
--- a/doc/content-for-originality.html
+++ b/doc/content-for-originality.html
@@ -35,7 +35,9 @@ Miller’s added values include:
- Name-indexing, compared to the Unix toolkit’s positional indexing.
- Raw speed, compared to awk, RecordStream, stats_m, or various other kinds of Python/Ruby/etc. scripts one can easily create.
+
- Compact keystroking for many common tasks, with a decent amount of flexibility.
- Ability to handle text files on the Unix pipe, without need for creating database tables, compared to SQL databases.
+
- Various file formats, and on-the-fly format conversion.
jq: Miller does for name-indexed text what
@@ -59,6 +61,24 @@ be a tool which collects together format-aware record-stream processing into
one place, with good reuse of Miller-internal library code for its various
features.
+Why not use Perl/Python/Ruby etc.? Maybe you
+should. With those tools you’ll get far more expressive power, and
+sufficiently quick turnaround time for small-to-medium-sized data. Using
+Miller you’ll get something less than a complete programming language,
+but which is fast, with moderate amounts of flexibility and much less
+keystroking.
+
+When I was first developing Miller I made a survey of several languages.
+Using low-level implementation languages like C, Go, Rust, and Nim, I’d
+need to create my own domain-specific language (DSL) which would always be less
+featured than a full programming language, but I’d get better
+performance. Using high-level interpreted languages such as Perl/Python/Ruby
+I’d get the language’s eval for free and I wouldn’t
+need a DSL; Miller would have mainly been a set of format-specific I/O hooks.
+If I’d gotten good enough performance from the latter I’d have done
+it without question and Miller would be far more flexible. But C won the
+performance criteria by a landslide so we have Miller in C with a custom DSL.
+
No, really, why one more command-line data-manipulation
tool? I wrote Miller because I was frustrated with tools like
grep, sed, and so on being line-aware without being
diff --git a/doc/originality.html b/doc/originality.html
index 3a5edfd20..3f15ddaee 100644
--- a/doc/originality.html
+++ b/doc/originality.html
@@ -174,7 +174,9 @@ Miller’s added values include:
- Name-indexing, compared to the Unix toolkit’s positional indexing.
- Raw speed, compared to awk, RecordStream, stats_m, or various other kinds of Python/Ruby/etc. scripts one can easily create.
+
- Compact keystroking for many common tasks, with a decent amount of flexibility.
- Ability to handle text files on the Unix pipe, without need for creating database tables, compared to SQL databases.
+
- Various file formats, and on-the-fly format conversion.
jq: Miller does for name-indexed text what
@@ -198,6 +200,24 @@ be a tool which collects together format-aware record-stream processing into
one place, with good reuse of Miller-internal library code for its various
features.
+Why not use Perl/Python/Ruby etc.? Maybe you
+should. With those tools you’ll get far more expressive power, and
+sufficiently quick turnaround time for small-to-medium-sized data. Using
+Miller you’ll get something less than a complete programming language,
+but which is fast, with moderate amounts of flexibility and much less
+keystroking.
+
+When I was first developing Miller I made a survey of several languages.
+Using low-level implementation languages like C, Go, Rust, and Nim, I’d
+need to create my own domain-specific language (DSL) which would always be less
+featured than a full programming language, but I’d get better
+performance. Using high-level interpreted languages such as Perl/Python/Ruby
+I’d get the language’s eval for free and I wouldn’t
+need a DSL; Miller would have mainly been a set of format-specific I/O hooks.
+If I’d gotten good enough performance from the latter I’d have done
+it without question and Miller would be far more flexible. But C won the
+performance criteria by a landslide so we have Miller in C with a custom DSL.
+
No, really, why one more command-line data-manipulation
tool? I wrote Miller because I was frustrated with tools like
grep, sed, and so on being line-aware without being