You'll have an easy time using browserify together with es6ify. Look at the first commit on branch with-es6ify of my example-browserify repo. Easy. Fun. Prettier javascript.

You run browserify . -o bundle.js and it transforms this:

( () => console.log('im in ur es6 havin ur bundle.js!') )()

into this:

((function() {
  return console.log('im in ur es6 havin ur bundle.js!');
}))();

Nooice*.

Later I will try out all of the supported es6 features to make sure I understand them and find out which ones depend on the traceur runtime.


* Or browserify index.js -o bundle.js; or npm run browserify (because of what I put in scripts in package.json); or watchify . -o bundle.js if you want it to recompile automatically when the file changes; or npm run watchify. Passing --debug to either of these is good; it gives you sourcemaps so that your browser shows you the original source when errors happen.


i want my live-preview inputs to be crazy liberating. define my own heredocs, then use them everywheres.

{{{jade

p.edit 2014-10-04 here's a sepcial edit class!!!

}}}


```jade

p.edit this un would do verbatim highlighting

```

defining your own markup language. need composability.

***huh?

this might preprocess through `huh?` langugae (i made it up) **and**
through *markdown* too
because of the *meaning* of "***huh?"

[ ] : or through GH flavored markdown

***

what are all the ways to effect composability?

A -> {t1, t2} -> (B, C) -> {weaver/joiner} -> D
A -> t1 -> B -> t2 -> C
A -> t1 -> (A, B) -> t2 -> C

^ better provide english description each of those so i can remember what it means later

A -> {t1, t2} -> (B, C) -> {weaver/joiner} -> D

you might have text A that you want to transform through each of two transformers t1 & t2 to produce two new texts B and C which you then transform through a joining function that somehow combines B and C to produce the final text D.

A -> t1 -> B -> t2 -> C

the more typical transformation pipeline. It does not branch. you transform A into B into C.

A -> t1 -> (A, B) -> t2 -> C

a spin on the first two: a joining transform t2 might need access to the original source text to produce the final text.

  • might want to write jade, pipe through hyperglue with some data, then through minify, or do a concat/join with other ones, and then through tex/mathjax, and then a syntax highlighter.
    • sure we could build it all as gulp tasks or through2 transforms, but sometimes we want to make our own disposable syntax and cast cabalistic incantations.
      • point is we humans like to build little private rituals that only we, their author and primary user, can understand.

The couch gag for Simpsons S26E01 was terrifically thought-provoking. It was stirring. It swirled my emotions and left me staring, quiet, mouth agape, thinking profound thoughts.

Even when people who otherwise say intelligent things go on to suggest that The Simpsons has unquestionably changed for the worse, it hasn't. It remains a medium of penetrating yet somehow ordinary glimpses into the many fascinating qualia of life.

About the gag: The future is unpredictable. A portrayal of it should not look futuristic; it's unpredictable. Let the impact of this sink in. It doesn't matter what you hope it will look like; you can't imagine it–not really. No one has and no one will. The future will be weird, because it won't be what anyone was expecting. How beautifully this was depicted.

The gag implied that The Simpsons will live forever. Somehow. The Simpsons will endure even if it is not recognizable to us anymore. The future would not be recognizable if viewed from the present, so why would The Simpsons be? In another sense, we have absorbed The Simpsons. It is a part of us. We are a strange loop with it. It lives in all of us who have loved it. Moreover, it lives in our culture–in the substrate that floats across and above individuals and outlives us all. It is amazingly unique in this distinction. If not unique, it is amazingly rare.

We should hope that one day The Simpsons will look unrecognizable and weird to us; it will have lived into a future where we have not.


* A Love Letter To The Simpsons is a great video–much more nuanced and considered than my obloquy gives it credit for.


For a while I've been trying to read Database Design & Relational Theory: Normal Forms & All That Jazz by CJ Date (no relation). I have a bad habit of picking up new books and reading only the first 3 or 4 chapters before moving on to another book, which is unfortunate for this book because it really starts in earnest at Chapter 5.

i'ma keep some notes here–for my own sake. Before I get to that, I'd like to file a complaint about the level of formality used in this book, but hold on it's not what you think.

Date drops a couple unambiguous warnings in Chapter 5 about how the level of formality is about to soar:

“...it’ll certainly be more formal. For that reason, I don’t want you to look at this chapter at all until you’ve absorbed everything in the previous one.

If that wasn't clear enough*:

“In this section I simply give definitions, with little by way of further elaboration [...] definitions that are rather more precise than the ones typically found in the literature (as well as being more precise, in some cases, than ones given earlier in this book).”

That's a solid burn on the database literature out there. But here's the thing: I wish it was more formal.

To me, formal is Practical Foundations for Programming Languages; it is The Mechanization of Standard ML; it is Homotopy Type Theory. I want to see a database design and relational theory text reach for this level of formality. Let me say that again for dramatic effect:

I want to see a database design and relational theory text as rigorous and formal as contemporary type-theoretic publications.

The world needs this. Now onto notes and outlines...


Warning: I'm rephrasing these into my own words and am probably turning some into wrong definitions in doing so. Any errors are my own.

  • heading – a set. The elements represent attribute names.
  • tuple with heading H – set of pairs \(<A, v>\) pairing each attribute \(A \in H\) with some corresponding value \(v\)
  • tuple projection – a subset of a tuple with heading H
  • relation – an ordered pair comprising a heading \(H\) and a set of tuples \(h\) all having heading \(H\). The components of \(H\) and \(h\) all lift into the relation.
  • relational projection – like tuple projection but lifted into a relation
  • joinable – relations where attributes having the same name have the same type†
  • join – a relation whose heading is the union of all given headings and tuples are the union of all given tuples
  • relation variable (relvar) – a relation lifted into a variable

More to come as I find time.


* Some online reviewers out there really lambaste the excessive formality, despite Date's own warning that formality is imminent. To each his own, I guess. I still wish it was more formal.

† Whoa, see what I mean about the lack of formality? the same type, what does that mean? Before we can say anything about type equality we need to define syntax, judgments, induction, and, oh, types–basically Parts I-IV of PFPL.


I've always taken it for granted that deconstruction, or post-modern non-fiction writing, is empty of meaningful content. Earlier this year I read David Foster Wallace's A Supposedly Fun Thing I'll Never Do Again and his Greatly Exaggerated essay within changed my perspective on the field.

In hindsight, I was guilty of lazy thinking. I judged something before really learning anything about it. My first encounter with deconstruction was from hearing about the Sokal affair*, and my second encounter was an online generator of post-modern nonsense. In fact, everything that I can recall naturally encountering on the internet about PoMo non-fiction has been heavily biased against it and at the time further reinforced my disdain. But let's have some accountability here: lazy thinking is the real culprit. By the way, I still know essentially nothing about any of this, but I am grateful for DFW's lucid introduction.

He sets up the issue with transparency:

If you’re not a critical-theory jockey, then to appreciate why the metaphysical viability of the author is a big deal you have to recognize the difference between a writer—the person whose choices and actions account for a text’s features—and an author—the entity whose intentions are taken to be responsible for a text’s meaning.

Later,

Axiomatic for both schools was the idea of a real author, an entity for whose definition most critics credit Hobbes’s Leviathan, which describes real authors as persons who, first, accept responsibility for a text and, second, “own” that text, i.e. retain the right to determine its meaning. It’s just this definition of “author” that Barthes in ’68 was trying to refute, arguing with respect to the first criterion that a writer cannot determine his text’s consequences enough to be really responsible (Salinger wasn’t hauled into court as an accessory when John Lennon was shot), and with respect to the second that the writer’s not the text’s owner in Hobbes’s sense because it is really critical readers who decide and thus determine what a piece of writing means.

This sounds entirely twenty-first century to me. Individuality and personal meaning are a big thing in present-day social contexts. Who cares what Melville intended to express with that sentence? Here is what it means to ME (who cares but Melville that is, and although I care less about his meaning than my own, I care strongly that his meaning was important to him).

We tend to trust speech over writing because of the immediacy of the speaker: he’s right there, and we can grab him by the lapels and look into his face and figure out just exactly what one single thing he means. But the reason why the poststructuralists are in the literary theory business at all is that they see writing, not speech, as more faithful to the metaphysics of true expression. For Barthes, Derrida, and Foucault, writing is a better animal than speech because it is iterable; it is iterable because it is abstract; and it is abstract because it is a function not of presence but of absence: the reader’s absent when the writer’s writing, and the writer’s absent when the reader’s reading.

Not only is this entirely rational and current, it is mathematical! Also computational. †

The question of meaning and meaning's representation lies at the heart of mathematical logic, and the process of iterable discovery is extremely fashionable in software development right now. It would seem that deconstruction is not empty of content but rather nearly subsumes much of what I admire in contemporary thought.


* My lazy thinking also prevented me from realizing that the hoax was not an effective criticism of an entire field of academia but merely a sign that traditional academic publishing was in need of the internet. Perhaps we need more poststructuralist theories of academic publishing?

† Leave it to DFW to describe literary criticism in a way that brings mathematical thoughts to my mind. Are those my mathematical thoughts or David's?


An npmsearch for pushState showed me substack's single-page module.

The module exemplifies the idiom do one thing well.

I set out looking for a router, but the self-proclaimed tiny ones had extra bulk in them to do hash routing, which I have no interest in right now. In contrast, single-page is like a framework for router plugins: You define your own router and single-page calls your router when the URL changes.

var showPage = singlePage(function myrouter(href) { ... });
showPage('/informal/thank-you-substack');

I wonder: do all of the other routers out there seamlessly plug into single-page? I don't know... It seems to me that they do a lot of extra non-routing junk. Aha! Suddenly this arbitrary, technically-non-routing library is illuminating my idea of what a router is. What are the minimal responsibilities that make something be a router? What does it mean for a router to do one thing well?

Although it does not boast about its small stature, single-page is genuinely tiny! And to me it is epiphanic.

Open Problems

  • How does this contrast with directly using browser pushState?
  • What are all the ways we can declare routes in a router?

  • Does a router have a purpose without single-page?
  • Does single-page have a purpose without a router?

Older shtuff: