## April 8-9, 2019

* TOC
{: toc }

Oh boy, I have a feeling this is going to be one of the biggest log entries I ever write. I may end up taking pieces and splitting them off into their own files, but I also like just plopping thoughts in here too, so we'll see... I also have a feeling this is going to take more than 1 sitting to write, but so I may have to come back to it this afternoon after lunch with my girlfriend and mom...

[Note from the future - the next day, April 9th. This entry did end up needing to be split into two days of effort, which is why the title of this is **8-9**. For the record, the first half of this entry was written mostly on the 8th and the second half mostly on the 9th.]

### <Programming 2019>

First I have to say that I was really not looking forward to this trip. I was already flagellating myself for the mistake of wasting a whole week before I even got there. So I was quite surprised to be entirely delighted by the week, and feel that it was incredibly well spent! 

#### <Programming 2019> Folks

Firstly, I felt very lucky to get to spend so much time with the wonderful crew at Salon de Refuge 2019, including friends from before:

* Antranig Basman
* Joel Jakubovic
* Philip Tchernavskik

and absolutely lovely new friends:

* Luke Church
* Mariana Marasoiu (who I stayed with, along with Luke)
* Clayton Lewis

I also felt like the luckiest obscure researcher in the world as I got to spend time with some of the only "distributed FRP" researchers in the world:

* Guido Salvaneschi (his Towards Distributed Reactive Programming may be the first paper on the topic; he also co-founded REBLS, which I presented at last year, so I met him briefly once before; he is the adviser of Pascal, below)
* Pascal Weisenburger (of SacalaLoci which I also saw at REBLS 2018, but I got to spend a lot more time with him this conf)
* Florian Myter (who I hadn't heard of before but was charmed by, and [presented a glitch-free propagation algorithm for distributed reactivity](https://programming-journal.org/2019/3/5/))
* Wolfgang De Meuter (who is the other co-founder of REBLS, and adviser of Florian above)

I felt incredibly lucky to get to sit at the banquet at a table of *all* of the above FRP people. In fact, I was seated in between Pascal and Florian, which was hilariously awesome.

It may be a good idea to email Pascal or Guido to collaborate somehow as we have similar-ish visions. Ultimately, I am focused on denotational semantics, which according to Guido, might make me more similar to ICFP-types. He suggested I google for "denotational semantics for distributed systems", "denotational consistency" or the "denotational semantics for pi calculi" (which led me to [this Wikipedia article on the denotational semantics on the Actor model](https://en.wikipedia.org/wiki/Denotational_semantics_of_the_Actor_model)). He also suggested this [ICFP paper on Fault Tolerant FRP](https://icfp18.sigplan.org/event/icfp-2018-papers-fault-tolerant-functional-reactive-programming).

I also very much enjoyed meeting Patrick Rein and Jens Licke. I was very sad to miss Patrick's [literature review of LIVE Programming](https://programming-journal.org/2019/3/1/) but I do plan to read it 

#### Visual Denotative Programming @ Salon 2019

Once I met with JE who helped me scrap my version of the talk that was just an outline of my paper, and instead focus on just one particular idea (visualizations), it was a blast to prepare, practice and deliver my Salon talk. I think it went over well, too. As far as I could tell, besides the large-room talks, the most of the other speakers at <Programming 2019> made their slides the night before or day of, and didn't do more than one run-through, if that. So I think my ~5 run-throughs served to make my talk one of the more polished ones. It seemed like more people were keeping their eyes on me than on their computers as they did in other talks. I think there were 15 people in the room for my talk.

My critique from Philip (and from Tomas Petricek who sent in his notes but couldn't attend) was very good. I found that it was excellent in its portrayal of common criticisms of denotational programming, which embed misunderstandings of the model. In particular, I think a common confusion is separating the denotational model from it's UI/PX/notation.

After Philip's talk, the real fun began. We then had a full 30 minutes of the audience asking Philip and I questions about visual denotative programming. I didn't want it to end! Such an indulgence for me: a whole room of brilliant people asking me questions about my passion! On thing I hadn't heard of is GeoGebra, which Clayton mentioned. Luke Church also mentioned Dynamo, which he offered to show me some time later.

#### Maybe confs aren't to be minimized

When I started thinking about attending conferences, I was in a minimization mindset: I hate traveling, and distractions from my deep work on research, so I wanted to go to the fewest the JE would "permit". However, having so thoroughly enjoyed  SPLASH 2018 and <Programming 2019>, particularly LIVE 2018 and Salon 2019, maybe I should reconsider this stance and now think about which other potential conferences I may want to attend... 

(To give you an idea of how much I enjoyed <Programming 2019>... I was so stimulated by the talks, but mostly the conversations I was having, that I wasn't able to fall asleep. My head was revving at a many thoughts a second, so I ended up just staying up late tweeting my thoughts off in big stormy bursts.)

Here's a few conference ideas that immediately come to mind:

* Strangeloop
* PPIG (Aug 28-30 and should I submit by June 12)
* ICFP
* Curry On 
* ICFP (and colocated workshops)

With these being already in my cal:

* SPLASH / LIVE / REBLS Aug papers. Oct 20-25 in Athens
* <Programming 2020>, in Portugal

### Research threads (April 8-9, 2019)

Mostly sparked by bouncing ideas off all the wonderful people at * <Programming 2020>, my brain became very active in developing old "research threads". A research thread is a line of inquiry that my brain has encountered and walked at least a few steps down. [As I'm just one person, I really am only able to walk down one thread at a time](https://twitter.com/stevekrouse/status/1115261356897386497), but I often wander down other threads, mostly for the pure fun of it. The grass is always greener, after all. 

The first subsection (of this subsection) is a "thread" about the *importance* of improving (ideally, democratizing) the construction of user interfaces. This is the foundation for my *current* research thread, gametrail. So while I'm not focused on developing the *importance* argument now, it's in the background of my current research, and worthwhile to iterate on casually. The next section in my current thinking around what has been my main research thread for the past ~6 months since REBLS: gametrail (aka visualizing cyles or a hareactive/turbine devtool). The following subsection four subsections contain insights that push forward other fascinating research threads that will likely be necessary for my BIG VISION of a mashup of Wikipedia, Smalltalk, Haskell, Facebook Origami, and Hazel (leaving out a few sources of inspiration, of course). The final section is related to SciHub, which is only tangentially related to the FUTURE OF CODING.

#### importance of ui ui

To be fair, I walk around wearing ui-colored glasses. It's like walking around with *design of everyday thing* glasses -- which happens to be another pair of glasses I am adding to my closet: you see the ways better interface design could improve things everywhere you look. Here's the shortest way to put it: every time a human communicates with a human who communicates with a computer is an opportunity for user interface design. My tweets (of 1 second ago) say it best:

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">You people think AI is going to eliminate jobs, just wait for the democratization of user-interface construction: anywhere a human communicates with a human who communicates with a machine is an opportunity for a better UI that the first human could use directly</p>&mdash; Steve Krouse (@stevekrouse) <a href="https://twitter.com/stevekrouse/status/1115265446595502080?ref_src=twsrc%5Etfw">April 8, 2019</a></blockquote>

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Such as:<br><br>* ordering food from waiters<br>* many functions of customer support<br>* many functions of retail workers<br>* helping you pay at a register<br><br>ML will help get rid of these jobs as well, but oftentimes a better screen-based UI is the right answer.</p>&mdash; Steve Krouse (@stevekrouse) <a href="https://twitter.com/stevekrouse/status/1115266800802045952?ref_src=twsrc%5Etfw">April 8, 2019</a></blockquote>

After all, I want to input my address in the Uber app, not say it aloud to a self-driving Uber-version of Siri.

#### gametrail

I'm beginning to see how difficult this project is going to be. That doesn't mean I think it's not important, but I want to ensure it's worth my research-time budget for the next 6 months.

For starters, I think my new goal (if I still want to pursue it after this analysis...) should be a Bret-Victor-style-demo of a gametrails dev tool experience, not an actually-working devtool. Let's start there and see if I want to realize it more. One of the main reasons for this downgrade is seeing harective/turbine's API change so quickly; it's just not worth the investment to make something that will be instantly outdated.

However, before resuming the design work for flows, want to take this opportunity of realizing how difficult this is (even with the BV-style simplification) to pause and consider: what problem am I trying to solve here and do these visualizations solve them?

Ultimately, I am trying to democratize UI construction, with something as usable as Squarespace/Facebook Origami, but with fully expressivity, like ReactJS, for example. (Ultimately, I am trying to do something even bigger than this, but UI construction feels basically as hard/easy as any other subtask of my eventual goal of *democratizing human creative expression over computation*, and I might as well continue here because I've already made decent progress.)

As I argued in my Salon talk (which does not yet have a home online... I hope to [add it here](/drafts/dctp) soon), what enables the power and simplicity of spreadsheets visual, dynamic interface is the right computational model: denotative programming. In the same way, denotative programming empowers the power and simplicity of Facebook Origami's beautiful visual environment (and where Origami diverges from the denotational model with pulses, it's power and simplicity suffers, particularly in larger programs). Thus, before I build this dream UI UI, I need to find the right computational model, which I think I found in Conal's DCTP (the artist formerly known as FRP).

However, Conal's flavor of DCTP (from his papers) hasn't caught on at all. Particularly next to the success of their bastard cousins, ReactJS and its ilk, the unpopularity of Conal's DCTPs are glaringly conspicuous. Why is this?

One likely reason is that he hasn't focused on HTML-like applications in his work; he's more focused on abstract, geometric shape animations and interactive. And HTML-like applications add a whole slew of complications of their own on top of time-varying values: the ordering of HTML elements and modeling AJAX requests.

Ok, so which different but least basterdized flavor of FRP should I adopt as my model? I mostly liked Haskell's Reflex's semantics (which I think were the first to model HTML-element-order monadicly), so probably something a lot like that...

Ok... but what language/framework will I *build my tool in*? JE, suggested that I really need to build it in a language/framework with the semantics of the UI UI tool itself. I thought this was an excellent idea, particularly because it would allow me to get more familiarity with DCTP and continue to pinpoint the precise flavor I want the tool to embody.

Haskell's Reflex wasn't really in the running as the language/framework to build the tool *in*. When using it, I was so miserable waiting on the Haskell compiler: 7 seconds for a syntax or type error is 6.5 seconds too much, no matter how beautiful the type system or semantics. JE suggested that I actually create (or find) my own traditional text-based JavaScript (or compile-to-JavaScript via Elm, PureScript or TypeScript) DCTP framework. 

I was very excited to re-discovered the Hareactive/Turbine JavaScript (/TypeScript) framework. It's semantically very similar to Reflex, apart from it's Now-monad (which I have mixed feelings about) and is exceptionally well written, even for a Haskell codebase, let alone a TypeScript one. I began playing with it. It was one order of magnitude better than Reflex simply tighter feedback loop enabled by instant JS "compile time" (which you can auto-trigger every couple of keystrokes). It also didn't hurt that I was able to get it working live at a URL on the codesandbox.io platform.

Yet despite the massive improvement over Reflex, Hareactive/Turbine still wasn't entirely pleasant. (To be honest, the main cause for my dissatisfaction was probably the quickly-changing and meager documentation; in other words, it is a new framework and I was personally roughing down the rough edges.) But the other main issue was that I didn't have good insight into the *structure* of the *streams* I was working with, nor the *structure* of the *data* inside those streams.

A related issue, but one I now see as fully distinct, was having trouble *reading and comprehending existing Hareactive/Turbine code, even when it was written by me* the week prior. So I thought I could combine these two main problems (not including the documentation issue) and build a way to both see the *outer-stream stream-structure* and *inner-stream-data-structure* of a *single stream* as well as the *global structure of dataflow between streams*. And thus gametrail was conceived.

It's important to mention prior work here. I wasn't the first to think to try to solve both problems at once. [RxFiddle](https://rxfiddle.net/) does just that. However, I found both their local stream and global dataflow diagrams lacking. On the other hand, [rxviz](https://rxviz.com/) was the ideal tool to visualize a single stream, animated, totally ignoring the global structure that produced it. I initially disqualified this single-stream approach because it lacked the global structure bit. And of course, [RxMarbles](https://rxmarbles.com/), the original flow viz to entice me many moons ago, was the ideal viz to solve the issue of understanding single stream operators, a real problem I used to feel before I internalized them, but is no longer the most glaringly apparent problem I now face -- and to be fair RxFiddle (and my gametrail idea) does somewhat attack this problem as well. In summary, I was trying to take the best of all these tools, and combine them with some of my own design chops into a single devtool experience for gametrail, that would hopefully point towards (or eventually morph into) the dream UI UI tool.

However, I am now rethinking the scope of this vision. What problems am I really trying to solve here and why? I am solving a problem of a problem of a problem of a sideproblem here. And why am I solving three problems all at the same time, in a single prototype? There's gotta be a way to simplify...

Here's a metaphor for one way to simplify. MS Excel is pretty darn good. Yet it hides the formulas, only lets you look at one formula at a time, and has very limited capabilities for inspecting the global structure of a spreadsheet despite being on such firm denotational grounds for it. And still considering all that, Excel is still better than any other programming environment on a power + simplicity showdown. Thus, if I get the model right (which let's assume I do with some flavor of the denotational model), and get just a one† or two†† things right with the visual environment, I will be "in the money" with power + simplicity. In other words, I won't write the last word on UI UIs but it'll be an order of magnitude better than what came before; even if I can just get one† or two†† things right.

##### †one  

Show the (inner) data (and it's structure/type).  BV says it best, "Some people believe that spreadsheets are popular because of their two-dimensional grid, but that's a minor factor. Spreadsheets rule because they show the data.... If you are serious about creating a programming environment for learning, the **number one thing you can do** -- more important than live coding or [ ... or ... or ... ] or _anything else_ -- is to **show the data**." 

Applying this insight to my problem-domain (which I tried to kinda do in the parenthesis at the beginning of this paragraph), <em>the number one thing I can do is show the **inner-stream state (data)**</em> (which would imply its structure / type in the same way a dollar sign in Excel implies it's type is "USD"). Likely *the close second thing I can do* is either 1) *show the outer-stream structure* or even better 2) <em>automatically do the type/stream **plumbing** to help you get your inner-stream state/data out</em> so you can compute on it. 

In other words, STOP trying to visualize the global stream dataflow and STOP trying to visualize how stream combinators work. Those are super useful things to visualize but they are not the MOST IMPORTANT THING, so punt on them, because, to be honest, they are likely "research problems" in their own right.

##### ††two 

However, I don't want you to get the wrong idea. Going back to BV's Learnable Programming (where I got the above quote), other key environmental factor's of a programming environment are:

a) follow the flow (which is what visualizing stream dataflow is about)
b) read the vocabulary (which is what visualizing stream combinators is about)

Yet I would argue that neither of these are worthy candidates for the second-most important design values to optimize for in a programming environment, because applying similar logic from above:

a) only some spreadsheets, only minimally, allow you to "follow the flow"
b) much of spreadsheet vocabulary aren't common concepts (for example, [HYPGEOMDIST](https://support.google.com/docs/answer/3094004) may require as much if not more learning as [filterApply](https://github.com/funkia/hareactive/blob/e62491685cbee28cd614dae291d4e48cb13b95e0/README.md#filterapplyapredicate-behaviora-a--boolean-stream-streama-streama), to compare two random ones)

But despite these shortcoming's spreadsheets succeed because of the above discussed adherence to "show the data" as well as embodying what I would argue is the _second most important programming environment characteristic_: **create by reacting**, which is distinct from by is enabled by **live coding**. (Quoting Learning Programming again: "it's [live coding] not a particularly interesting idea _in itself_. Immediate-update is merely a _prerequisite_ for doing anything interesting -- it enables _other_ features which require a tight feedback loop.") It's so damn hard to construct all these streams in ones' head. (The essential complexity of UI problems is _surprisingly_ high. We can try to escape it by coding imperitively, but that's just wrapping it in bacon and adding *more* complexity. The only solution to lots of essential complexity is to *augment humans*, and one way of doing that is letting them think small incremental thoughts to existing structures -- instead of forcing them to construct intricate castles that  If we firstly get a tight feedback loop (live coding), and then allow the programmer to start with and gradually sculpt something concrete on the screen, we're in amazing shape.

But again, to be clear, I want to focus on **show the data** as my only focus first, and maybe after that's mostly done, I'll see if I can slip in a **create by reacting**. (The jury is still out on whether **live coding** is absolutely require. My gut says it is, but I don't want to make the mistake again of thinking more things than are necessary are necessary.)

Ok, so let's summarize all that nonsense into a thing I can communicate to JE in our meeting in two hours:

* The Salon went really well. I continue to be excited about the idea of extending the promise of spreadsheets via the denotative and visual perspective, starting with UI construction, but eventually *all the softwares* (as discussed more in the following sections).
* But before I jump back into where I left off, I wanted to take the time to be more precise about the problem I am trying to solve and see if we can come up with a clever-er easier solution. (In other words, avoid the XY Problem.) (In fact, in the interest of being *really* sure to avoid the XY problem, maybe I should do some hareactive/turbine 7GUIs tasks while videoing myself complaining about the hard parts.)
* I think that instead of trying to build <em>a **better RxFiddle** that also works with cyclic DCTP stream</em>, I will instead build <em>**exactly RxVis** for cyclic DCTP streams</em>. 
* Then I evaluate if this solves my problem by continuing the hareactive/turbine 7GUIs to suss out its remaining PX problems. (I should also consider targeting a single stable version of hareactive/turbine instead of constantly playing catch up to their changes to take the API/documentation changes headaches out of consideration.) (Unless there's an even quicker way to test this out... For example, could I use RxJS without and then with RxViz and see if *that* makes a big improvement. The main difference between the two is only cycles, because RxViz visualizes higher-order flows just fine.)
* But let's zoom out even more: the <em>**whole point** of improving my PX while using a JS DCTP framework is to make it usable enough to **build the actual thing I want to build: the UI UI**</em>. (Part of why this is so confusing is that there's meta-ness and bootstrapping everywhere here... In other words, there was a hope that the devtool (gametrail) or otherwise improved developer experience of hareactive/turbine (or an alternative) would _bleed into_ or maybe even _morph into_ the _actual thing I am building_. So I was solving a Y because not only would it help me with solve X faster, but it was also kinda sorta _a simplified version of X_.)

Even shorter: have I sufficiently lost the forest for the trees that I bounce on this PX of my text-based DCTP framework problem for the original problem of GUI (think FB Origami or Josh Horowitz's Pane or Webflow) for DCTP? Because that's the _really_ interesting problem, and I could begin working on it _without_ solving the gametrail problem by starting my design work in doing mockups in Figma. 

#### the ui ui

Ok so now let's jump up from the Y of gametrail to the X of "the ui ui" (which is itself the Y to "democratizing computation's" X). 

I don't have the time or energy to recap and then add my new thoughts to this project, but suffice it to say that it'd mainly be similar to [Aprt.us](http://aprt.us/), but instead of everything being absolutely positioned, everything would be cardinally ordered as children of some parent HTML element. In other words it'd be tree-like in that you can only add items within items or change the order of items -- all ideally via drag-and-drop in some eventual version. 

(As far as drag-and-drop/direct manipulation goes, I think it would easily express all reorderings and the swapping out of components in the "HTML monad." But the _rewiring of the bindings of the recursive_ HTML monad... that's no walk in the park... But as with the last section, that may just be a rough edge to leave in there for another day... and there's also a chance that we can *come up with (or steal from some obscure corner of math) a better, foundation ui paradigm* than HTML's whacky notion of a tree structure but where the children are also ordered as well as there awful hidden dependencies between children, as well as parents...)

Continuing to extend Aprt.us metaphor, just like aprt.us allows you to customize all the properties of shapes but doesn't overwhelm you with options, the ui ui would similarly give you access to all the event streams / behaviors of the "selected element" with the more obvious ones prioritized and the rest hidden. In order to compute with those flows, one would type text based combinator formulas -- the equivalent of aprtus's spreadsheet-like JavaScript formula interface. (Of course we eventually want something better than that, but one step at a time...)

To put this another way, I am leveraging my insights learned by mentally simplifying gametrail (discussed above) to simplify the first version of the ui ui. Just improve slightly on aprtus: add events, cycles and higher-ordered-ness, and don't you dare dream of adding anything else. (Note: I purposefully did *not* include *even single-stream* visualizations in that list. That's too much innovation in one step. Instead we will visualize events as the data of their last occurrence and its timestamp, and behavior's as they currently do: their current values.)

I don't want to do into it now, but one other interesting source of related ideas for the ui ui can be found from a few months ago in the log or here on twitter:

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Love it! The text right below what he quoted:<br><br>We can continue this idea for all kinds of expressions: if-expressions, pattern-matching, lambdas, function application… Can we build nestable custom GUIs for every part of System F/Haskell?! I think so!</p>&mdash; Steve Krouse (@stevekrouse) <a href="https://twitter.com/stevekrouse/status/1074224081535406080?ref_src=twsrc%5Etfw">December 16, 2018</a></blockquote>

#### collaborative end-user programming

Let's go up more more level. This is the X that the last section began with an allusion to. In other words, this is the dream and the ui ui (which is really a holy grail in its own right) is just an implementation detail for.

I've spoken about this vision before elsewhere, so the only thing to add is that maybe instead of slowly building up to it, I should consider skipping to it now, mucking about it what the key problems are, and then retreat with my tail between my legs to the lowers levels that will actually make it possible -- but then I'd be armed at those lower levels with insights!

Ok, that likely didn't make sense to anyone but me. It likely even won't make sense to a future me! Let me be concrete: instead of working on some version of gametrail or ui ui as discussed above, maybe I should recruit a couple fellow revolutionaries to begin collaborating on a piece of end-user software we all use every day, such as email, Slack-like applications, calendars, todo lists, social networks etc. This idea has some spiritual similarity with JE's Chorus, but it's entirely the same because I have a bias towards customizability of the UI instead of the opposite.

I'm sure there are a million details about this that make it not make sense that I haven't even considered, but I think it's a fun project to daydream about working on with Geoffrey Litt and others. (Whenever I am tempted by this, I force myself to remember how frustrating it was to work on BlinkNote. Yes it was a blast at times but it also wasn't practical to be using a bleeding edge notes app with critical data of mine, while developing it on the side.)

#### denotational *programming*

Sorry to tease you with this title, but I don't currently have the time to expand on it. The quick version is: what if we stop programming by mutating a bag of text and instead treat expressions and immutable as the values we want them to express?

#### Denotational -> Mathematical

CS problems get complicated in distributed settings (and others) because they break the core assumptions of  Computer Science:

* one computer
* instantaneous ram access
* instantaneous single CPU computation

What would be a framework that abstracts over all settings (distributed, time-dilated both in space and computational speed) by first making all such assumptions explicit (like I tried to do above), and precise (like I failed to do above), and then abstracting over them all to spawn a more generic programming language.

Here's another way to say almost the same idea: waht if denotational isn't abstract enough? Could it be possible that what I've been yearning for all this time, wasn't a better PX for Haskell, nor even a better PX for Agda or Coq, but actually a something more abstract/math-y than any of those (also with a good PX)? Maybe what I want is TLA+ plus program synthesis, but that doesn't feel quite right either... 

One thing I want to call out now, though: many people seem to subconsciously acknowledge that the future of programming will one day be programming in  Coq/Agda/TLA+ when we can finally make the PX as decent as other languages. But it seems like we've all given up on this problem as "way too hard for our lifetimes" without acknowledging this out loud. I understand people might not want to waste their life researching a moonshot, but at least be honest at you're working on a short-to-medium-term improvement to a inferior version of what we eventually want the solution to be. In other words, like acknowledge that we're in a "program synthesis winter" and talk about what to do about it. (Maybe people in that community already acknowledge this. I need to learn more about them.)

Another related idea: Call-by-bullshit idiosyncrasies of various languages gotta go. This kind of order of operations is paper math bullshit. We got magic ink now - no more implicit, global evaluation-ordering conventions.

As you can tell, I'm getting tired/delirious so I'm just going to link to the remaining ideas for posterity to deal with and decode:

* Higher order types and functions aren't 💯 **https://twitter.com/stevekrouse/status/1113967072478945281?s=19**
* Interesting question: what's the limit of what we can encode into types? **https://twitter.com/csaba_hruska/status/1114500222313476097?s=19**
* I need to learn more about dependent types (as well as finishing TAPL PFPL) and denotational semantics **https://queertypes.com/posts/48-logic-proofs-with-agda-coq-idris.html**

#### nuance all the way down

Quick recent insight about LogicHub: one way to make it more in line with David Deutch's school of thought is to insist that it's truly infinite in the downward direction. In other words:

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">It&#39;s nuances, not 🐢, all the way down</p>&mdash; Steve Krouse (@stevekrouse) <a href="https://twitter.com/stevekrouse/status/1113271898140479496?ref_src=twsrc%5Etfw">April 3, 2019</a></blockquote>

A related insight: _theories/facts/things_ are containers of _metaphors_ that explain only the idea itself but does not defend it, as well some structure that contains _arguments_, where each argument is a thing that attempts to defend it _in terms of other theories/facts/things_, which are similarly recursively defended, all the way down to infinity... An interesting additional point to note: the _structures_ that contain single arguments themselves are also _theories/facts/things_ which need to be defended and can be overturned later, impacting all _theories/facts/things_ that they helped prop up before their dethroning. For example, when (not "if", because we are *always* at the beginning of infinity, *everywhere*) we later learn that some contextual caveat where the _double-blind, controlled study_ is not as effective as previously  thought, all arguments that violate the contexts in which the _double-blind, controlled study_ reigns supreme, those arguments will be appropriately penalized.

### Essay ideas (April 8-9, 2019)

I have 5 essay/talk ideas I have partially outlined to various degrees that I was planning to embed right in this journal entry but I got too tired. So I'll just tease you with their titles and that I will eventually clean up those outlines at some point and add them to the internet soon:

* Natural Langauge is not and will never be the future of coding
* Why *compositionality* is king
* Where is the line between programming vs using a computer?
* What is programming?
* Learning to Code Isn't a Thing

### Reflection (April 8-9, 2019)

* About a month ago I wasn't so happy with my research progress. Getting the flu in SF didn't help. But then I had a fantastic time at &lt;Programming 2019&gt; and now I'm so excited that many nights I can't even fall asleep. (This is actually becoming a big problem. I'm writing this on 2 hours of sleep...)
* One thing that's improved my mood and outlook is that I recently came into a unexpected windfall: the business I cofounded (The Coding Space) was unexpectedly sold. It's not any life-changing money, but it does extend my runway of how long I can continue this research / freelancing / podcast / community organizing lifestyle from ~2 more years to ~6 more years, but that's only if I continue to live quite cheaply, even as I get older. Regardless of how it affects other things, at the very least it eased my mental burden a fair bit.
* In summary, I no longer feel like I need a drastic change to how I split up my time between my projects. The only main thing I need to correct for at this very moment is that I am *embarrassingly* behind on editing and publishing very many recorded podcast conversations (Hillel Wayne, Cyrus Omar, Michael Arntzenius, and Amjad Masad).

### This week (April 8-9, 2019)

Given how hectic this week has gotten with my parents in town, JE coming to town, and possibly a meeting with one of my all-time-heroes next week (more details soon), I am feeling like keeping my priorities small for this week:

* finish transcribing, uploading, and publishing Hillel's podcast
* ditto, for Cyrus Omar's podcast, if possible

### Week of April 15, 2019

* Research
* Podcasts (as long as Ellen from Dark is fine with me punting on presentations for a couple weeks)
* Maybe prep for, and then work with JE on the 19th

### Rest of 2019 (April 8-9, 2019)

Given my great conf experiences, I think I want to re-adopt JE's suggestion to aim my research at specific conference deadlines... and those will be... to be determined when I talk to JE in 10 min!

Sometimes I wonder when I'll ever get to all the resources I collect (and currently organized [on Github Issues](https://github.com/stevekrouse/futureofcoding.org/projects/2)). My new plan is to go to primary sources of inspiration like that (which also includes programming random shit to get annoyed) whenever I am feeling down about the importance or likelihood of success of this work. As long as I'm excited let's move ahead with what's already in my brain!

This isn't really related to the "rest of 2019" section but I had a funny idea to redo my logo with the background image of ["we interrupt your regularly scheduled programming"](https://twitter.com/stevekrouse/status/1114695204420968448)... and I couldn't think of a better place to put this sentence.

Author: Steve Krouse