{"action":"created","issue":{"url":"https://api.github.com/repos/stevekrouse/futureofcoding.org/issues/86","repository_url":"https://api.github.com/repos/stevekrouse/futureofcoding.org","labels_url":"https://api.github.com/repos/stevekrouse/futureofcoding.org/issues/86/labels{/name}","comments_url":"https://api.github.com/repos/stevekrouse/futureofcoding.org/issues/86/comments","events_url":"https://api.github.com/repos/stevekrouse/futureofcoding.org/issues/86/events","html_url":"https://github.com/stevekrouse/futureofcoding.org/issues/86","id":380892379,"node_id":"MDU6SXNzdWUzODA4OTIzNzk=","number":86,"title":"p4","user":{"login":"stevekrouse","id":2288939,"node_id":"MDQ6VXNlcjIyODg5Mzk=","avatar_url":"https://avatars2.githubusercontent.com/u/2288939?v=4","gravatar_id":"","url":"https://api.github.com/users/stevekrouse","html_url":"https://github.com/stevekrouse","followers_url":"https://api.github.com/users/stevekrouse/followers","following_url":"https://api.github.com/users/stevekrouse/following{/other_user}","gists_url":"https://api.github.com/users/stevekrouse/gists{/gist_id}","starred_url":"https://api.github.com/users/stevekrouse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stevekrouse/subscriptions","organizations_url":"https://api.github.com/users/stevekrouse/orgs","repos_url":"https://api.github.com/users/stevekrouse/repos","events_url":"https://api.github.com/users/stevekrouse/events{/privacy}","received_events_url":"https://api.github.com/users/stevekrouse/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-11-14T21:22:57Z","updated_at":"2018-11-14T22:01:07Z","closed_at":null,"author_association":"OWNER","body":"https://futureofcoding.org/log#prototype-4\r\n\r\nThe [future work](https://futureofcoding.org/papers/comprehensible-frp/#7-future-work) section of my paper talks about visual metaphors for FRP. While I do think this is quite important in order to \"democratize visual intuition\" ([Penrose](http://penrose.ink/)), I wonder if it's necessary. What if we take normal FRP haskell-ish notation as a starting place and simply augment it with LIVE-ness, such as an interpreted environment, showing data, and evaluating as far as possible even when there are holes (Cyrus Omar's work). Geoff Litt and Paul Chiusano suggested that expressions with holes are just functions with those holes as parameters, and we could put a slider or examples values in there. Always concretions, never pure abstractions.\r\n\r\nHere's another idea I've been toying with: Jason's Brennan's notion of a programming environment on an endless canvas, like in Sketch or Photoshop. One thing this could enable is a structure-less structured editor - in that you could put together pieces of expressions in various places and combine them later. I guess this would be similar to Scratch or Blockly... which I don't love... One possibility is to use the layer metaphor from Photoshop as a programmatic abstraction, but I don't know what that would mean exactly yet.\r\n\r\nMy first thought was to build this as a FP thing first and build my way up to FRP. It could be the [data slice-and-dice ninja thing](https://futureofcoding.org/log#yesterday%E2%80%99s-slice-and-dice-data-ninja-playground), starting with JSON/CSV slice, dicing, and joining -- this is related to [datafun](http://www.rntz.net/datafun/).\r\n\r\nBut then I went ahead and did a drawings for it as an FRP platform:\r\n\r\n![img_0032](https://user-images.githubusercontent.com/2288939/46086431-122c6080-c176-11e8-8a3c-214ab5e09154.jpg)\r\n![img_0033](https://user-images.githubusercontent.com/2288939/46086528-4acc3a00-c176-11e8-9be7-d5e9017bca9a.jpg)\r\n![img_0034](https://user-images.githubusercontent.com/2288939/46086472-296b4e00-c176-11e8-9974-441aaf189d39.jpg)\r\n![img_0035](https://user-images.githubusercontent.com/2288939/46086469-26705d80-c176-11e8-85a8-852189cef443.jpg)"},"comment":{"url":"https://api.github.com/repos/stevekrouse/futureofcoding.org/issues/comments/438834812","html_url":"https://github.com/stevekrouse/futureofcoding.org/issues/86#issuecomment-438834812","issue_url":"https://api.github.com/repos/stevekrouse/futureofcoding.org/issues/86","id":438834812,"node_id":"MDEyOklzc3VlQ29tbWVudDQzODgzNDgxMg==","user":{"login":"stevekrouse","id":2288939,"node_id":"MDQ6VXNlcjIyODg5Mzk=","avatar_url":"https://avatars2.githubusercontent.com/u/2288939?v=4","gravatar_id":"","url":"https://api.github.com/users/stevekrouse","html_url":"https://github.com/stevekrouse","followers_url":"https://api.github.com/users/stevekrouse/followers","following_url":"https://api.github.com/users/stevekrouse/following{/other_user}","gists_url":"https://api.github.com/users/stevekrouse/gists{/gist_id}","starred_url":"https://api.github.com/users/stevekrouse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stevekrouse/subscriptions","organizations_url":"https://api.github.com/users/stevekrouse/orgs","repos_url":"https://api.github.com/users/stevekrouse/repos","events_url":"https://api.github.com/users/stevekrouse/events{/privacy}","received_events_url":"https://api.github.com/users/stevekrouse/received_events","type":"User","site_admin":false},"created_at":"2018-11-14T22:01:07Z","updated_at":"2018-11-14T22:01:07Z","author_association":"OWNER","body":"The goal is to submit this work to \\<Programming\\> in Feb and a good title for the PX workshop (says JE) is \"FRP eXperience\".\r\n\r\nThere are a few different levels here: \r\n\r\n* the abstraction / code\r\n* the streams, including data and how they fit together\r\n* the output UI\r\n\r\n##### Infinite canvas drawings\r\n\r\n![image](https://user-images.githubusercontent.com/2288939/48514496-6d9cd580-e82c-11e8-8bf4-1b4af9aef054.png)\r\n\r\n##### Other tools for inspiration\r\n\r\n* WYSIWYG hybrids such as Sketch-n-Sketch\r\n* Aprt.us, which would be a more visual language. Key question is how to do higher-order & cyclic, and other abstractions\r\n* Facebook Origami\r\n* Lamdu/Luna/Dark and all the projectional editors\r\n\r\n##### Worst parts of Reflex/Haskell\r\n\r\nBut then I thought: let's focus on the really key issue here. What's the highest-leverage improvement to be made? What's the *worst* part of using Reflex/Haskell now? In the shower note on the right below, it says:\r\n\r\n1. feedback loop: knowing if the syntax is right, if the types make sense, what the code I'm looking at *is* from both a type, data, and UI perspective\r\n2. knowing what's possible (syntax, API, types)\r\n\r\n##### p4 prioritized features\r\n\r\n1. With this framing, a quick compile time (or intepreter time) could be key. Reflex seems to take 4+ seconds. Can I do sub 1? Or faster? How about hot reloading?\r\n2. Great docs, autocomplete, type annotations everywhere\r\n3. Automatic plumbing:  can we semi-automatically lift transforms inside monadic contexts? Ditto for automatic type coersion plumbing like int to string, etc\r\n4. Stream visualization, including how streams make other streams, the shape of streams, and also the data for each stream\r\n5. (Bi-directional) Direct manipulation of UI\r\n\r\n![image](https://user-images.githubusercontent.com/2288939/48357110-d0904000-e665-11e8-9154-3768ad3ce414.png)\r\n\r\n##### Implementation\r\n\r\nJE send me an email: \r\n\r\n> Can you implement your FRP eXperience using FRP, and apply it to itself? That might be challenging, but would also be very impressive. It will be seen as a limitation if it can't apply to itself, although that might be unavoidable in the first phase. But I think that at the very least you need to implement it in some FRP framework to avoid the charge of hypocrisy.\r\n\r\nMy response: The only implementation of the FRP I argue for in my paper is Reflex/ghcjs. It doesn't exist in PureScript, Elm, F#, etc. Turns out laziness makes it a lot easier to implement. My next experiment is to try to do it in JS with CycleJS. I've tried this in the past. It's not easy -- it's not built for this use case -- but it seems possible, even cycles. More to follow...\r\n\r\n* I did a very naive implementation of streams stuff in JS here: https://codesandbox.io/s/81225lrop2\r\n* It'd probably be better to build off cyclejs. Over a year ago I tried to do something similar so maybe I can start there? https://codesandbox.io/s/xlrynkqoqp Inspecting the types of streams is key. Maybe I can use the cyclejs devtools and/or augment them somehow. Could typescript or something similar help me encode the types of streams of streams of streams? Could monaco help with autocomplete suggestions?\r\n\r\nSome other ideas for building this:\r\n\r\n* racket turnstule dsl for building typed langauges\r\n* L. Kats and E. Visser. The spoofax language workbench. \r\n* C. Omar. Reasonably Programmable Syntax. PhD thesis, Carnegie Mellon University, 2017.\r\n* Build a JS interpreter with laziness based on Stephen Diehl's work (discussed below as well)"}}
{"actor":{"display_login":"stevekrouse"}}