|
| 1 | +--- |
| 2 | +title: Jonathan Edwards 6/14/18 11am ET |
| 3 | +--- |
| 4 | + |
| 5 | +# Jonathan Edwards 6/14/18 11am ET |
| 6 | + |
| 7 | +- Never heard of PPIG. What conferences do you go to? |
| 8 | + - <programming> |
| 9 | + - Strangeloop |
| 10 | + - Splash LIVE |
| 11 | + - Talk vs attending |
| 12 | + - What value do you get? |
| 13 | + - Do you schedule meetings? |
| 14 | + |
| 15 | +- Methodology problem (or is it a collaboration problem?) |
| 16 | + - Coolness isn’t right criteria |
| 17 | + - What about success of a project or methodology? |
| 18 | + - Is the goal “getting ideas out there” (BV or Alan Kay) or transferring these ideas into a project (Haskell or Google)? |
| 19 | + |
| 20 | +- My current research direction |
| 21 | + - Ultimate goal: truly open source software, where people can fork/customize their applications in real time. A world where 10% (instead of 0.01%) of users can edit their tools, would be a world with lots of amazing, free tools. |
| 22 | + - Sub-goal: people be able to navigate and understand the relevant section of the project they are trying to modify, and make the modification |
| 23 | + - Any 10x or 100x programmer has trouble with this. |
| 24 | + - Files and folders. Ugh. What runs when? |
| 25 | + - Imperative programming: need to read every line |
| 26 | + |
| 27 | + - Solution: |
| 28 | + - Remove all mutation from afar (explicit dependencies) |
| 29 | + - Remove control flow |
| 30 | + - Either FRP or synchronous languages |
| 31 | + - Then we’ll have a declarative specification that we can build visual metaphor abstractions on top of |
| 32 | + |
| 33 | + - Other things we’ll need that I’m not thinking about |
| 34 | + - A version control system that could handle many, many divergent forks |
| 35 | + - A way to share data between applications - a more semantic format, maybe |
| 36 | + - The visual metaphor layer |
| 37 | + - The “editing” layer that lives in each application |
| 38 | + - The hosting and permissioning, and accounts for each application |
| 39 | + |
| 40 | + - Current challenges |
| 41 | + - Explaining to my friends and family what I do - which isn’t hard when things are going well |
| 42 | + - Making enough money, so I can live, but also have enough time for this |
| 43 | + - Picking which problems to work on, and how they fit into a larger solution/vision |
| 44 | + - Collaboration with others |
| 45 | + - You’ve worked at MIT and YC research |
| 46 | + - Haskell is such an interesting success story of collaboration around laziness |
| 47 | + |
| 48 | + - Reading papers vs coming up with my own ideas |
| 49 | + - Presenting work vs working on new ideas |
| 50 | + - Conferences? |
| 51 | + |
| 52 | +- Notes |
| 53 | + - Don’t read wadler |
| 54 | + - [https://arxiv.org/abs/1803.10195](https://arxiv.org/abs/1803.10195) |
| 55 | + - Notes on my direction |
| 56 | + - Who hits wants |
| 57 | + - It would be nice to point to a piece of code: |
| 58 | + - what parts of the state does it depend on and what does it modify |
| 59 | + |
| 60 | + - Subsetting the project enough so I can make some progress on it |
| 61 | + - Pick a language to work within |
| 62 | + |
| 63 | + - A issue we’re torn on: |
| 64 | + - Nulls are formally messy but informally flexible and natural in some sense |
| 65 | + - Andrew Myers from CMU HCI thinks nulls are natural |
| 66 | + |
| 67 | + - Generally strategy: |
| 68 | + - Yes tree-structured state |
| 69 | + - We structure our UIs and code as trees already |
| 70 | + - It’s easy to map dbs as trees (and no sql already is) |
| 71 | + - We can unify all our data into one structure |
| 72 | + - Tree data model programming language [https://en.wikipedia.org/wiki/ParaSail_(programming_language)](https://en.wikipedia.org/wiki/ParaSail_(programming_language)) |
| 73 | + |
| 74 | + - No arbitrary graphs which can go any which way are too complicated: problems of pointers and heaps |
| 75 | + |
| 76 | + |
| 77 | +## Direct programming Notes |
| 78 | + |
| 79 | +- Presentational |
| 80 | + - I wouldn’t start by opening the base field. A better time may be when you should how you can drill down to any definition. |
| 81 | + - Don’t need to explain the cursor location, action and optionally an argument |
| 82 | + - The guiding principle: start with that, before explaining how the document works? |
| 83 | + - Start with the goal of minimizing learning curve of beginner, then talk about how indirection is hard for them |
| 84 | + |
| 85 | + - Sorry for getting the event invite in your video! |
| 86 | + - How to evaluate the work |
| 87 | + - See if it solves the indirection problem by teaching it to some students...? |
| 88 | + |
| 89 | +- Meat |
| 90 | + - I wouldn’t call it “Past State: date”. Maybe just the date. I prefer the word “version” to “state” for end user programmers. |
| 91 | + - I’d highlight the history and state with different colors. One should be a “selection color” and the other should be a “change was made here color” |
| 92 | + - I think the no-op default is exactly what you don’t want. You want it to change anything, so I’d default them all to 2. |
| 93 | + - I don’t like the right-click multiply. I think I’d much, much prefer having to type 3 * 5 in the a-number field, and then on enter or leaving the field, having it evaluate and then add the multiplication to the history. |
| 94 | + - Why don’t you have to select both the x and + to get both lines to be a formula? Does it automatically do everything after this line? |
| 95 | + - Why doesn’t it create a formula that takes an argument, and then supplies the argument? |
| 96 | + - I don’t normally think of math as a set of steps... |
| 97 | + - If you set a state to itself, maybe that should be recorded in the history? |
| 98 | + - The semantics of if’s are weird |
| 99 | + - The template element in lists is a bit strange |
| 100 | + |
| 101 | +- Compliments |
| 102 | + - Being able to abstract over history to make a procedure is clever |
| 103 | + - I really love how you can see every operation in a list loop, and how you can edit any iteration and it edits them all |
| 104 | + - Very, very cool how you turned bug into code and also unit test |
| 105 | + - The history is a script - I like this wordplay a lot |
| 106 | + |
| 107 | +<script> |
| 108 | + |
| 109 | +(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ |
| 110 | +(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), |
| 111 | +m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) |
| 112 | +})(window,document,'script','https://www.google-analytics.com/analytics.js','ga'); |
| 113 | + |
| 114 | +ga('create', 'UA-103157758-1', 'auto'); |
| 115 | +ga('send', 'pageview'); |
| 116 | + |
| 117 | +</script> |
| 118 | +<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script> |
0 commit comments