From 64c63f28ad313ab34d64dc330d4c325033e2a148 Mon Sep 17 00:00:00 2001 From: John Kerl Date: Fri, 6 May 2016 13:12:38 -0700 Subject: [PATCH] todo --- c/todo.txt | 6 +----- doc/content-for-originality.html | 20 ++++++++++++++++++++ doc/originality.html | 20 ++++++++++++++++++++ 3 files changed, 41 insertions(+), 5 deletions(-) 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:

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:

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