added reflection 13, podcasts 28 and 29

episodes/28.md

@@ -0,0 +1,44 @@
+---
+title: 28 - Exploring Dynamicland - Omar Rizwan
+---
+
+# 28 - Exploring Dynamicland: Omar Rizwan
+
+_08/27/18_
+
+Many of you have heard about Dynamicland, Bret Victor's new project. Omar Rizwan comes on the podcast this week to tell us all about it. He recently wrote an amazing write up about it, [Notes from Dynamicland: Geokit](https://rsnous.com/posts/notes-from-dynamicland-geokit/), that I'd highly reccomend to everyone interested in the future of computing. 
+
+<iframe src="https://omny.fm/shows/future-of-coding/28-exploring-dynamicland-omar-rizwan/embed?style=artwork" width="100%" height="180" frameborder="0"></iframe>
+
+## Links
+
+* [Omar's website](https://rsnous.com/)
+* [Omar's twitter](https://twitter.com/rsnous) (very funny!)
+* Omar's email: omar.rizwan@gmail.com
+* [Notes from Dynamicland: Geokit](https://rsnous.com/posts/notes-from-dynamicland-geokit/)
+* [Learnable Programming](http://worrydream.com/LearnableProgramming/)
+* [Inventing on Principle](https://vimeo.com/36579366)
+* [Thiel Fellowship](https://thielfellowship.org/)
+* [Nicky Case](https://ncase.me/)
+* [Explorable Explainations](https://explorabl.es/)
+* [Michael Nelson](http://michaelnielsen.org/)
+* [Amit Patel](https://twitter.com/redblobgames) of [Red Blob Games](https://www.redblobgames.com/)
+* [Alan Kay STEPS](http://www.vpri.org/pdf/tr2012001_steps.pdf)
+* [Lua](https://www.lua.org/)
+* [Xerox PARC](https://en.wikipedia.org/wiki/PARC_(company))
+* [Essay Omar mentions on Interpreted vs Compiled langauges](http://fexpr.blogspot.com/2016/08/interpreted-programming-languages.html)
+* [Poker chip numbers at Dynamicland](http://futureofcoding.org/notes/bret-victor/dynamicland#videos)
+* [Scott](https://en.wikipedia.org/wiki/Dana_Scott) and [Strachey](https://en.wikipedia.org/wiki/Christopher_Strachey)
+* [Jonathan Edwards](http://alarmingdevelopment.org)
+
+
+
+<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>
+<script>
+(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
+ga('create', 'UA-103157758-1', 'auto');
+ga('send', 'pageview');
+</script>

episodes/29.md

@@ -0,0 +1,23 @@
+---
+title: 29 - Reflection Thirteen - Independent Mentorship
+---
+
+# 29 - Reflection Thirteen: Independent Mentorship
+
+_08/27/18_
+
+My research recap episodes are back! This is the first I've recorded since the end of 2017. I discuss my new mentor-mentee relationship with Jonathan Edwards, my upcoming new paper on functional reactive programming, my move to London, my goals, and other various musings.
+
+<iframe src="https://omny.fm/shows/future-of-coding/29-reflection-thirteen-independent-mentorship/embed?style=artwork" width="100%" height="180" frameborder="0"></iframe>
+
+Very thorough [notes for this episode can be found here](../reflections/13).
+
+<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>
+<script>
+(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
+ga('create', 'UA-103157758-1', 'auto');
+ga('send', 'pageview');
+</script>

index.html

@@ -127,6 +127,8 @@ <h4>Papers</h4>
     <div id="episodes">
       <h4>Episodes</h4>
       <ul class="list-unstyled">
+        <li><span class="date">2018 Aug 27 - </span><a href="./episodes/29">#29 - Reflection 13: Independent Mentorship</a></li>
+        <li><span class="date">2018 Aug 27 - </span><a href="./episodes/28">#28 - Exploring Dynamicland: Omar Rizwan</a></li>
         <li><span class="date">2018 Jul 17 - </span><a href="./episodes/27">#27 - Bringing Explicit Modeling To The Web: David K Piano</a></li>
         <li><span class="date">2018 Jul 03 - </span><a href="./episodes/26">#26 - Compassion & Programming: Glen Chiacchieri</a></li>
         <li><span class="date">2018 Jun 12 - </span><a href="./episodes/25">#25 - You Should Think About Some States: Kevin Lynagh</a></li>

notes/aaron-kent-call-9-15-17.md

@@ -1,3 +1,7 @@
+---
+title: Aaron Kent Call 9/15/17
+---
+
 # Aaron Kent Call 9/15/17
 
 * Scala people

notes/jonathan-edwards/06-14-18.md

@@ -0,0 +1,118 @@
+---
+title: Jonathan Edwards 6/14/18 11am ET
+---
+
+# Jonathan Edwards 6/14/18 11am ET
+
+- Never heard of PPIG. What conferences do you go to? 
+    - <programming> 
+    - Strangeloop 
+    - Splash LIVE 
+    - Talk vs attending 
+    - What value do you get? 
+    - Do you schedule meetings? 
+
+- Methodology problem (or is it a collaboration problem?) 
+    - Coolness isn’t right criteria 
+    - What about success of a project or methodology? 
+    - Is the goal “getting ideas out there” (BV or Alan Kay) or transferring these ideas into a project (Haskell or Google)? 
+
+- My current research direction 
+    - 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. 
+        - Sub-goal: people be able to navigate and understand the relevant section of the project they are trying to modify, and make the modification 
+            - Any 10x or 100x programmer has trouble with this.  
+                - Files and folders. Ugh. What runs when? 
+                - Imperative programming: need to read every line 
+
+            - Solution:  
+                - Remove all mutation from afar (explicit dependencies) 
+                - Remove control flow 
+                - Either FRP or synchronous languages 
+                    - Then we’ll have a declarative specification that we can build visual metaphor abstractions on top of 
+
+        - Other things we’ll need that I’m not thinking about 
+            - A version control system that could handle many, many divergent forks 
+            - A way to share data between applications - a more semantic format, maybe 
+            - The visual metaphor layer 
+            - The “editing” layer that lives in each application 
+            - The hosting and permissioning, and accounts for each application 
+
+    - Current challenges 
+        - Explaining to my friends and family what I do - which isn’t hard when things are going well 
+        - Making enough money, so I can live, but also have enough time for this 
+        - Picking which problems to work on, and how they fit into a larger solution/vision 
+        - Collaboration with others 
+            - You’ve worked at MIT and YC research 
+            - Haskell is such an interesting success story of collaboration around laziness 
+
+        - Reading papers vs coming up with my own ideas 
+        - Presenting work vs working on new ideas 
+        - Conferences? 
+
+- Notes 
+    - Don’t read wadler 
+    - [https://arxiv.org/abs/1803.10195](https://arxiv.org/abs/1803.10195) 
+    - Notes on my direction 
+        - Who hits wants 
+        - It would be nice to point to a piece of code:  
+            - what parts of the state does it depend on and what does it modify 
+
+        - Subsetting the project enough so I can make some progress on it 
+            - Pick a language to work within 
+
+        - A issue we’re torn on:  
+            - Nulls are formally messy but informally flexible and natural in some sense 
+            - Andrew Myers from CMU HCI thinks nulls are natural 
+
+        - Generally strategy: 
+            - Yes tree-structured state 
+                - We structure our UIs and code as trees already 
+                - It’s easy to map dbs as trees (and no sql already is) 
+                - We can unify all our data into one structure 
+                - Tree data model programming language [https://en.wikipedia.org/wiki/ParaSail_(programming_language)](https://en.wikipedia.org/wiki/ParaSail_(programming_language)) 
+
+            - No arbitrary graphs which can go any which way are too complicated: problems of pointers and heaps 
+
+
+## Direct programming Notes
+
+- Presentational 
+    - 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. 
+    - Don’t need to explain the cursor location, action and optionally an argument 
+    - The guiding principle: start with that, before explaining how the document works? 
+        - Start with the goal of minimizing learning curve of beginner, then talk about how indirection is hard for them 
+
+    - Sorry for getting the event invite in your video! 
+    - How to evaluate the work 
+        - See if it solves the indirection problem by teaching it to some students...? 
+
+- Meat 
+    - I wouldn’t call it “Past State: date”. Maybe just the date. I prefer the word “version” to “state” for end user programmers. 
+    - 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” 
+    - 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. 
+    - 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. 
+    - 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? 
+    - Why doesn’t it create a formula that takes an argument, and then supplies the argument? 
+    - I don’t normally think of math as a set of steps... 
+    - If you set a state to itself, maybe that should be recorded in the history? 
+    - The semantics of if’s are weird 
+    - The template element in lists is a bit strange 
+
+- Compliments 
+    - Being able to abstract over history to make a procedure is clever 
+    - 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 
+    - Very, very cool how you turned bug into code and also unit test 
+    - The history is a script - I like this wordplay a lot
+
+<script>
+
+(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
+
+ga('create', 'UA-103157758-1', 'auto');
+ga('send', 'pageview');
+
+</script>
+<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>

notes/jonathan-edwards/07-10-18.md

@@ -0,0 +1,140 @@
+---
+title: Jonathan Edwards 07/10/18
+---
+
+# Jonathan Edwards 07/10/18
+
+- I was able to “solve” the problem in Reflex. 
+    - [http://futureofcoding.org/log#dom-recursion-problem-solved-by-reflex](http://futureofcoding.org/log#dom-recursion-problem-solved-by-reflex) 
+    - Hard, types and shit, emacs... worked on emacs setup stuff today 
+
+- They also have ToDoMVC 
+    - I mostly understand it 
+    - And the code looks like what I was looking for 
+
+- I’m going towards a language (elm) or framework (cycle) or devtool (rxfiddle) 
+    - My vague sense is that I need to understand Reflex and then build something with its abstractions 
+
+- I also have this sense that stream combinator visuatializations, like rxfiddle, are key to making FRP understandable 
+    - One way to say this: declarative language + GUI on top (HTML, SQL) 
+        - Note: PX (shawn mcdirmid), model and UI 
+
+    - Map is straight forward arrows -> 
+    - Should I go down the list and try to do this for them all? 
+
+- Don’t want to fight a battle on two fronts, though 
+- Also want to think about presenting something at SPLASH 
+
+
+
+- [https://vlhcc18.github.io/](https://vlhcc18.github.io/) 
+    - User studies, very academic 
+
+- Go to SPLASH, LIVE (pre) and ONWARD (during) 
+    - Less and less practitioners, more researchers 
+
+- Strangeloop is more industry. Cool, neat ideas. More industry. Less research 
+    - ICFP is co-located there. 
+        - Racket people 
+
+    - Stopped going 
+
+- One way to get oriented is to write up a survey with all the different FRP implementations 
+    - Reflex 
+    - Elm 
+    - Maybe show another one if it’s helpful 
+    - Even just one example is enough: just show a problem 
+        - Motivating Example 
+
+    - Maybe ToDoMVC 
+
+- Essay 
+    - Elm  
+        - Motivating example 
+
+    - Reflex  
+        - Solved 
+
+    - Hard to use 
+        - How to improve with viz? 
+
+    - Link on social media, put on website 
+
+- After 
+    - For specific example 
+        - What would it look like - mock it up 
+        - Storyboard 
+        - Don’t worry about general case 
+
+    - Publish this 
+    - Bret Victor demo is just build UI for that one example and make video 
+        - But what you really want is why it’s hard to generalize 
+
+- And then 
+    - Generalize it... 
+    - Build a thing... 
+
+- Apply to REBLs 
+    - Aug 17 to apply 
+    - Concatenate Essay and After 
+    - Progression: 
+        - Problem 
+        - Good semantics 
+        - Difficult to edit 
+        - How to fix UI? 
+        - Here are the technical challenges to building this for real 
+
+- If I don’t make it 
+    - PX workshop at <Programming> 
+    - [https://2018.programming-conference.org/](https://2018.programming-conference.org/) 
+
+- Co-design - two fronts 
+- So hard to go down a bad path 
+    - But if you get far enough to show results, you get a seat at the table, people know your name 
+
+
+
+LIVE and text is hard because sometime the text doesn’t make sense
+
+That’s why structure editing is great for LIVE
+
+
+
+His work 
+
+- Great quote from urbit 
+    - “Current systems are built on principle on half of your brain can be erased.” - at any point you can start from database state and reload into memory. 
+
+- Only really structured editor is Scratch 
+    - Simple and laborious 
+    - Doesn’t do any refactoring 
+
+- Tried a bunch of approaches 
+    - Photoshop one of windows - control panel approach 
+    - Meta model approach in Chorus 
+
+- Greenfoot also seems to work, they teach people with it 
+- Blockly from EToys and Blockly 
+    - I want to do things that aren’t just changing the AST 
+        - Such as change the type of something 
+
+- I need a fancier data model than an AST 
+    - I have a data model 
+    - I have actual data 
+
+
+
+Hard to do more than 4-5 hours per day of peak creative work and fill in with other things
+
+<script>
+
+(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
+
+ga('create', 'UA-103157758-1', 'auto');
+ga('send', 'pageview');
+
+</script>
+<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>