stevekrouse

              if (error.url === "") {
                var emptyURLTypes = ["setBackdropURL('')", 'setBackdropURL("")', 'url: ""', "url: ''"]
                var emptyURLType = emptyURLTypes.find(t => code.includes(t))
                if (emptyURLType) {
                  app.error = {message: "You forgot to include an image or background URL.", lineno: code.substring(0, code.indexOf(emptyURLType)).split('\n').length}
                } else {
                  // We can't figure out the lineno if it's set to an empty string variable
                  // https://woofjs.com/create#image-url-issue
                  app.error = {message: "You forgot to include an image or background URL.", lineno: null}
                }

stevekrouse

stevekrouse

Required Reading

• Papert: Mindstorms and maybe Children's Machine (maybe others of his)
• Kay: Hasn't happened yet, TODO find others, maybe STEPS, early history of smalltalk
• BV: magic ink, learnable programming, all the videos, really
• Granger: modeling, some videos, etc
• mother of all demos
• as we may think

stevekrouse

title
The Misunderstood Roots of FRP Can Save Programming

• TOC {:toc}

The Misunderstood Roots of FRP Can Save Programming

For many years I been searching for the perfect paradigm for programming user interfaces. Like many others, I fell in love with FRP with the rise of ReactJS and spent a few years searching for the perfect reactive model. Eventually, I found my way back to the original work on FRP by Conal Elliott. It took me almost a year to make sense of it. This essay attempts to make Conal's vision more understandable to less mathematically-oriented programmers, and also show how this perspective could be the foundation for a new era of programming, not just with user interfaces, but also multi-node computing, storage, machine learning, etc.

stevekrouse

title
The Misunderstood Roots of FRP Can Save Programming

• TOC {:toc}

The Misunderstood Roots of FRP Can Save Programming

For many years I been searching for the perfect paradigm for programming user interfaces. Like many others, I fell in love with FRP with the rise of ReactJS and spent a few years searching for the perfect reactive model. Eventually, I found my way back to the original work on FRP by Conal Elliott. It took me almost a year to make sense of it. This essay attempts to make Conal's vision more understandable to less mathematically-oriented programmers, and also show how this perspective could be the foundation for a new era of programming, not just with user interfaces, but also multi-node computing, storage, machine learning, etc.

stevekrouse

DCTP 2

Dikstra's 1968 Goto Considered Harmful argues that we can produce better code by replacing goto with structured commands, such as functions, if-statements, and loops. In this tradition, the functional programming community has continued to demonstrate how we can produce better programs without various side-effects, sometimes with the introduction of new language features. For example, many forms of mutable state can be expressed with recursion.

Of course these effects aren't truly eliminated but merely shifted down the technological stack. The compiler for a language with recursion will likely utilize mutable state for an efficient implementation. The benefits of pure languages are also their costs: being cut off from operational details let us focus on essential complexity, but at the same time inhibit us improving the performance of our programs. Hopefully these costs will continue to decrease over time due to faster and bigger chips, and advanced compilation techniques. Modern compilers fo

stevekrouse

@stevekrouse I think it's worth thinking through the implications of only wanting to democratize high-level programs. Since we don't really have a good way to build hardware that can execute recursively nested expressions, the lowest level will always execute statements that are connected by named locations. So by saying you don't want people to have to think about statements, you're asking for the lowest levels to just be "handled" for you. That's basically just the same priesthood arrangement we're trying to get away from, and we end up with the same questions about who watches the watchers, and so on.

-Kartik Agram on the Future of Coding Slack

This is a very interesting point: if we truly want to democratize programming, it needs to be democratic and every level, all the way down to the bits. Otherwise, it's just another limited app won't support extensibility in all the ways we'd

stevekrouse

https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b https://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language/5878525 https://stackoverflow.com/questions/5385377/the-difference-between-reactive-and-functional-reactive-programming/5386908#5386908 http://conal.net/blog/posts/early-inspirations-and-new-directions-in-functional-reactive-programming https://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631 https://github.com/conal/talk-2014-bayhac-denotational-design#why-continuous-time-matters https://github.com/conal/talk-2015-essence-and-origins-of-frp

On a fateful day in late 2014, I read The Future of DOM MV* by David Nolan. It mentioned a new JavaScript library out of Facebook that everybody was making fun of. I read on. My mind was blown. ReactJS was a revalation!

stevekrouse

<html>
  <head>
  </head>
  <body>
    <h1 id="error" style="display:none; color: red">Too many characters to save. Please delete some.</h1>
    <div id="c" contenteditable style="min-height:300px;outline:none;"></div>
  </body>
  <script src="main.js"></script>
</html>

stevekrouse

module Main exposing (main)

import Html exposing (Html, button, div, text)
import Html.Events exposing (onClick)


type alias Model =
    { count : Int }