fix single l conal elliott typo

Author: Steve Krouse

404.md

@@ -39,7 +39,8 @@ const moved = {
   '/essays/power': '/drafts/power',
   '/essays/regex-for-humans': '/drafts/regex-for-humans',
   '/essays/visual': '/drafts/visual',
-  '/drafts/frp': '/papers/comprehensible-frp'
+  '/drafts/frp': '/papers/comprehensible-frp',
+  '/notes/conal-elliot': '/notes/conal-elliott'
 }
 
 const movedKey = Object.keys(moved).find(url => window.location.pathname.includes(url))

about.md

@@ -53,7 +53,7 @@ My (current) angle on this problem is most influenced by:
 
 * Jonathan Edwards
 * Out of the Tarpit
-* Conal Elliot
+* Conal Elliott
 * Bret Victor
 * Paul Chiusano
 

drafts/casual.md

@@ -111,11 +111,11 @@ Just kidding. It's 2018. Who's writing a terminal apps? Luckily creating web app
 
 ## Functional Reactive Programming
 
-Funnily enough, the popular way to create web apps in 2018 is based on the work of early Haskellers Conal Elliot and Paul Hudak. They came up with a way of declaratively describing interactive animations *with only pure functions, no monads required*. ReactJS, VueJS, CycleJS, etc are based on this "reactive" paradigm, where you declaratively describe what's on the page, as opposed to imperitively adding and removing characters to the screen one-by-one. Of course, there's code somewhere in your computer that's adding and removing characters from the screen, but we don't have to worry about that - it's below our level of abstraction. 
+Funnily enough, the popular way to create web apps in 2018 is based on the work of early Haskellers Conal Elliott and Paul Hudak. They came up with a way of declaratively describing interactive animations *with only pure functions, no monads required*. ReactJS, VueJS, CycleJS, etc are based on this "reactive" paradigm, where you declaratively describe what's on the page, as opposed to imperitively adding and removing characters to the screen one-by-one. Of course, there's code somewhere in your computer that's adding and removing characters from the screen, but we don't have to worry about that - it's below our level of abstraction. 
 
 TODO how does FRP accomplish this?
 
-This doesn't just apply to user interfaces. Conal Elliot argues in [Can functional programming be liberated from the von Neumann paradigm?](http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm) that we can perform that same trick for any IO-based software interface. 
+This doesn't just apply to user interfaces. Conal Elliott argues in [Can functional programming be liberated from the von Neumann paradigm?](http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm) that we can perform that same trick for any IO-based software interface. 
 
 
 ## Are we there yet?

episodes/33.md

@@ -29,7 +29,7 @@ In order to accomplish this vision, I believe there are three large categories o
 2. Create a better **programming experience** for the complex abstractions we create to avoid IO.
 3. Reimagine **version control** for a world where software looks very different than it does today, with many, many more forks, at many more levels than just one-deep off of master.
 
-My recent work was on ridding ourselves of the IO Monad from user interfaces, which is building on Conal Elliot's FRP work. [My paper and talk](http://futureofcoding.org/papers/comprehensible-frp) at REBLS last month argues that Elm Architecture makes software take longer to understand (which is untenable if we want people to be able to modify the software they use *in the course of using it*) as compared to the higher-order and cyclic streams of Conal's original FRP.
+My recent work was on ridding ourselves of the IO Monad from user interfaces, which is building on Conal Elliott's FRP work. [My paper and talk](http://futureofcoding.org/papers/comprehensible-frp) at REBLS last month argues that Elm Architecture makes software take longer to understand (which is untenable if we want people to be able to modify the software they use *in the course of using it*) as compared to the higher-order and cyclic streams of Conal's original FRP.
 
 My future work will be improving the programming experience of "original FRP", potentially with a Haskell-inspired structured editor. I will also extend Conal's FRP work to also [removing the IO Monad from the "backend"](https://github.com/stevekrouse/futureofcoding.org/issues/85).
 
@@ -142,7 +142,7 @@ _Transcript sponsored by [repl.it](https://repl.it/)_
 	<h4>Thesis</h4>
 	<div class="block">
 		<div class="time">00:14:29</div>
-		Alright. So, now my thesis. My current angle on this whole mission is most influenced by Jonathan Edwards, Out of the Tarpit, Conal Elliot, Bret Victor, and Paul Chiusano. There are many, many, many hundreds of others who have influenced my thinking here, but I don't want to list them all. Those are the people that really come top of mind when I think about where my thoughts come from, particularly not only on the inspiration for the mission itself, but for how to achieve it.
+		Alright. So, now my thesis. My current angle on this whole mission is most influenced by Jonathan Edwards, Out of the Tarpit, Conal Elliott, Bret Victor, and Paul Chiusano. There are many, many, many hundreds of others who have influenced my thinking here, but I don't want to list them all. Those are the people that really come top of mind when I think about where my thoughts come from, particularly not only on the inspiration for the mission itself, but for how to achieve it.
 	</div>
 	<div class="block">
 		<div class="time">00:15:05</div>
@@ -170,11 +170,11 @@ _Transcript sponsored by [repl.it](https://repl.it/)_
 	</div>
 	<div class="block">
 		<div class="time">00:19:43</div>
-		So in other words, basically what I'm getting at is we need to, point five, rid ourselves of the IO monad and replace it with better abstractions for whole systems. So, now Conal Elliot has a really, really wonderful post, Will Functional Programming Ever be Liberated From the von Neumann Architecture? In this point, he makes a really, really wonderful distinction. So, monads themselves are this very benign type class thing with laws. They're kind of mathematical and categorical. They're great, and they're not that hard to understand. The thing that's kind of hard to understand, I think, is the IO monad. And I think part of why it's hard to understand is that Haskell people aren't honest about what it is. The IO monad is imperative code embedded within Haskell. That's what it is. You get to write code with side effects within your Haskell program. And it's a reasonable compromise given the world we live in today, because you want to have the benefits of Haskell, but then you also need your code to have some side effects.
+		So in other words, basically what I'm getting at is we need to, point five, rid ourselves of the IO monad and replace it with better abstractions for whole systems. So, now Conal Elliott has a really, really wonderful post, Will Functional Programming Ever be Liberated From the von Neumann Architecture? In this point, he makes a really, really wonderful distinction. So, monads themselves are this very benign type class thing with laws. They're kind of mathematical and categorical. They're great, and they're not that hard to understand. The thing that's kind of hard to understand, I think, is the IO monad. And I think part of why it's hard to understand is that Haskell people aren't honest about what it is. The IO monad is imperative code embedded within Haskell. That's what it is. You get to write code with side effects within your Haskell program. And it's a reasonable compromise given the world we live in today, because you want to have the benefits of Haskell, but then you also need your code to have some side effects.
 	</div>
 	<div class="block">
 		<div class="time">00:20:24</div>
-		But Conal Elliot shows us how we can do better than the IO monad, and he showed how with FRP. Functional reactive programming, he argues, and I would agree, is a way to do side effect-y things. Basically, you have a user interface on the screen, that a user can interact with, and it can be dynamic, and update, and whatnot, so there are all these side effect-y things happening, your computer doing stuff, yet the interface, to the programmer, at the Haskell level, or at the FRP level, has no IO. You describe the view as a pure function of state. It's beautiful. It's a beautiful system.
+		But Conal Elliott shows us how we can do better than the IO monad, and he showed how with FRP. Functional reactive programming, he argues, and I would agree, is a way to do side effect-y things. Basically, you have a user interface on the screen, that a user can interact with, and it can be dynamic, and update, and whatnot, so there are all these side effect-y things happening, your computer doing stuff, yet the interface, to the programmer, at the Haskell level, or at the FRP level, has no IO. You describe the view as a pure function of state. It's beautiful. It's a beautiful system.
 	</div>
 	<div class="block">
 		<div class="time">00:21:03</div>
@@ -309,7 +309,7 @@ _Transcript sponsored by [repl.it](https://repl.it/)_
 	<h4> Higher order and cyclic streams</h4>
 	<div class="block">
 		<div class="time">00:46:48</div>
-		So, what's the alternative?, you ask. Thanks for asking. So I think the alternative is to go back to the original conception of FRP that Conal Elliot came up with, with Paul Hudak, in the '90s. And in order for us to do this we need higher order and cyclic streams. So the justification of why we need higher order and cyclical streams in order to escape the hell of the Elm Architecture, that's a complicated point that I haven't even fully convinced myself of but just assume it to be the case. So we need high order and cyclical streams. And those really aren't around in very many places.
+		So, what's the alternative?, you ask. Thanks for asking. So I think the alternative is to go back to the original conception of FRP that Conal Elliott came up with, with Paul Hudak, in the '90s. And in order for us to do this we need higher order and cyclic streams. So the justification of why we need higher order and cyclical streams in order to escape the hell of the Elm Architecture, that's a complicated point that I haven't even fully convinced myself of but just assume it to be the case. So we need high order and cyclical streams. And those really aren't around in very many places.
 	</div>
 	<h4>Fluid Haskell Chimera</h4>
 	<div class="block">
@@ -327,7 +327,7 @@ _Transcript sponsored by [repl.it](https://repl.it/)_
 	<h3>Turbine</h3>
 	<div class="block">
 		<div class="time">00:49:58</div>
-		Okay, so that's Explicitly Comprehensible FRP, in a way too short amount of time. So go on the Internet if you want to know more. So, as I was saying, Haskell was just a pain but luckily in the last few days I found this library called Turbine. So actually I'd seen it a couple months ago but I passed it over for some dumb reason. But luckily a few days ago I popped on Twitter to waste time and I was thwarted, my time was used very productively, because right at the top of my Twitter feed was Conal Elliot praising an essay written by the Framework creator, Simon Friis Vindum, of Turbine. And so I read it and revisited it and I was like, "Holy crap, this is exactly what I'm looking for." And so I played with it for a few hours and it was great. Really it's similar to Reflex, there's a few things I like about it less but it wins by a mile, simply for the reason that I was able to install it in two seconds. I still need help setting up typescript but I was able to install it without typescript for two seconds, or very quickly, and then on every key stroke it'll reload the page, like instantly. It's so quick to compile and run it. So, for that reason alone, it warns me about syntax errors, it warns me about silly errors. It's just so much, so much better.
+		Okay, so that's Explicitly Comprehensible FRP, in a way too short amount of time. So go on the Internet if you want to know more. So, as I was saying, Haskell was just a pain but luckily in the last few days I found this library called Turbine. So actually I'd seen it a couple months ago but I passed it over for some dumb reason. But luckily a few days ago I popped on Twitter to waste time and I was thwarted, my time was used very productively, because right at the top of my Twitter feed was Conal Elliott praising an essay written by the Framework creator, Simon Friis Vindum, of Turbine. And so I read it and revisited it and I was like, "Holy crap, this is exactly what I'm looking for." And so I played with it for a few hours and it was great. Really it's similar to Reflex, there's a few things I like about it less but it wins by a mile, simply for the reason that I was able to install it in two seconds. I still need help setting up typescript but I was able to install it without typescript for two seconds, or very quickly, and then on every key stroke it'll reload the page, like instantly. It's so quick to compile and run it. So, for that reason alone, it warns me about syntax errors, it warns me about silly errors. It's just so much, so much better.
 	</div>
 	<div class="block">
 		<div class="time">00:51:30</div>

journal.md

@@ -597,7 +597,7 @@ Andre replied already! He is busy preparing for a bunch of conferences so might
 * Jonathan Edwards
   * https://github.com/stevekrouse/futureofcoding.org/commit/52a0d72bc49f2d56eebcfcdaae440467008f1cd2
   * https://github.com/stevekrouse/futureofcoding.org/commit/cd83671ac0a4d68818c40815c9f5202ec078aafc
-* Conal Elliot
+* Conal Elliott
   * https://github.com/stevekrouse/futureofcoding.org/commit/52a0d72bc49f2d56eebcfcdaae440467008f1cd2 
 * Eve
   * http://futureofcoding.org/journal#my-first-full-day-with-eve

links.md

@@ -501,20 +501,20 @@ title: Link Research
   * haskell programming as a graph
   * I don't usually find graphs compelling. I prefer blocks/structured editor approaches which leave the text closer to prose sentences for better reading. I'm not a computer so I don't like reading trees.
 
-* [Conal Elliot - Tangible Functional Programming](https://www.youtube.com/watch?v=faJ8N0giqzw)
+* [Conal Elliott - Tangible Functional Programming](https://www.youtube.com/watch?v=faJ8N0giqzw)
   * the dream: combine usability and composability (so like IFFT but at the right level of abstraction)
   * UNIX pipes with input and output text makes it easy to compose
   * I've already seen this video, I'm now realizing, he shows how to drag outputs into inputs in a GUI
 
-* [Conal Elliot - Fran - Composing Reactive Animations](http://conal.net/fran/tutorial.htm)
+* [Conal Elliott - Fran - Composing Reactive Animations](http://conal.net/fran/tutorial.htm)
   * Holy shit! This is like Reactive WoofJS (or the Elm game engine) but was made in 1998 in Haskell! He makes quick work of my "inital value problem": simply give a function all the arugments it needs, starting value, and rate of increase
   * Let me send this over to my friends at McMaster University to see if they've thought about making an Elm version...
 
 * [Conal Elliott - The Essence and Origins of Functional Reactive Programming](https://www.youtube.com/watch?v=j3Q32brCUAI)
   * seperate design spec from implementation
   * FRP is about continuous time in the same way vector graphics are about continuous space
 
-* [Conal Elliot - Denotational Design](http://conal.net/papers/type-class-morphisms/)
+* [Conal Elliott - Denotational Design](http://conal.net/papers/type-class-morphisms/)
   * "The purpose of abstraction is not to be vauge but to create a new semantic level in which one can be absolutely precise." - Dijkstra
   * Peter Landin reccomends that "denotive" to replace ill-defined "functional" and "declarative". A langauge is only "denotive" if each expression only depends on sub-expressions
   * before you think about implementation... what are the main types, main operations, what do the types mean?

notes/bret-victor/learnable-programming.md

@@ -141,7 +141,7 @@ This is also key. CycleJS devtools diagram.
 
 > The environment can represent time at multiple granularities, such as frames or event responses, to enable exploration across these meaningful chunks of execution.
 
-Again, this sounds to me like add-ons that the community could build given a really solid underlying structure. A structure that Conal Elliot would build. Perfect abstractions.
+Again, this sounds to me like add-ons that the community could build given a really solid underlying structure. A structure that Conal Elliott would build. Perfect abstractions.
 
 ### FRP Scratch
 
@@ -328,7 +328,7 @@ I can't put a finger on why, but this feels like a powerful insight. But then ag
 
 #### Sequencing and monads
 
-Despite all my FP and Haskell experience, I never felt very comforatable with monads. This is probably related to the fact that I only used Haskell in the university setting. However, potentially monads aren't needed for sequencing side-effect-y code. That's what FRP is supposed to be for, right? This section of the essay, unsurprisingly, is making me want to do my Conal Elliot FRP deep dive sooner rather than later.
+Despite all my FP and Haskell experience, I never felt very comforatable with monads. This is probably related to the fact that I only used Haskell in the university setting. However, potentially monads aren't needed for sequencing side-effect-y code. That's what FRP is supposed to be for, right? This section of the essay, unsurprisingly, is making me want to do my Conal Elliott FRP deep dive sooner rather than later.
 
 ### Readability
 

notes/conal-elliot.md renamed to notes/conal-elliott.md

@@ -1,8 +1,8 @@
 ---
-title: Conal Elliot
+title: Conal Elliott
 ---
 
-# Conal Elliot
+# Conal Elliott
 
 * TOC
 {:toc}

notes/dan-scanlon-call-9-5-17.md

@@ -67,7 +67,7 @@ title: Dan Scanlon Call 9/5/17
   * doing this research in his free time
     * restraining himself from coding it himself
     * trying to think it out in his head, hypothetically
-    * TODO Elliot Conal denotational design
+    * TODO Elliott Conal denotational design
 
 * Get his feedback on my research
   * StreamSheets

reflections/13.md

@@ -74,7 +74,7 @@ Eventually, however, I'll have to deal with other key problems, such as collabor
 
 #### Anti IO-monad & Cannonical
 
-I've had some strange thoughts here, mostly inspired by Conal Elliot. I don't have much to say about them yet, but you can read [here](http://futureofcoding.org/log#my-growing-anti-io-monad-obsession) and [here](http://futureofcoding.org/log#2-anti-io-monad).
+I've had some strange thoughts here, mostly inspired by Conal Elliott. I don't have much to say about them yet, but you can read [here](http://futureofcoding.org/log#my-growing-anti-io-monad-obsession) and [here](http://futureofcoding.org/log#2-anti-io-monad).
 
 #### Data ninja playground