mirror of
https://github.com/johnkerl/miller.git
synced 2026-07-22 07:30:43 +00:00
181 lines
9 KiB
HTML
181 lines
9 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
|
|
<!-- PAGE GENERATED FROM template.html and content-for-originality.html BY poki. -->
|
|
<!-- PLEASE MAKE CHANGES THERE AND THEN RE-RUN poki. -->
|
|
<head>
|
|
<meta http-equiv="Content-type" content="text/html;charset=UTF-8"/>
|
|
<meta name="description" content="Miller documentation"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0"/> <!-- mobile-friendly -->
|
|
<meta name="keywords"
|
|
content="John Kerl, Kerl, Miller, miller, mlr, OLAP, data analysis software, regression, correlation, variance, data tools, " />
|
|
|
|
<title> How original is Miller? </title>
|
|
<link rel="stylesheet" type="text/css" href="css/miller.css"/>
|
|
<link rel="stylesheet" type="text/css" href="css/poki-callbacks.css"/>
|
|
</head>
|
|
|
|
<!-- ================================================================ -->
|
|
<script type="text/javascript">
|
|
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
|
|
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
|
|
</script>
|
|
<script type="text/javascript">
|
|
try {
|
|
var pageTracker = _gat._getTracker("UA-15651652-1");
|
|
pageTracker._trackPageview();
|
|
} catch(err) {}
|
|
</script>
|
|
<!-- ================================================================ -->
|
|
|
|
<body bgcolor="#ffffff">
|
|
|
|
<!-- ================================================================ -->
|
|
|
|
<!-- navbar -->
|
|
<div class="pokinav">
|
|
<center><titleinbody>Miller</titleinbody></center>
|
|
|
|
<!-- NAVBAR GENERATED FROM template.html BY poki -->
|
|
<br/>
|
|
<a class="poki-navbar-element" href="index.html">Overview</a>
|
|
|
|
<a class="poki-navbar-element" href="faq.html">Using</a>
|
|
|
|
<a class="poki-navbar-element" href="reference.html">Reference</a>
|
|
|
|
<a class="poki-navbar-element" href="why.html"><b>Background</b></a>
|
|
|
|
<a class="poki-navbar-element" href="contact.html">Repository</a>
|
|
|
|
<br/>
|
|
<br/><a href="why.html">Why?</a>
|
|
<br/><a href="whyc.html">Why C?</a>
|
|
<br/><a href="whyc-details.html">Why C: details</a>
|
|
<br/><a href="etymology.html">Why call it Miller?</a>
|
|
<br/><a href="originality.html"><b>How original is Miller?</b></a>
|
|
<br/><a href="performance.html">Performance</a>
|
|
</div>
|
|
|
|
<!-- page body -->
|
|
<p/>
|
|
|
|
<!-- BODY COPIED FROM content-for-originality.html BY poki -->
|
|
<div class="pokitoc">
|
|
<center><titleinbody>How original is Miller?</titleinbody></center>
|
|
</div>
|
|
<p/>
|
|
|
|
<p/> It isn’t. Miller is one of many, many participants in the
|
|
online-analytical-processing culture. Other key participants include
|
|
<code>awk</code>, SQL, spreadsheets, etc. etc. etc. Far from being an original
|
|
concept, Miller explicitly strives to imitate several existing tools:
|
|
|
|
<p/>
|
|
<span class="boldmaroon">Unix toolkit</span>: Intentional similarities as described in
|
|
<a href="feature-comparison.html">Unix-toolkit context</a>.
|
|
|
|
<p/>Recipes abound for command-line data analysis using the Unix toolkit. Here are just a couple of my favorites:
|
|
<ul>
|
|
<li/> <a href="http://en.wikibooks.org/wiki/Ad_Hoc_Data_Analysis_From_The_Unix_Command_Line">http://en.wikibooks.org/wiki/Ad_Hoc_Data_Analysis_From_The_Unix_Command_Line</a>
|
|
<li/> <a href="http://www.gregreda.com/2013/07/15/unix-commands-for-data-science">http://www.gregreda.com/2013/07/15/unix-commands-for-data-science</a>
|
|
<li/> <a href="https://github.com/dbohdan/structured-text-tools">https://github.com/dbohdan/structured-text-tools</a>
|
|
</ul>
|
|
|
|
<p/> <span class="boldmaroon">RecordStream</span>: Miller owes particular inspiration
|
|
to <a href="https://github.com/benbernard/RecordStream">RecordStream</a>. The
|
|
key difference is that RecordStream is a Perl-based tool for manipulating JSON
|
|
(including requiring it to separately manipulate other formats such as CSV into
|
|
and out of JSON), while Miller is fast C which handles its formats natively.
|
|
The similarities include the <code>sort</code>, <code>stats1</code> (analog of
|
|
RecordStream’s <code>collate</code>), and <code>delta</code> operations, as well
|
|
as <code>filter</code> and <code>put</code>, and pretty-print formatting.
|
|
|
|
<p/> <span class="boldmaroon">stats_m</span>: A third source of lineage is my Python
|
|
<a href="https://github.com/johnkerl/scripts-math/tree/master/stats">stats_m</a>
|
|
module. This includes simple single-pass algorithms which form Miller’s
|
|
<code>stats1</code> and <code>stats2</code> subcommands.
|
|
|
|
<p/> <span class="boldmaroon">SQL</span>: Fourthly, Miller’s <code>group-by</code> command
|
|
name is from SQL, as is the term <code>aggregate</code>.
|
|
|
|
<p/> <span class="boldmaroon">Added value</span>:
|
|
Miller’s added values include:
|
|
<ul>
|
|
<li> Name-indexing, compared to the Unix toolkit’s positional indexing.
|
|
<li> Raw speed, compared to <code>awk</code>, RecordStream, <code>stats_m</code>, or various other kinds of Python/Ruby/etc. scripts one can easily create.
|
|
<li> Compact keystroking for many common tasks, with a decent amount of flexibility.
|
|
<li> Ability to handle text files on the Unix pipe, without need for creating database tables, compared to SQL databases.
|
|
<li> Various file formats, and on-the-fly format conversion.
|
|
</ul>
|
|
|
|
<p/><span class="boldmaroon">jq</span>: Miller does for name-indexed text what
|
|
<a href="http://stedolan.github.io/jq/">jq</a> does for JSON. If you’re
|
|
not already familiar with <code>jq</code>, please <a href="http://stedolan.github.io/jq/">check it out!</a>.
|
|
|
|
<p/><span class="boldmaroon">What about similar tools?</span>
|
|
Here’s a comprehensive list:
|
|
<a href="https://github.com/dbohdan/structured-text-tools">https://github.com/dbohdan/structured-text-tools</a>.
|
|
It doesn’t mention <a href="https://github.com/turicas/rows">rows</a> so here’s a plug for that as well.
|
|
As it turns out, I learned about most of these after writing Miller.
|
|
|
|
<p/><span class="boldmaroon">What about DOTADIW?</span> One of the key points of the
|
|
<a href="http://en.wikipedia.org/wiki/Unix_philosophy">Unix philosophy</a> is
|
|
that a tool should do one thing and do it well. Hence <code>sort</code> and
|
|
<code>cut</code> do just one thing. Why does Miller put <code>awk</code>-like
|
|
processing, a few SQL-like operations, and statistical reduction all into one
|
|
tool (see also <a href="reference.html">Main reference</a>)? This is a fair
|
|
question. First note that many standard tools, such as <code>awk</code> and
|
|
<code>perl</code>, do quite a few things — as does <code>jq</code>. But I could
|
|
have pushed for putting format awareness and name-indexing options into
|
|
<code>cut</code>, <code>awk</code>, and so on (so you could do <code>cut -f
|
|
hostname,uptime</code> or <code>awk '{sum += $x*$y}END{print sum}'</code>). Patching
|
|
<code>cut</code>, <code>sort</code>, etc. on multiple operating systems is a
|
|
non-starter in terms of uptake. Moreover, it makes sense for me to have Miller
|
|
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.
|
|
|
|
<p/><span class="boldmaroon">Why not use Perl/Python/Ruby etc.?</span> 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.
|
|
|
|
<p/>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 <code>eval</code> 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.
|
|
|
|
<p/> <span class="boldmaroon">No, really, why one more command-line data-manipulation
|
|
tool?</span> I wrote Miller because I was frustrated with tools like
|
|
<code>grep</code>, <code>sed</code>, and so on being <i>line-aware</i> without being
|
|
<i>format-aware</i>. The single most poignant example I can think of is seeing
|
|
people grep data lines out of their CSV files and sadly losing their header
|
|
lines. While some lighter-than-SQL processing is very nice to have, at core I
|
|
wanted the format-awareness of <a
|
|
href="https://github.com/benbernard/RecordStream">RecordStream</a> combined
|
|
with the raw speed of the Unix toolkit. Miller does precisely that.
|
|
|
|
<!-- ================================================================ -->
|
|
<script type="text/javascript" src="js/miller-doc-toggler.js"></script>
|
|
<!-- wtf -->
|
|
<script type="text/javascript">
|
|
// Put this at the bottom of the page since its constructor scans the
|
|
// document's div tags to find the toggleables.
|
|
const bodyToggler = new MillerDocToggler(
|
|
"body_section_toggle_",
|
|
'maroon',
|
|
'maroon',
|
|
);
|
|
</script>
|
|
|
|
</body>
|
|
</html>
|