Skip to content

Commit a7ed243

Browse files
author
Steve Krouse
committed
## A tad lost in FRP Land
* TOC {: toc } Unfortunately, Thursday was a bit of a bust. I went to the Games for Changes conference but didn't get inspired. I imagine that'll be the case for most conferences - unless they're _nonferences_, which is basically a conference without talks and focuses on peer-to-peer interactions. ### Fall 2018 conferences Speaking of nonferences, the tickets for CycleJSConf 2018 go online today and they only have 40 spots so I should decide about that ASAP. It looks like a long an expensive flight, so I'll have to think on it... As an aside, my girlfriend and I are thinking about moving to London in the next few months, in which case it's cheap and a 2 hour flight. But then it'll be harder to get back to the States for Splash in Boston in early Nov.... These conferences are complicated and expensive! * Sep 26-28 Strangeloop (and elm-conf) St. Louis * Oct 17-19 CycleConf Copenhagen * Nov 4-9 SPLASH Boston ### A fourth vision-y essay I spent 2 hours on Friday (before I had to go to Philly for my grandfather's birthday) on yet another vision-y essay. This one is about how the smallest unit of improvement a person can make in technology is an app, and how that's too big, especially when people mostly just want to add on to existing apps with a feature or customization. ### Casual, comprehensible, visual essay At this point I have 4 such essays: 1. [Apps are too big as a unit of improvement](/essays/app-idea) 2. [People will (learn to) improve software if it's not too hard](/essays/power) 3. [Software needs to be casually improved](/essays/causal) 4. [In order to be casually improved, it needs to be visual](/essays/visual) And starting on Wednesday, I've been maintaining a Workflowy nested list of the "outline" of this massive essay / thought dump. Workflowy felt like the right tool for this because I'm making a linear argument with a lot of tangents and nested points, and I want to be able to zoom in and out on the sub-points as well as collapse arguments to see the broader shape. The Workflowy is not on source control, so I put [the current version of it in this gist](https://gist.github.com/stevekrouse/626422d9c0e99629afda2a227374911c), and [here's a link to the live one](https://workflowy.com/s/BeQ_.L6nCI8NokW). For better or for worse, these ideas keep metastasizing and gobbling up other projects into their purview. For example, on Friday I re-read [the final STEPS report](http://www.vpri.org/pdf/tr2012001_steps.pdf) as well as Guido's [Computer Programming for Everybody](https://www.python.org/doc/essays/cp4e/), the second of which I found from watching [@roml's Liberal Software](https://www.youtube.com/watch?v=i3nJR7PNgI4). All three projects were highly related and I copied and pasted lots of their text into the Workflowy for reference. I also sent an email to @roml, asking for help articulating the vision for "liberal software." It's a fascinating vision. In particular, I want to clarify how it's different from the Smalltalk, Lively Kernal, Morphic, STEPS, Boxer vision of a unified computing environment. Maybe it's not different from those, but it feels different. For one, I'm more concerned with web-based tools, while those are more OS based. For another, I care a lot about the visual polish of the end software, while those almost deliberately seem to not. I'd love to zoom in on a sub-topic of my outline and write / polish that concept well so I can publish it, get it out there, but I am finding that easier said than done. I'm also becoming cognizant of how long this writing is taking me, and am worried that it's not the best use of my time... Maybe I should go back to the problem as opposed to motivating and contextualizing the problem. On the plus side, I've become skilled enough in communicating what I'm working on and why that yesterday I was able to explain it at a party (in conjunction with Nadia's [Independent Researcher article](https://nadiaeghbal.com/independent-research)). Additionally, both Jonathan Edwards and Paul Chiusano sent me a shockingly relevant paper that came out a few days ago, discussed below, which is a great sign that people understand where my head's at. ### Reading & Watching on 6/2/18 I worked from 9:20-2:00 today, had a 45 min break for lunch, and have been working on this write up for the last hour or two. Productive day! (Although it doesn't really feel it because I don't have much tangible to show for it.) #### [Debugging Data Flows in Reactive Programs](http://pure.tudelft.nl/ws/files/38856517/paper.pdf) This is the paper both Paul and Jonathan sent me, which came out a few days ago. I haven't felt this sinking feeling of "oh shit someone already beat me to it" in a long time, which is a great sign. On note I'll make up front: the reasoning in this paper feels backwards to me. It's saying: people use FRP, it's hard to debug FRP with imperitive debuggers, so let's make visual debuggers. However, I feel that the visualizations are the key to why FRP should be used in the first place, and the fact that we don't already have good visualizations for it crazy. They focus on the [rxjs](https://github.com/ReactiveX/rxjs) library in this example. To be honest, I had considered doing something similar myself, so it's great to see this before I did that. This means that they do visualize streams of streams, but not cyclic streams. They also focus a lot on the user interviews, which I find silly, like they're pretending to be a different kind of science than they are. I speak more about their visualizer, rxfiddle, below in the "FRP Visualizations" section. I find it hilarious that they include a reference to [StoryFlow](http://www.ycwu.org/projects/infovis13.html), a tool to visually track the evolution of a character in a fictional story. It's funny to be because I've been using the [metaphor of fiction](http://futureofcoding.org/essays/casual#reading-fiction) as an example of how it's difficult to follow state in imperative languages. They also cited a bunch of papers at the end of their paper that extolled the importance of seeing runtime values in order to comprehend programs, which fits into my thesis nicely. Currently you have to instrument your code manually or set debug breakpoints to inspect. I want you to be able to look with your eyes, mostly, and interact only a bit to see what's up in a program. #### [Functional Reactive Programming, Continued](https://dl.acm.org/citation.cfm?id=581695) After reading the above paper which focuses on rxjs, I felt my understanding of "true FRP" shaken a bit. I often find it hard to keep them all straight in my head, so I read this article in part to see if I could figure it out. This was an arrowized paper. It helped me get back into the mindset of FRP, but no great insights here. #### [Monadic Functional Reactive Programming](https://www.researchgate.net/publication/262292005_Monadic_Functional_Reactive_Programming) I was in the groove, so I continued on. This article was fascinating, but a bit hard to read because I'm slightly allergic to monads. It was interesting to see that he explicitly says he wasn't able to do "mutually dependent signals." #### [Practical Principled FRP](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.724.7758&rep=rep1&type=pdf) _Forget the past, change the future, FRPNow!_ This paper is apparently the basis for Hareactive/Turbine (discussed more below) and builds upon Monadic FRP. It seems to solve space/time leaks with some clever restrictions about what you can and cannot depend upon. However, as many monadic interfaces do, this feels very imperitive to me. They have a `Now` monad for goodness sake! At the end, they make an tantalizing point that "synchronous dataflow langauges, such as Lustre, Esterel and Lucid Synchrone" ... never have a issue with leaky abstractions, even for higher-order dataflow, because they are more restrictive than traditional FRP" - but he doesn't say in which ways they're more restrictive. #### [Ryan Trinkle - Reflex](https://www.youtube.com/watch?v=dOy7zIk3IUI) Fascinating talk! In particular, I loved the way he explained why FRP is the best: 1. equational reasoning, which I've been calling "definitional" 2. local reasoning, or understanding apart from context, which I've been calling "being able to rule out parts of the application you don't have to read" Another key point I got from the video is that if you want to use ghci with reflex-dom, you can, but then you need to use the ghc binders, which requires a desktop environment to see stuff with. Or something like that. Maybe it means I can use ghci to do more than I thought I could... In the talk, he shows this tutorial on [building a reflex library through building a terminal library](https://github.com/reflex-frp/reflex-platform/blob/develop/examples/host.hs). Looks fascinating! I also skimmed another video, which had [a great example and quote about declarativity](https://youtu.be/92eXGvHFbzs?t=40m33s). He shows dynamic list, whose dependencies are all explicitly listed inside of it. Only one place to (recursively) look. This epitomizes why reflux is the only library I am still excited about. I reached out to [Obsidian](https://obsidian.systems), the Haskell dev shop he runs, to see if they're still hiring. I could definitely see spending some time there, which I can't say about almost any other company. ### FRP Visualizations Before I found the FRP Debugging articles, I was saying something along the lines of: we need visuals that support casual understanding of large, complex software programs. FRP support this because the metaphors are very visual. Just look at [rxmarbles.com](http://rxmarbles.com/) and [the cyclejs devtools](https://github.com/cyclejs/cyclejs/tree/master/devtool). If you wanted to visualize imperitive programs, the best you could do is [Python Tutor](http://pythontutor.com/), which merely helps you "play machine in your head." It turns out, I'm not the only one to want to provide more live visualizations for FRP: #### [rxfiddle](https://rxfiddle.net) My inital reaction to this tool was "neat!" But upon closer inspection, I'm not impressed: * the high-level graph in the middle of the screen is confusing. It'd be best if you could zoom in and out on the same structure for high and low level views. * clicking on data points is confusing * the fact that they show opaque green dots instead of raw data is dumb, especially when it's a number They try to vertically align data points. This is a reasonable strategy but doesn't scale super well for complex flows (maybe better layout could solve this). One idea I had would be to use color to show the lineage/causality of events. One point they make is that more work needs to be done for combinators that modify flows in a less merge-y way, such as filters, folds, etc. Another point is what to do with a high-frequency event. One idea is sparklines, but there are many ways to compress data. Additionally, I find it useful to have both representations of streams: a lazy infinite list, and also a single value that changes over time. One final note is that they only show acyclic graphs, which is insufficient for my purposes as discussed elsewhere. #### [rxviz](https://rxviz.com) These are fun. I like them a lot more than rxfidle. They do a great job of showing higher-order streams. They don't, however, show how streams combine to make other streams. They just show one output stream or stream of streams. For completeness, here are some other links on visualizing FRP programs: * [rxvision](https://jaredforsyth.com/rxvision/) * [Rx Diagrams](https://blog.angularindepth.com/learn-to-combine-rxjs-sequences-with-super-intuitive-interactive-diagrams-20fce8e6511) * [ReScala RP Debugging](https://dl.acm.org/citation.cfm?id=2884815) ### FRP flavors This is a problem I've struggled with for a year or so now. There are so many flavors of FRP out there, with different points on the design space, it's hard to keep them straight. Andre Stalz has some interesting things to say on this topic [here](https://www.reddit.com/r/javascript/comments/3zr6i0/conversation_whats_the_core_differences_between/) and [here](https://staltz.com/unidirectional-user-interface-architectures.html). Jonathan Edwards suggested I make a survey type doc for them. Neat idea. [FRPZoo](https://github.com/gelisam/frp-zoo) already exists but doesn't quite capture what I want. Also, I don't care so much to compare them all. I want to simply find the one model I want and go with it. #### [Turbine](https://github.com/funkia/turbine) Seems like the most Conal-based FRP in JavaScript. However, you add stream on-click handlers in UI elements, which isn't for me. #### CycleJS, Elm, Redux All have the same singleton state + reducer architecture I don't like. However, it is possible to do CycleJS without the singleton state as I did in [this Flappy bird](https://codesandbox.io/s/xlrynkqoqp) about a year ago. The question is: 1) can it do cycles? and 2) how do we like the devtools? #### [Reflex](https://reflex-frp.org) I haven't done much more with this, despite watching the videos above, but it remains the only library I still like, despite the annoying type quantifiers and ghcjs nonesense. #### Purescript Paul Chiusano suggested I see if Purescript has anything I like in FRP land. Maybe it'd be easier than Reflex. ### Next steps 6/2/18 There are a few social things to figure out: * fall conferences * the next FoC meetup in NYC * a possible meetup in Boston with Nicky Case and Glen A few other next steps: * update my Workflowy with notes from today's reading & watching * cyclejs with non-singleton state - can we do cycles? what do the devtools do (particularly as compared to singleton state)? * look for PureScript FRP library * continue learning Reflex. I found [this tutorial](https://github.com/hansroland/reflex-dom-inbits/blob/master/tutorial.md) #### What am I driving towards? 1. An essay about comprehensible programming 2. A comprehensible & casually editable ToDoMVC 3. Tufte-inspired (show data, show comparisons, etc) visualizations (and editor) for cyclical, higher-order, GUI streams #### Anxiety about speed, focus I wish that it was more obvious what I should work on next or focus on for this week. I am feeling a bit anxious about getting to a polished published piece of work that I can point to and be proud of, similar to my Visual History of Eve in that it is polished and got attention, but more impressive and meaningful, like a Staltz or BV article. However, while today wasn't particularly directed, it was definitely quite productive. It took me ~2 hours just to write up all that I did today. I just have to trust in the messiness and hope that a smaller piece of a project will appear and provide itself for polish and publish at some point. As far as tomorrow goes, let's start by re-reading this entry and going from there...
1 parent 3e85df6 commit a7ed243

File tree

2 files changed

+54
-4
lines changed

2 files changed

+54
-4
lines changed

essays/app-idea.md

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: App are a bad unit of change
3+
---
4+
5+
# App are a bad unit of change
6+
7+
What do you get when you cross an ambitious person with a software problem?
8+
9+
An app idea.
10+
11+
It’s exciting that people feel empowered to improve the world through software. However, it’s a real bummer that the unit of change is “an app,” because apps are clunky, costly things to build.
12+
13+
You would never consider making an app just to solve your own problem, or the problems of your friends. It costs 100s of hours and/or $10k minimum to create even a basic app. Improving our technology is so costly that the only way to justify it is by spreading its cost around over thousands or even millions of users.
14+
15+
This is tragic for a few reasons.
16+
17+
Firstly, our software will only solves the problems of the masses, one-size-fits-all problems. The problems that affect mere thousands, hundreds, or even one person can't be directly addressed via software. It’d be too expensive to create custom software, let alone support it as people's’ needs evolve. Today all the customization we get is a meager settings menu and maybe a few Zapier integrations.
18+
19+
Secondly, the cost of software creation is so high that it pushes most entrepreneurs into wacky Silicon Valley business models, where they give away large portions of their company and then grow as fast as possible to justify that investment. This is a very wasteful model. [Something about how slow software is to iterate, and how it requires full time people to test things.]
20+
21+
Finally, this is most tragic because people don't really want to create new software apps. They just want to slightly improve an existing piece of software. I have a friend who wanted to add a few features to mint.com: new app idea. I had a friend who wanted to improve craigslist: new app idea. These friends then proceeded to create pitch decks, talk to investors, create marketing plans to steal customers away, etc, etc. What if we could funnel all that creative energy into simply improving mint.com and craigslist directly? [1]
22+
23+
Unfortunately, technology doesn’t work that way.
24+
25+
The first problem is that mint.com and craigslist are not open-source, so you can’t improve them directly. The best you can do is a brittle Chrome extension.
26+
27+
Another showstopper: even if they were open-source, that’d only let you create your own separate, competing version of the same service somewhere else. [2] We’d still be stuck in a world where the smallest unit of improvement is an app.
28+
29+
We need what r0ml calls “liberal software,” the ability to fork and edit the runtime environment of an application.
30+
31+
“Imagine a world where source-code management was incorporated into a web site. Users could push their own modifications on branches and specify which version they wanted to use. Even if the source is available today, we don't know how to give people the freedom to modify our web sites at run time. We give them the source, but no way to deploy it. That is something we need to change.”
32+
33+
https://lwn.net/Articles/712376/
34+
35+
36+
[1] Yes, there are some who only start businesses with dollar signs in their eyes, and wouldn't lift a finger to improve the world without monetary reward, but I believe that plenty, if not most, people would jump at the change to solve their own problems, and those of others, if it isn’t too costly.
37+
38+
[2] Yes, you could submit a pull request, but let’s assume the feature you’re adding is not broadly applicable, so not all users of the service would want it.
39+
40+
41+
<script>
42+
43+
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
44+
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
45+
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
46+
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
47+
48+
ga('create', 'UA-103157758-1', 'auto');
49+
ga('send', 'pageview');
50+
51+
</script>
52+
<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>

essays/power.md

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,8 @@
11
---
2-
title: Visual Programming
2+
title: The Trick to Get Any Student Interested In Computer Science and How It'll Change the World
33
---
44

5-
# Visual Programming
6-
7-
The Trick to Get Any Student Interested In Computer Science and How It'll Change the World
5+
# The Trick to Get Any Student Interested In Computer Science and How It'll Change the World
86

97
As a computer science teacher, I sometimes found myself with a student totally uninterested in programming. However I always had a secret in my back pocket that no kid could resist falling for.
108

0 commit comments

Comments
 (0)