journal.md

title
Journal

Future of Coding Research Journal

July 25 2017 2:26pm

Again, I'm finally getting to research late in the day. I spent the morning reveiewing Woof pull requests and doing emails. But I'm finally here on the Ubuntu side of my chromebook, playing with Unison...

I got the factorial code to work by following the advice of the founder of Unison in the conversation I pasted below:

So I tried to accomplish https://projecteuler.net/problem=7. First I tried the dumb way by checking each prime against all numbers lower than it. Then I tried the smarter way by only checking against the primes lower than it. However in the course of constructing a helper function I must've messed something up badly because I caused a Lamdu to crash:

What I love about Lamdu:

• immediate evaluation

• evaluation of recursive function that you can scroll through

• named parameters that are auto-typed for you

• searching for terms by type

• allowing you to put a incorrectly typed term somewhere but have it highlighted as red

• quick declaration of structural types

So what I don't like about Lamdu:

• It's not obvious if you have selected a term or if it's still a "hole". I don't think they should put the top search result in a hole because it looks like it's been filled. I think holes should be reserved for no data or data of the wrong type in which case they would be red colored which is clear.

• It's impossible (or I don't know how) to move code around easily. For example, turning an expression in the body of a function into a variable in a let expression. Another thing I wanted to do was "lift" an if-expression outside of its subexpression and make it the parent expression.

  Instead of: prime' (if blah then x else y) (if blah then p else q)

  I wanted: if blah then (prime x p) else (prime y q)

  The only way to accomplish this that I knew of was to basically start the expression from scratch. Clearly, text is superiror if this is was structured editing is like. I wonder if we can overcome this issue of moving code around. My gut tells me that the more consistent/uniform the syntax of the code is, the easier it will be to move things around. However, a simple way to solve this particular problem would be to have a copy-and-paste feature. Then I could copy the whole expression, delete the parent expression from within the child expression, and then paste the entire old expression into the former-child-now-parent expression and delete the former-parent-now-child expression's child expression. Not too terrible.

• As I've said before, the syntax is too sparse. They could make the method names longer and more understandable. Also for if-expressions, there's really no syntax at all which makes it impossible to search for if-expressions via the keyboard. You have to type out a boolean expression and hit space and then select the if-expression.

• The type errors aren't very helpful. Now they just show me the expected type and the actual type. It'd be nice if they suggested a way to convert, which isn't hard for streams and arrays. Or even just explained the error in text, as in "The length function expects an Array. You have given it a Stream. Please either give the length function an Array or use a function that inputs a Stream." This might seem obvious to most Haskell programmers but it isn't to most programmers, especially beginners.

• I wish there were more "command prompts" for me to evaluate random expressions. I don't like having to delete old ones to try out new ones. I wish it were more like IPython notebook in this way.

• I wish I could declare the type of something myself as opposed to having to wait for Lamdu to infer it.

• Why don't Streams have a built-in length method? Given that there is a sum method that operates on Streams, I don't see any reason why there can't be one.

• Ultimately the biggest issue I have with Lamdu is really more an issue with Haskell-like languages (Elm, Unison) in general. They are really, really hard to parse. I find it incredibly difficult to follow what's going on. Possibly this would get better the more time I spend with these langauges but I've already spent hundreds of hours so I don't think a langauge that requires thousands of hours to get proficient at reading it is what we're going for here.

  The benefits gained from functional programming (no runtime errors, more declarative/abstract code) are invaluable. The question for me is: how to we take these benefits and make them less costly? One idea that I think about a lot is types as shapes, but I am doubtful of how well this idea scales. It requires more research. More generally, visual metaphors could be helpful here somehow, because functional/reactive programming is super easy for people in the context of spreadsheets, which is part of the idea behind aprt.us.

• Ok, to be honest, my biggest issue with Lamdu is that it's a desktop application that I have to install from source to get to play with it. I have to plan my whole day around switching to the Ubuntu side of my comptuer to play with it. Unison also has a non-web backend, partly Haskell and partly Scala I think, although inital demos were done on the front end in Elm. I think Luna-lang is also a native app, but I'm not sure of that. What langauge to build something like this in isn't a clear one for me. Watching Unison and Eve both start with Elm and then move off it has been interesting to see. I think Eve moved to vanilla JS for speed reasons, which probably will be where I end up too.

• I found the Lamdu code really hard to parse through and find anything interesting or even understandable. Haskell is tough. Maybe if I get these guys on my podcast, I'll have them walk us through their code.

July 24 2017 4:26pm

I'm recognizing that I won't have time to get to what I hoped to today as I'm still just trying to get through my inbox and other tasks. To be clear, no research happened today but I have a solid plan for what to work on tomorrow!

July 24 2017 2:04pm

Apologies for skipping an entry on Friday. I spent most of the day installing Ubuntu on my chromebook so that I could try Lamdu out. And then I spent a while installing Lamdu. Finally I got it to work! You can see the conversation I had with one of the creators of Lamdu on its Gitter channel:

Overall, it's a really fun prototype that shows a lot of promise! As you can see, even I was confused about how to use it. It's also feels pretty janky. It's not a smooth experiece at this point but I can imagine how it could be one day.

However, I do have one BIG reservation with a language like this (or Unison or Elm or Haskell): reading the syntax is difficult, even for me, and especially for a beginner. I wonder if the solution could be as simple as more verbose syntax "if this is true then X otherwise Y" or "transform each element in list X by Y" as opposed to the minimalist style they have now with almost no words. Maybe shapes would be helpful. Maybe higher level macros.

I want to spend more time working with it, getting a better sense of what it can do. The next steps are:

1. build a few toy programs in it, maybe solve some project euler problems.
2. get a sense of how its code works, in particular how the editor's type-a-head suggestions work

Other tasks I want to work on today:

1. Edit my podcast interview with Jonathan Leung I recorded on Friday.
2. Design the podcast logo.
3. Put my "thesis" for the future of coding on the website. Add topics that I find interesting, like pull request without leaving the main page, types as shapes, etc. Pull from:

• https://github.com/stevekrouse/cycle/blob/d6094179c97ec815198cf24cbab9248968a2f157/README.md#principles
• https://docs.google.com/document/d/1oSbI5z7BZVkHxf0gOabjz393HiLAys1WJeHnaVMg4dg/edit?usp=drive_web
• TODOs from futureofcoding.org/links

July 20, 2017 9:41am

Yesterday ended up being a particularly productive research session, but I didn't have time to recap it. Here's a pretty solid picture of my progress: https://github.com/stevekrouse/futureofcoding.org/commit/4670a33f503a621f606de0338df1c21d161967fe#diff-424069113a08a4256349764ee38dbbbf

The most exciting part was falling in love with Lamdu, even while I failed to get it to install or run. I have a sinking feeling that it's not going to be compatible with cloud9 so I need to talk to them about that.

TODOS:

• reach out to Lamdu people about installing, contributing and being on the podcast
• add http://2016.ecoop.org/track/LIVE-2016#program to my research links and also consider going / applying

July 18, 2017 4:00pm

I was able to get through the links -- in particular I really loved Bret's notes on dynamic diagrams and am really excited to get to his Substroke project sometime soon -- however, I am excited to get to Lamdu tomorrow, in particular getting it to run on my chromebook through some magics.

July 18, 2017 1:35pm

So I ended up creating futureofcoding.org/links yesterday (instead of /products) and it seems to be a good way to organize things, at least for now. I think it was a good idea to start by watching some Alan Kay video for framing and context. He really challenges listeners to write him with interesting emails, so I'm going to work on putting something together soon. Wouldn't that be a coup -- befriending Alan Kay and getting him on this podcast?!

I'd say one of the bigger ideas I got from Alan is that we should be problem-focused and not solution-focused, to the point of ignoring the tools we currently have entirely and building them from scratch if need be. I definitely fall into the trap of "what can I make with these tools" all the time. The solutionism trap. I feel myself caught up in a related problem a lot where I am optimizing for integrating with existing tech, which will definitly hold you back in the long term but seems neccesary for adoption in the short term...

Ok, so I have from now (2pm) to 4:30 to do some research. I hope to quickly get through the papers and talks that I have on my list and make it to Lamdu today.

July 17, 2017 12:38pm

I don't have much time for research today (only about 90 minutes), but I want to get into the habit of writing notes here every weekday even if it's just to say that I didn't do any research that day. My main task for today will be organizing the list of links to research, prioritizing them, etc.

I think I should make the different styles of research here more clear:

1. Researching other products (reading documentation, writing notes, building toy apps)
2. Building prototypes (Cycle 1, Cycle 2, Rose 1, Elm game engine)
3. Writing about various future of coding topics (Types as Shapes, Resources for creating front-end programming languages and frameworks in 2017)

Today, I'm just working on organizing (1). I currently have it in a google doc: https://docs.google.com/document/d/1TtfMqBBRGnwisCx42nuXa4Y5VF3EizpZxFQBivJWhhE/edit

I am going to create a place on this website, in this github repo, for these links. One idea is to just talk about them here in this journal but that doesn't feel very structured. Why don't I create products.md where I have a few sections:

1. Products to look into (prioritized)
2. Products reviewed
3. Places to find more products to review

July 14, 2017 5:09pm

So that was fun! I talked for almost an hour about my past research and thought-out-loud about the directions to take things in the future. I was suprised about how cogent my thougths about where to take my research were. It felt like I was alomst as logical as I can be here in text. I wanted to include the thoughts that I came to on the podcast here about what my next steps are in this research project...

1. Organize and prioritize the list of links, with Lambdu and Luna at the top. This should take a few days.
2. Research each of the links, putting what I think about them and any demos I make here in these notes. This should take no longer than a month.
3. Resume building prototypes. Directions this could take include:

• Cycle v2 from the ground up, with a custom block-interface and virtual-dom or snabdom instead of VueJS
• Reactive WoofJS or Elm game engine
• Rose v1 with text as the UI
• working with Paul on Unison (or on any of the other projects I'm researching)
• none of the above, I come up with another wacky idea that steals my attention, which after all is the point of all this research

July 14, 2017 2:58pm

I'm back! So a few things on my mind.

Firstly, organizing my thoughts on what to research next from yesterday. Another one to add to the list:

10. Thinking about how Woof, or the next step after Woof, could be the starting point for Rose. Use my students as my target user and build for them.

Secondly, I think it would be good for my audience to hear about my past research so they have context before I go off explaining my new research. Potentially reviewing past research could even be a good way for me to decide what to research next. Ok, so at first I thought this would be a recap in one episode but now I'm realizing it might span multiple episodes. Here are the topics to discuss:

• Scratch, how it's amazing (types as shapes, cloud based, no syntax errors, no documentation, no runtime errors, good abstractions like forever's running once per render loop, audio and image editors, social network, allow kids to make what they want)

• I was inspired to build blocks for JQuery, Cycle version 1. No HTML, No CSS. You would do everything imperitively. It would compile to JS directly. Stopped working on it when I found Code.org App Lap.

• Took a break to work on the business and Woof which I'll discuss later.

• Came back to build blocks for VueJS, which is very similar to ReactJS. Much more declarative.

  • build TodoMVC
  • built a chat app, weather app
  • fun to work with, faster and easier than coding
  • terrible error messages
  • brittle
  • used with students, went to hackathons
    • harder to learn than I thought it would be (the abstractions could be clearer, but hard to do that within blockly)
    • error messages were a killer
    • the fact that you could import into it or export from it was bad considering it couldn't be self contained

• Rebranded as Rose

  • worked on Prune, projectional editing in JS because importable and exportable
    • providing users will all possible semantic edits is tricky
    • js is a shitty language so even if we solve all syntax errors, the abstractions are tough and there are runtime errors
  • if I were to go back to prune, I would leave the text as the UI (not Vue) and just focus on a subset of JS (so no import)

• Research into other products

  • Elm. Really tricky to use but amazing once you get it running.
  • Cycle. Similar to Elm. Streams are nifty.
  • Eve. Clearly I should spend more time with it but still doesn't make sense to me.
  • Unison. Very exciting. Seems like it's almost exactly what I want in so many ways. Hope to get my friend Paul on here soon.
  • Luna Lang / Lambdu - need to spend more time with these
  • List of others... needs organizing and time

• Woof

  • next step after Scratch
  • one-to-one mapping of blocks, so leverage understanding of Scratch to learn text-based coding in JS
  • enable game development
  • full integreated IDE
  • open source and free, so hit me up on github if you'd like to contribute

• directions for going in next (below)

Ok, so that is a lot of content. Obviously. Especially if I want to drill into each of these topics. Let's estimate how much time each topics will take.

• Scratch is amazing (10 min)
• Blocks for JQuery (10 min)
• Blocks for VueJS (20 min)
• Rose / Prune (20 min)
• Other ressearch (20 min)
• The story of Woof (15 min)
• Next steps (20 min)

Ok, so it sounds like I really could do it in a long solo podcast. It would be an interesting experience. I may end up wanting more control than the tryca.st editor gives me so I can pause it, do a do-over, etc. Let's try it all as one take and see how it goes... I wonder if talking about my next steps will be cogent at all or if I'm going to prefer to write about it first and then talk about it.

July 13, 2017 2:13pm

Welcome to the first entry of the Future of Coding Research Journal!

The tone of this journal will be stream-of-consciousness. First and foremost, it is for me to work through my own thoughts. If it can be helpful to people on the interwebs, even better!

To recap the state of affairs, I've been working on building "next generation" programming languages on-and-off for about a year now. You can read more about my past research and prototypes here:

• 2017 May 09 - The Rose Project (April 2017)
• 2017 Mar 25 - The Rose Project (March 2017)

Today I'm simply creating this journal and seeding it with some basic content. Here's what I want to think about next time I'm here (either tomorrow or Monday): what to work on next.

Here are some ideas, in no particular order, but numbered so I can refer to them via their number:

1. Build an Elm game engine
2. Build a reactive version of WoofJS
3. Finish building my Elm Spelling Bee App
4. Reach out to Luna Lang to get access
5. Spend more time with Lambdu
6. Organize links of other resources in this space
7. Re read rose blogs
8. Prune with text as ui

Clearly, I should start with (8) because it will help me come up with other things to work on. Until next time!

<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>