<meta charset="utf-8">
<link rel="stylesheet" href="css/csshake.min.css">
<link rel="stylesheet" href="css/animate.css">
+ <link rel="stylesheet" href="css/style.css">
<link href="https://fonts.googleapis.com/css?family=Press+Start+2P&display=swap" rel="stylesheet">
<link rel="stylesheet"
href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.18.1/styles/atom-one-dark.min.css">
<script>hljs.initHighlightingOnLoad();</script>
<script src="js/confetti.min.js"></script>
<title>Wide-Eyed Crazy Functional Programming</title>
- <style>
- body {
- margin: 0px;
- font-family: 'Press Start 2P', cursive;
- color: white;
- text-shadow:
- 1px 1px 0 #000;
- background-color: #f98012;
- background-image: url("img/tile.png");
- background-repeat: repeat;
- background-size: 10%;
- image-rendering: crisp-edges;
- background-blend-mode: multiply;
- font-size: 22px;
- }
-
- .angereyWrap {
- position: absolute;
- color: #cc0000;
- }
-
- .angerey {
- letter-spacing: -20px;
- transform: rotate(90deg) scale(1, 1.5);
- }
-
- .thonkingWrap {
- position: absolute;
- }
-
- .hljs {
- font-family: 'Press Start 2P', cursive;
- text-shadow: 2px 2px 0 #000;
- font-size: 30px;
- overflow: hidden;
- }
-
- h1, h2 {
- text-shadow: 2px 2px 0 #000;
- }
-
- .slide-title {
- font-size: 40px;
- margin: 20px;
- text-shadow: 10px 10px 0 #00000069;
- text-align: center;
- }
-
- .slide {
- margin: 40px;
- box-shadow: 10px 10px 0 #00000069;
- padding: 20px;
- height: 80%;
- background: #6187a8e3;
- }
-
- .flexotron {
- display: flex;
- justify-content: center;
- align-items: center;
- flex-wrap: wrap;
- }
-
- #cloudguy, #cloudguy2 {
- height: 100%;
- display: flex;
- justify-content: center;
- align-items: center;
- flex-wrap: wrap;
- }
-
- .cloudguypower {
- height: 24%;
- }
-
- #cloudguys {
- height: 30%;
- width: 100%;
- display: flex;
- justify-content: space-around;
- text-align:center
-
- }
-
- #cloudguys img {
- height: 100%;
- }
-
- #cloudguys div {
- width: 20%;
- max-width: 20%;
- }
-
- #cloudguys span {
- display: block;
- opacity: 0;
- }
-
- #cgquotes, #cloudguy2 > div > div {
- font-size: 30px;
- text-shadow: 2px 2px 0 #000;
- }
-
- .idk div {
- display: flex;
- width: 40%;
- }
-
- li {
- list-style: square;
- }
-
- img {
- image-rendering: optimizeSpeed; /* STOP SMOOTHING, GIVE ME SPEED */
- image-rendering: -moz-crisp-edges; /* Firefox */
- image-rendering: -o-crisp-edges; /* Opera */
- image-rendering: -webkit-optimize-contrast; /* Chrome (and eventually Safari) */
- image-rendering: pixelated; /* Chrome */
- image-rendering: optimize-contrast; /* CSS3 Proposed */
- -ms-interpolation-mode: nearest-neighbor; /* IE8+ */
- }
-
- .fig {
- text-align: center;
- }
-
- #rant .shake-constant, .crazy, .span {
- display: inline-block;
- }
-
- #rant .shake-opacity {
- color: #f98012;
- }
-
- #rant {
- padding: 20px;
- height: 80%;
- font-size: 14px;
- }
-
- .textbox {
- text-align: center;
- box-shadow: 10px 10px 0 #00000069;
- border: 2px solid black;
- background-color: #3f6382;
- padding: 5px;
- }
-
- .hljs {
- box-shadow: 10px 10px 0 #00000069;
- border: 2px solid black;
- }
-
- div[id^="slide-"] {
- display: none;
- }
-
- span[class^="code-friends"].on, span[class^="code-friends"].on > span, span[class^="code-friends"].on > span > span {
- color: #f98012 !important;
- }
-
- span[class^="promise"].on, span[class^="promise"].on > span, span[class^="promise"].on > span > span, span[class^="promise"].on > span > span > span {
- color: #f98012 !important;
- }
-
- .highlight {
- color: #f98012;
- }
-
- li {
- margin-top: 10px;
- }
-
- .notes {
- display: none;
- }
-
- </style>
</head>
<body>
<div id="slide-0">
<div id="cgquotes" style="width: 80%; margin: auto;">Welcome to the talk!</div>
</div>
</div>
- <div class="notes" >
- <ul>
- <li>Thanks for the opporunity to talk about programming with you all</li>
- </ul>
- </div>
+ <div id="commentary"><a href="notes.html" target="_blank"><img src="img/commentary.png" /><br />Click me!</a></div>
</div>
<div id="slide-1">
<div class="slide-title">=<< Welcome to the Talk Called >>=</div>
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;">Wide-Eyed Crazy Functional Programming</div>
<img class="cloudguypower" style="margin-right: 70px; transform: scaleX(-1);" src="img/cloudguy-power.gif" />
</div>
+ <div class="notes">
+ Woo! Look at them go! If you throw on <a href="https://www.youtube.com/watch?v=vqz8c4ZP3Wg" target="_blank">this</a> then it's like a 2 hour dance party!
+ </div>
</div>
<div id="slide-2">
- <div class="slide-title">=<< What's up with that Title? >>=</div>
- <div class="slide">
- </div>
- <div class="notes">
- <ul>
- <li>A few people asked me about the title, so I thought I'd clear up what it means</li>
- </ul>
+ <div class="slide-title">=<< Just Wait a Sec... >>=</div>
+ <div class="slide flexotron" style="flex-wrap: nowrap;">
+ <div class="textbox flexotron" id="notes" style="position: relative; margin-right:20px; padding: 20px;">
+ This slide needs to be here to let the confetti settle otherwise the next slide lags even more lol... Just wait til the confetti goes away and continue.
+ </div>
</div>
</div>
<div id="slide-3">
<div class="fig">Fig 1.1 What most people thing a typical functional programming advocate looks like</div>
</div>
<div class="notes">
+ <h1>Wide-eyed Crazy Functional Programmers</h1>
<ul>
- <li>Regarded as eccentric crazies with wild ideas</li>
- <li>Spout nonsense like "monads" every 2 seconds</li>
- <li>Often bald</li>
+ <li>Some people were curious about the title, so I figured I'd clarify what it means - functional programmers have a reputation of...</li>
+ <ul>
+ <li>Being eccentric wide-eyed crazies with wild ideas</li>
+ <li>Spouting nonsense like "monads" and "functors" every 2 seconds</li>
+ <li>Being bald</li>
+ </ul>
</ul>
</div>
</div>
<div id="slide-4">
<div class="slide-title">=<< Obligatory Quote >>=</div>
- <div class="slide">
- </div>
- <div class="notes">
- <ul>
- <li>Before I get to far in to it, I want to add some framing to the talk</li>
- <li>My goal is not to teach you functional programming, my goal is to spark some curiosityt</li>
- </ul>
- </div>
- </div>
- <div id="slide-5">
- <div class="slide-title">=<< Obligatory Quote >>=</div>
- <div class="slide flexotron">
- <div class="textbox" style="font-size:30px;">If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.</div>
- </div>
- <div class="notes">
- <ul>
- <li>Before I get to far in to it, I want to add some framing to the talk</li>
- <li>My goal is not to teach you functional programming, my goal is to spark some curiosityt</li>
- <li>And I think this obligatory quote (every good talk has a quote) conveys the framework I used when writing these slides</li>
- <li>Also we like boats and ships and stuff like that here, so make sense I guess.</li>
- </ul>
- </div>
- </div>
- <div id="slide-6">
- <div class="slide-title">=<< Obligatory Quote >>=</div>
<div class="slide flexotron">
<div class="textbox" style="font-size:30px;">If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.<br /><br /> - Some French Guy. Idk. I'm not cultured. I'm Australian.</div>
</div>
<div class="notes">
+ <h1>Some Framing</h1>
<ul>
- <li>Before I get to far in to it, I want to add some framing to the talk</li>
- <li>My goal is not to teach you functional programming, my goal is to spark some curiosityt</li>
+ <li>My goal is not to teach you functional programming, my goal is to spark curiosity</li>
<li>And I think this obligatory quote (every good talk has a quote) conveys the framework I used when writing these slides</li>
- <li>Also we like boats and ships and stuff like that here, so make sense I guess.</li>
- <li>And of course, don't forget attribution. So that everyone knows you're cultured and read important things</li>
- <li>With that in mind, don't take any code examples too seriously, they are to demonstrate the big picture idea.</li>
- </ul>
- </div>
- </div>
- <div id="slide-7">
- <div class="slide-title">=<< What is this Talk About? >>=</div>
- <div class="slide">
- </div>
- <div class="notes">
- <ul>
- <li>So what is this talk about?</li>
- <li>Let me start by telling you some things it is not about</li>
- <li>Which is something you're not supposed to do as an educator but whatever</li>
+ <li>Also we like boats and ships and stuff like that here, so make sense I guess</li>
+ <li>I'm not gonna make you build the ship, I'm gonna try make you curious about the sea that is functional programming</li>
+ <li>With that in mind, don't take any code examples too seriously, they are to demonstrate the big picture idea</li>
</ul>
</div>
</div>
- <div id="slide-8">
+ <div id="slide-5">
<div class="slide-title">=<< What is this Talk About? >>=</div>
<div class="slide">
<h1>This talk is <span class="highlight">not</span> about:</h1>
</div>
</div>
<div class="notes">
+ <h1>Teaching Violation!</h1>
<ul>
- <li>So what is it about?</li>
- <li>When trying to explain to someone why they should learn functional programming, there are many perspectives to try explain it from.</li>
- <li>For this discussion, I've settled on a very meta one. Perspective itself.</li>
+ <li>They say you should never say what something is not when teaching</li>
+ <li>But screw that, anarchy! Yeah!</li>
</ul>
</div>
</div>
- <div id="slide-9">
+ <div id="slide-6">
<div class="slide-title">=<< What is this Talk About? >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Perspective</div>
</div>
<div class="notes">
+ <h1>What It Do, Then?</h1>
<ul>
- <li>As said, this is not a talk about haskell, it's about viewing programming through different perspectives"</li>
- <li>Please ask questions as we go!</li>
- <li>Let's start the talk!</li>
+ <li>So what is it about?</li>
+ <li>When trying to explain to someone why they should learn functional programming, there are many perspectives to try explain it from.</li>
+ <li>For this discussion, I've settled on a very meta one. Perspective itself.</li>
</ul>
</div>
</div>
- <div id="slide-10">
- <div class="slide-title">=<< What is Functional Programming? >>=</div>
- <div class="slide">
- </div>
- </div>
- <div id="slide-11">
+ <div id="slide-7">
<div class="slide-title">=<< What is Functional Programming? >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Programming with functions.</div>
</div>
+ <div class="notes">
+ <h1>Who could have guessed!</h1>
+ </div>
</div>
- <div id="slide-12">
+ <div id="slide-8">
<div class="slide-title">=<< What is Functional Programming? >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Programming with functions.<br /><br />No, really. Everything is a function.</div>
</div>
</div>
- <div id="slide-13">
- <div class="slide-title">=<< What is a Function? >>=</div>
- <div class="slide"></div>
- </div>
- <div id="slide-14">
+ <div id="slide-9">
<div class="slide-title">=<< What is a Function? >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >A mapping between sets that associates every element of the first set to exactly one element of the second set.</div>
</div>
<div class="notes">
+ <h1>Regarding Functions</h1>
<ul>
- <li>It's important to understand that that's it.</li>
- <li>This is different to functions in procedural languages - actually the name "function" is a misnomer in that context. Really they should be called prodedures or subroutines (hence the name procedural)</li>
+ <li>These aren't like procedural functions - "function" is a misnomer in that context. They are really procedures or subroutines (hence the name procedural)</li>
<li>A function is a mapping. It's equivalent to something like an array in PHP. It associates one value to another one</li>
<li>In the same way that a PHP array cannot mutate state, a function cannot</li>
- <li>What I'm describing are actually pure functions, but for the rest of the talk I'll just be saying "functions"</li>
- <li>This has some interesting consequences...</li>
+ <li>These are called "pure functions", but I'll just say "functions"</li>
+ <li>Mat asked a question about "impure functions"</li>
+ <ul>
+ <li>An impure function involves side effects. For example:
+ <div style="text-align: center;"><pre style="display: inline-block;"><code style="text-align: left; font-size: 18px;">
+function readFileAndAdd2(string $filePath) : int {
+ $number = file_get_contents($filePath);
+ return $number+2;
+}</code></pre></div>
+ is impure because it could be called with the same input and give different outputs (if the contents of the file at $filePath change).</li>
+ <li>I/O can be pure, but that's beyond the scope of this talk (maybe another dev training?)</li>
+ </ul>
</ul>
</div>
</div>
- <div id="slide-15">
+ <div id="slide-10">
<div class="slide-title">=<< What is a Function? >>=</div>
<div class="slide">
<h1>No equivalent constructs for:</h1>
</div>
<div class="textbox" style="width: 60%; margin: auto; margin-top:10px;">*In pure functional programming, there are true variables. That is, once you declare the value of a variable, you cannot change it. Contrast this with procedural languages where you can reassign a variable whenever you like.</div>
</div>
- </div>
- <div id="slide-16">
- <div class="slide-title">=<< Huh? >>=</div>
- <div class="slide"></div>
<div class="notes">
+ <h1>Consequences</h1>
<ul>
- <li>And of course this all begs the question....</li>
+ <li>As a consequence, of having only pure functions, we have no more control structures D:</li>
+ <li>That raises the question... (go to the next slide xD)</li>
</ul>
</div>
-
</div>
- <div id="slide-17">
+ <div id="slide-11">
<div class="slide-title">=<< Huh? >>=</div>
<div class="slide flexotron">
<div class="textbox" style="text-align:center; font-size:40px; text-shadow: 4px 4px #000; padding:20px;" >Who in their right mind would wanna do that?!</div>
</div>
<div class="notes">
+ <h1>Yeah, Who? Crazies, No Doubt</h1>
<ul>
- <li>You're trying to tell me FP is awesome be because it has ... less features?</li>
- <li>This is true, but it makes no difference. You can accomplish anything in FP that you can accomplish in a procedural language</li>
+ <li>It seems paradoxical, features have been removed, but somehow functional programming is just as good? Maybe better?</li>
+ <li>How can taking away all the tools we use to write programs be a good thing?</li>
+ <li>It actually makes no difference. You can accomplish anything in FP that you can accomplish in a procedural language, and gain some cool new superpowers</li>
</ul>
</div>
</div>
- <div id="slide-18">
+ <div id="slide-12">
<div class="slide-title">=<< Huh? >>=</div>
<div class="slide">
<h1>Why tho?</h1>
</div>
</div>
<div class="notes">
+ <h1>Learn for Big Brain</h1>
<ul>
- <li>The best answer I can give is, "learning is good". I think that's something everyone at moodle can agree on</li>
- <li>Learning FP is gonna require you to wrestle your brain in to shapes it's never taken before. Which will leave it with the plasticity to learn a greater variety of things you encounter.</li>
+ <li>Learning functional programming is gonna require you to wrestle your brain in to shapes it's never taken before. Which will leave it with the plasticity to learn a greater variety of things you encounter.</li>
<li>It will also make the math/logic part of your brain very buff</li>
- <li>As we know, the brain has 3 main cortexes. The passion cortex, the power cortext, and the logic cortex</li>
- <li>As programmers we need to engorge mostly the logic cortext, but also the passion cortex - as this is a profession that involves other people.</li>
- <li>Communicating about programs written in the functional style is actually easier than the programs written in the procedural style. More on that later</li>
- <li>And lets not forget that our very own MoodleNet is written in Elixir. A functional language.</li>
+ <li>As mentioned, there is no maths in this talk, but if you learn functional programming you will get buff maths brain</li>
+ <li>And as we know, the brain has 3 main cortexes: The passion cortex, the power cortext, and the maths/logic cortex</li>
+ <li>For the purposes of programming, we need a buff maths/logic cortext, learning functional programming will make us better programmers in general</li>
</ul>
</div>
</div>
- <div id="slide-19">
+ <div id="slide-13">
<div class="slide-title">=<< Paradigms >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Paradigms</div>
</div>
- <div class="notes">
- <ul>
- <li>Let's talk about paradigms for a bit</li>
- <li>In particular, let's talk about the two most widely used paradigms. Which also happen to be the most at odds</li>
- </ul>
- </div>
</div>
- <div id="slide-20">
+ <div id="slide-14">
<div class="slide-title">=<< Paradigms >>=</div>
<div class="slide flexotron">
<div class="textbox flexotron" style="position: relative; width: 30%; height: 50%; margin-right:20px;">
<li>PHP</li>
<li>C</li>
<li>Java</li>
- <li>DamoScript</li>
+ <li>BASIC</li>
</ul>
</div>
</div>
</div>
<div class="notes">
+ <h1>The Big Two</h1>
<ul>
- <li>So here they are. Declaritive and imperative, and inside those we see sub-paradigms (there are more, for example SQL is declaritive but not functional, and Assembly is imperative but not procedural - although the vast majority of imperative languages are indeed procedural):</li>
- <li>And then inside the boxes we see some examples of language that embody that paradigm</li>
- <li>For the purposes of this talk it's probably OK to just think of declaritive and functional as interchangeable, and some for imperative and procedural. I'll probably mix them up</li>
- <li>So why am I showing this? Well, let's look at this through a different perspective... Some of you might have realised that imperative and declaritive are both words used to describe human language, and that's relevant</li>
- <li>Learning a new paradigm is beneficial the same way learning a new human language is</li>
+ <li>Here are the big two paradigms, and inside those we see sub-paradigms.</li>
+ <li>And then in those there are some languages that embody that paradigm (there are more places languages can exist, for example SQL is declaritive but not functional, and Assembly is imperative but not procedural)</li>
+ <li>Marina made a comment that thinking about SQL while reading these slides is helpful - and I think that's true</li>
+ <ul>
+ <li>In SQL you express things in terms of relations, and there are no for loops, while loops, gotos, etc</li>
+ </ul>
+ <li>For this talk it's OK to just think of declaritive and functional as interchangeable, same with imperative and procedural</li>
+ <li>Foreshaddowing: Imperative and declaritive are both words used to describe human language</li>
+ <li>Learning a new paradigm is beneficial the same way learning a new human language is. It makes you better at programming and communicating.</li>
</ul>
</div>
</div>
- <div id="slide-21">
+ <div id="slide-15">
<div class="slide-title">=<< Gramatical Mood >>=</div>
<div class="slide flexotron">
<div class="textbox" style="position: relative; width: 30%; height: 50%; margin-right:20px; padding-top: 40px;">
</ul>
</div>
</div>
- <div id="slide-22">
+ <div id="slide-16">
<div class="slide-title">=<< Gramatical Mood >>=</div>
<div class="slide flexotron">
<div class="textbox flexotron" style="position: relative; width: 30%; height: 50%; margin-right:20px; padding-top: 40px;">
</div>
</div>
<div class="notes">
- <ul>
- <li>To make it more concise... here's the smallest definition I can think of</li>
- <li>And this applies to programs too. In the functional paradigm we no longer have the "instruction words" - things like, for, while, goto, variable reassignment</li>
- </ul>
- </div>
- </div>
- <div id="slide-23">
- <div class="slide-title">=<< Big Brain Moment >>=</div>
- <div class="slide"></div>
- <div class="notes">
- <ul>
- <li>And that brings us to the first of hopefully many "Big Brain Moments"</li>
- </ul>
+ This is the simplest way I can think to express difference
</div>
</div>
- <div id="slide-24">
+ <div id="slide-17">
<div class="slide-title">=<< Big Brain Moment >>=</div>
<div class="slide flexotron">
<div class="textbox" style="text-align:center; font-size:40px; text-shadow: 4px 4px #000; padding:20px;" >Programming languages <span class="highlight">ARE</span> human languages.</div>
</div>
<div class="notes">
- <ul>
- <li>We don't write programs for computers - we write programs for other humans.</li>
- </ul>
+ <h1>We don't write programs for computers<br />We write programs for other humans</h1>
+ </div>
+ <div class="notes">
+ <li>Unless your writing machine code or something like that...</li>
</div>
</div>
- <div id="slide-25">
+ <div id="slide-18">
<div class="slide-title">=<< Why is declaritive mood good? >>=</div>
- <div class="slide">
+ <div class="slide flexotron">
+ <div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Atemporality<br />Independant of or unaffected by time.</div>
</div>
<div class="notes">
+ <h1>I Can See Through Time!</h1>
<ul>
- <li>But in both cases, it seems like we lose something useful in the declaritive mode. What do we get by giving up these things?</li>
+ <li>In both the human language case, and the programming case, we give up our "instruction words" (in the case of programming, this is for, while, goto, etc)</li>
<li>Surely giving instructions is useful, otherwise how do you do anything?!</li>
+ <li>Do we get something good in return? Yes! We get atemporality</li>
+ <ul>
+ <li>This is super powerful and quite different from how we normally write programs</li>
+ <li>When we write in a procedural language we have to think about how things change over time</li>
+ </ul>
</ul>
</div>
</div>
- <div id="slide-26">
- <div class="slide-title">=<< Why is declaritive mood good? >>=</div>
- <div class="slide flexotron">
- <div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Atemporality</div>
- </div>
- </div>
- <div id="slide-27">
- <div class="slide-title">=<< Why is declaritive mood good? >>=</div>
- <div class="slide flexotron">
- <div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Independant of or unaffected by time.</div>
- </div>
- </div>
- <div id="slide-28">
+ <div id="slide-19">
<div class="slide-title">=<< Why is declaritive mood good? >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:50px; text-shadow: 4px 4px #000; padding:20px;" >Declarative programs express what <span class="highlight" style="display: block;">they actually do</span> leaving more "brain space" to focus on solving the problem.</div>
</div>
<div class="notes">
+ <h1>Expressivity</h1>
<ul>
- <li>A declaritive program expresses its operation in terms of relationships.</li>
- <li>In an imperative paradigm, thinking about the program means thinking about changes over time => keeping track of changes</li>
- <li>In a declaritive one, thinking about the program means thinking about relationships => look at what the thing is, how it relates to the other thing, and move on</li>
+ <li>In an imperative paradigm, thinking about the program means thinking about changes over time - which means we have to keep track of state in our head</li>
+ <li>In a declaritive paradigm, thinking about the program means thinking about relationships - which means we look at what the thing is, how it relates to the other thing, and move on</li>
</ul>
</div>
</div>
- <div id="slide-29">
+ <div id="slide-20">
<div class="slide-title">=<< To Recap >>=</div>
<div class="slide">
<h1>Why tho?</h1>
</div>
<div class="notes">
<ul>
- <li>Some problems are simply very difficult to solve in an imperative way.</li>
- <li>Especially when we are talking about events that are happening in parallel and may run at different speed/times</li>
+ <li>Some problems are very difficult to solve in an imperative way.</li>
+ <li>Especially when talking about events that are happening in parallel and may run at different speed/times</li>
<li>In the imperative paradigm, you quite easily come up against data races by virtue of the way the program is expressed</li>
+ <li>Functional programming takes away entire classes of problems by removing the "instruction words" - no more data races</li>
+ <li>If you ever used JavaScript before promises were a thing, I'm sure you've felt the pain</li>
</ul>
</div>
</div>
</div>
- <div id="slide-30">
- <div class="slide-title">=<< Some Code (Finally) >>=</div>
- <div class="slide">
- </div>
- <div class="notes">
- <ul>
- <li>At this point I imagine a lot of you are thinking....</li>
- </ul>
- </div>
- </div>
- <div id="slide-31">
- <div class="slide-title">=<< Some Code (Finally) >>=</div>
- <div class="slide flexotron">
- <div style="text-align:center; font-size:50px; text-shadow: 4px 4px #000; padding:20px;" >Enough of this philosophy and linguistics mumbo jumbo, already!</div>
- </div>
- </div>
- <div id="slide-32">
+ <div id="slide-21">
<div class="slide-title">=<< Some Code (Finally) >>=</div>
<div class="slide">
<h1>My favourite example</h1>
<div class="textbox" style="margin: auto; width: 60%; font-size: 20px;">In the declaritive paradigm, <span class="code-friends1" onmouseenter="activateFriends(1, true);" onmouseleave="deactivateFriends(1);" style="display: inline-block;">this</span> code hangs while <span class="code-friends2" onmouseenter="activateFriends(2, true);" onmouseleave="deactivateFriends(2);" style="display: inline-block;">this</span> code runs. In the imperative paradigm <span class="code-friends3" onmouseenter="activateFriends(3, true);" onmouseleave="deactivateFriends(3);" style="display: inline-block;">this</span> code hangs, while <span class="code-friends4" onmouseenter="activateFriends(4, true);" onmouseleave="deactivateFriends(4);" style="display: inline-block;">this</span> code runs.</div>
</div>
</div>
+ <div class="notes">
+ <h1>Hot tip!</h1>
+ <ul>
+ <li>Hover over the "this" words in the text box! Notice that the code which hangs is flipped in each paradigm!</li>
+ <li>This code is not any specific language. It's one I made up although it looks similar to other languages</li>
+ <li>The idea is to parse it in the declaritive and the imperative style to see the difference</li>
+ </ul>
+ </div>
</div>
- <div id="slide-33">
+ <div id="slide-22">
<div class="slide-title">=<< Some Code (Finally) >>=</div>
<div class="slide">
<div style="display: flex; margin-top: 50px;">
</div>
</div>
</div>
+ <div class="notes">
+ <h1>Reminder!</h1>
+ <ul>
+ <li>In the declaritive paradigm, = means that two things are one in the same - which leads to a contradiction in our example</li>
+ <li>In the imperative paradigm (assuming x is defined) there's no problem - we just add 1 to x, then save it back in x</li>
+ </ul>
+ </div>
</div>
- <div id="slide-34">
+ <div id="slide-23">
<div class="slide-title">=<< Some Code (Finally) >>=</div>
<div class="slide">
<div style="display: flex; margin-top: 50px;">
}</code></pre>
</div>
<div class="flexotron" style="height: 80%;">
- <div class="textbox" style="position: relative; width: 30%; height: 50%; margin-right:20px; padding-top: 30px;">
+ <div class="textbox" style="position: relative; width: 30%; height: 50%; margin-right:20px; padding-top: 40px;">
<span class="textbox" style="box-shadow: none; position: absolute; top: -20px; left: 30px;">Declarative</span>
"The repeat of `x` is `x` appended to the repeat of `x`"<br /><br /><br />
An infinite list of `x`!
</div>
</div>
</div>
+ <div class="notes">
+ <h1>Atemporality</h1>
+ <ul>
+ <li>Here we are starting to touch on atemporality</li>
+ <li>The declaritive style does not read the definition as instructions. It's not things happening over time. It just is what it is. It's a list of whatever you pass in repeated forever</li>
+ </ul>
+ </div>
</div>
- <div id="slide-35">
+ <div id="slide-24">
<div class="slide-title">=<< Big Brain Moment >>=</div>
<div class="slide flexotron">
<div class="textbox" style="text-align:center; font-size:40px; text-shadow: 4px 4px #000; padding:20px;" >Programming languages <span class="highlight">ARE</span> human languages.</div>
</div>
<div class="notes">
+ <h1>Recap/Reinforcement</h1>
<ul>
- <li>Let's take this time to reflect...</li>
<li>Imperative tells you what to do</li>
<li>Declaritive tells you what things are</li>
</ul>
</div>
</div>
- <div id="slide-36">
+ <div id="slide-25">
<div class="slide-title">=<< Some Code (Finally) >>=</div>
<div class="slide">
<h1>Real Haskell code that runs</h1>
</div>
<div class="notes">
<ul>
- <li>Let's think about the way this is understood</li>
- <li>threeFs is the first three elements in an infinite list of fs - totally fine, makes complete sense</li>
- <li>Shame that the function name is "take" but whatever</li>
+ <li>The first line is the Haskell way of defining the repeat function from before</li>
+ <li>And we read this as: "threeFs is the first three elements in an infinite list of fs"</li>
+ <ul>
+ <li>And that's totally fine! If you have an infinitely long list of fs then of course you can just take the first 3</li>
+ <li>It's a but unfortunate that the function to get n elements is called "take" because that's kinda imperative, but whatever</li>
+ </ul>
</ul>
</div>
</div>
- <div id="slide-37">
+ <div id="slide-26">
<div class="slide-title">=<< Some Code (Finally) >>=</div>
<div class="slide">
<h1>Real JavaScript code that hangs</h1>
</div>
<div class="notes">
<ul>
- <li>By contrast, this reads as "First compute an infinite list of fs" - which as we saw before was a problem. And even that human sentence clearly has a problem.</li>
+ <li>By contrast, this reads as "First compute an infinite list of fs" - which is clearly problematic</li>
+ <li>It's left as an exercise to the reader to try work out why the x = x + 1 example would hang in Haskell</li>
</ul>
</div>
</div>
- <div id="slide-38">
+ <div id="slide-27">
<div class="slide-title">=<< Big Brain Moment >>=</div>
<div class="slide">
<h1>What did declaritive mode give us?</h1>
</div>
</div>
<div class="notes">
+ <h1>Big Brain Moment Two!</h1>
<ul>
- <li>Big brain moment two!</li>
<li>How cool is that? Because we can express what things are, we can express an infininte list!</li>
+ <li>Often when we write programs, we have to worry about things cascading out infinitely, but not in the declaritive paradigm!</li>
<li>None of the declaritive version of the program relies on us traking changes anywhere. We just need to know what a thing is and how it relates to another thing</li>
+ <ul>
+ <li>And if that thing happens to be infinite, who cares! That's just what it is</li>
+ </ul>
</ul>
</div>
</div>
- <div id="slide-39">
+ <div id="slide-28">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Promises</div>
</div>
<div class="notes">
- <ul>
- <li>Let's think about promises...</li>
- <li>Seems like an odd tangent but let's go with it</li>
- <li>And just as before, I'm gonna break one of the carinal rules of teaching by telling you what promises are not...</li>
- </ul>
+ Seems like an odd tangent but let's go with it. And just as before, I'm gonna break one of the carinal rules of teaching by telling you what promises are not...
</div>
</div>
- <div id="slide-40">
+ <div id="slide-29">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide flexotron">
<div style="position: relative; text-align:center; font-size:40px; text-shadow: 4px 4px #000;" >
</div>
<div class="notes">
<ul>
- <li>So there's a lot of misleading information out there about promises</li>
- <li>Some people believe that promises "make" things asynchronous, but this isn't true</li>
- <li>You can have perfectly synchronous promises, the thing you pass as a callbackto a promise does not get "run in the background" or anything like that</li>
+ <li>There's a lot of misleading information out there about promises</li>
+ <li>Some people believe that promises "make things asynchronous", but this isn't true</li>
+ <li>You can have perfectly synchronous promises, the thing you pass as a callback to a promise does not get "run in the background" or anything like that</li>
</ul>
</div>
</div>
- <div id="slide-41">
+ <div id="slide-30">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide">
<h1>The real promises</h1>
</ul>
</div>
</div>
+ <div class="notes">
+ <ul>
+ <li>The "value" is where the asynchronous part comes in</li>
+ <li>That value may become available later, but it may just be there the entire time as well</li>
+ </ul>
+ </div>
</div>
- <div id="slide-42">
+ <div id="slide-31">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide">
<h1>Terminology/syntax recap</h1>
</div>
</div>
<div class="notes">
+ <h1>Regarding Composition</h1>
<ul>
- <li>Shoutout Mat about arrow functions</li>
- <li>A quick note on composition: So far you may have come across function composition. There's lots of different kinds of composition, but function composition is incredibly common, especially in programming. However in the example we are talking the composition of promises. In the sense that we combine to promises, and get another promise.</li>
+ <li>You may have come across function composition. There's lots of different kinds of composition, but function composition is incredibly common, especially in programming. But we'll talk about the composition of promises.</li>
+ <li>In both cases the idea is the same. Function composition lets you combine two functions in to another function. Promise composition lets you combine two promises in to another promise</li>
</ul>
</div>
</div>
- <div id="slide-43">
+ <div id="slide-32">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide">
<h1>Promise composition</h1>
</div>
</div>
<div class="notes">
+ <h1>Hot Tip!</h1>
<ul>
- <li>Depending on how we go for time, I hope to discuss composition after this section.</li>
+ <li>Hover over "one", "two", and "three" to see the promises highlighed</li>
+ <ul>
+ <li>The first one is all by itself</li>
+ <li>The second one is the composition of the first one using the composition rule (the function passed to `then`)</li>
+ <li>The third one is the composition of the second one using the composition rule (the function given to `then`)</li>
+ </ul>
+ <li>The `then` method accepts a function which:</li>
+ <ul>
+ <li>Will be passed the previous promise's wrapped value</li>
+ <li>Causing it return the next promise</li>
+ <li>Which will give its wrapped value to the function passed to the next `then` method</li>
+ </ul>
+ <li>It's very important to realise that we are passing a function to then, not a value, it's not actually doing anything when we set up the promise chain</li>
</ul>
</div>
</div>
- <div id="slide-44">
+ <div id="slide-33">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide">
<h1>OK great but who cares?</h1>
</ul>
</div>
</div>
+ <div class="notes">
+ <h1>Pls Note</h1>
+ <ul>
+ <li>Since this is JavaScript, you can mutate state in the functions that are passed to "then"</li>
+ <li>But that's beside the point I'm trying to demonstrate, and you shouldn't really do that anyway</li>
+ </ul>
+ </div>
</div>
- <div id="slide-45">
+ <div id="slide-34">
<div class="slide-title">=<< Promises >>=</div>
<div class="slide flexotron">
<div style="position: relative;">
</div>
</div>
<div class="notes">
- <ul>
- <li>This sure is starting to sound familiar.</li>
- </ul>
+ This sure is starting to sound familiar.
</div>
</div>
- <div id="slide-46">
+ <div id="slide-35">
<div class="slide-title">=<< Big Brain Moment >>=</div>
<div class="slide">
<h1>Woah!</h1>
<span class="code-friends7" onmouseenter="activateFriends(7);" onmouseleave="deactivateFriends(7);" style="display: inline-block">>>=</span> (<span class="code-friends8" onmouseenter="activateFriends(8);" onmouseleave="deactivateFriends(8);" style="display: inline-block">\x -></span> <span class="code-friends9" onmouseenter="activateFriends(9);" onmouseleave="deactivateFriends(9);" style="display: inline-block">Right</span> (<span class="code-friends10" onmouseenter="activateFriends(10);" onmouseleave="deactivateFriends(10);" style="display: inline-block">x ++ " and finally here!"</span>))</code></pre>
</div>
<div class="notes">
+ <h1>Hot Tip!</h1>
<ul>
- <li>Big brain time again</li>
- <li>It does not matter what order the promises resolve in, the final promise will always be resolved with "We start here..."</li>
- <li>In this specific example, there is nothing asynchronous happening, but it's not much work to adapt it so there is. I just wanted to really highlight the similarities with haskell</li>
+ <li>Hover over the language elements to see how they pair up in each language!</li>
+ <li>Promises are very similar to a type in Haskell called "Either". "Either" can be instantiated with `Right` or `Left` which correspond to `resolve` and `reject`, respectively</li>
+ <li>It does not matter what order the promises resolve in, the final promise will always be resolved with "We start here then get here and finally here"</li>
+ <li>Bas made a good point that when looking at the calls to "then" you think about the things happening one after another.</li>
+ <ul>
+ <li>While that's true, what `then` does is describe the way to combine the results once they arrive</li>
+ <li>The "We start here" result could come from a web request that takes 10 seconds, whereas the other strings could resolve instantly, but the final promise would still be "We start here then get here and finally here" - even though that was not the order we got the results</li>
+ <li>Be careful, the `x` in each "then" call is not the same `x`. It's part of the function which is being passed to then, which means it is in a completely different scope. The purpose of the function is to describe what you want to happen</li>
+ <li>It's hard to untwist your brain from thinking about promises in the procedural way - this is what I meant by "wrestling your brain in to new shapes" :)</li>
+ </ul>
+ <li>In this example, there is nothing asynchronous happening, but it's not much work to adapt it so there is. I mainly wanted to really the similarities with haskell</li>
+ <li>How cool is it that these look so similar?</li>
+ <li>As mentioned, in the JavaScript version, you could mutate something inside the `then` functions - but this would absolutely lead to data races</li>
+ <li>In Haskell, you cannot do that, which is one of the ways it stops you shooting yourself in the foot</li>
+ <li>Noel made an interesting comment that JavaScript added async/await as "syntactic sugar" to make this kind of code look more imperative.</li>
+ <ul>
+ <li>And I was pleased to say that the exact same thing exists in Haskell :)</li>
+ </ul>
</ul>
</div>
</div>
- <div id="slide-47">
+ <div id="slide-36">
<div class="slide-title">=<< Big Brain Moment >>=</div>
<div class="slide">
<h1>Woah!</h1>
<span class="code-friends7" onmouseenter="activateFriends(7);" onmouseleave="deactivateFriends(7);" style="display: inline-block">>>=</span> (<span class="code-friends8" onmouseenter="activateFriends(8);" onmouseleave="deactivateFriends(8);" style="display: inline-block">\x -></span> <span class="code-friends9" onmouseenter="activateFriends(9);" onmouseleave="deactivateFriends(9);" style="display: inline-block">Right</span> (<span class="code-friends10" onmouseenter="activateFriends(10);" onmouseleave="deactivateFriends(10);" style="display: inline-block">x ++ " and finally here!"</span>))</code></pre>
</div>
<div class="notes">
+ <h1>You Were Doing FP all Along!</h1>
<ul>
<li>Likewise, we can put a failure anywhere in the chain. It doesn't matter if the failure happens first, last, or anywhere in between. The result is always a failed promise of "Oh noes!"</li>
<li>So, if you've ever used promises, you've been doing declaritive style programming without even realising it!</li>
</ul>
</div>
</div>
- <div id="slide-48">
+ <div id="slide-37">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div style="text-align:center; font-size:60px; text-shadow: 4px 4px #000; padding:20px;" >Composition</div>
</div>
<div class="notes">
+ <h1>The section on composition!</h1>
<ul>
- <li>Let's think about composition...</li>
- <li>Mat touched on function composition briefly in his talk</li>
- <li>I wantto talk about it in a more abstract sence. I think the idea of composition is so important that it deserves its own little bit</li>
+ <li>This gets its own section because it is not just important to programming, it's important to life in general</li>
</ul>
</div>
</div>
- <div id="slide-49">
+ <div id="slide-38">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<img src="img/composition0.png" style="height: 700px;" />
</div>
</div>
- <div id="slide-50">
+ <div id="slide-39">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div style="position: relative;">
</div>
</div>
</div>
- <div id="slide-51">
+ <div id="slide-40">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div style="position: relative;">
</div>
</div>
</div>
- <div id="slide-52">
+ <div id="slide-41">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div style="position: relative;">
</div>
</div>
<div class="notes">
+ <h1>Coins and pipes!</h1>
<ul>
- <li>RETURN LATER: Come back to this slide after looking at the next one</li>
- <li>We want to go from A to C - but maybe that's really hard</li>
- <li>Perhaps someone worked out how to go from A to B, and someone else worked out how to go from B to C</li>
- <li>Well, if we're in a system where composition is possible, then we just solved the problem!</li>
- <li>This is the natural way people solve problems</li>
- <li>RETURN EVEN LATER: After returning from the end slide: explain how side effects break composition</li>
+ <li>Keep in mind the the composition of A->B and B->C is not gauranteed to exist!</li>
+ <li>I'm using coins and pipes to demonstrate, but the coins and pipes could be anything... Functions, promises, etc.</li>
+ <li>Stop reading here!! After reading the next slide come back to this one pls :)</li>
+ <ul>
+ <li>We want to go from A to C - but maybe that's really hard (I accidentally illustrated that in the diagram! The pipe from A to C is really long! But the A->B->C route is short!)</li>
+ <li>Perhaps someone worked out how to go from A to B, and someone else worked out how to go from B to C</li>
+ <li>If we're in a system where composition is possible, then we just solved the problem!</li>
+ <li>This is the natural way people solve problems</li>
+ <ul>
+ <li>We like to break things up in to small chunks and solve the small bits and then put them back together</li>
+ <li>You probably do it when you're writing software at Moodle!</li>
+ </ul>
+ </ul>
+ <li>Stop reading here!! After getting to the "What's this got to do with FP" slide, come back pls :)</li>
<ul>
- <li>Maybe A->B has a side effect, this means when we call B->C with the result from A->B, it may not be the same as calling A->C. The point of composition is that the outcome should be the same.</li>
- <li>Don't talk about it unless needed: Referential transparency. f(a, b) => return print(a + b) + print(a + b); is not the same program as f(a,b) => c = print(a + b); return c + c;</li>
+ <li>Maybe A->B has a side effect, this means when we call B->C with the result from A->B, it may not be the same as calling A->C. The point of composition is that the outcome of calling both should be indistinguishable.</li>
+ <li>Procedures in imperative languages (what most programmers call functions) are a short sighted attempt at composition, we wanted a way to break things up, and sure... You can put functions together in imperative languages and it kinda works, but it's not the same as true composition</li>
+ <li>In the functional paradigm, composition is gauranteed because functions cannot have side effects</li>
</ul>
- <li>Procedures in imperative languages are a short sighted attempt at composition</li>
- <li>In the functional paradigm, composition is gauranteed because functions cannot have side effects</li>
</ul>
</div>
</div>
- <div id="slide-53">
- <div class="slide-title">=<< Composition >>=</div>
- <div class="slide">
- <h1>OK great but who cares?</h1>
- </div>
- </div>
- <div id="slide-54">
+ <div id="slide-42">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide">
<h1>OK great but who cares?</h1>
</div>
<div class="notes">
<ul>
- <li>Go back to the full composition diagram</li>
+ <li>Remember to go back to the previous slide!</li>
</ul>
</div>
</div>
- <div id="slide-55">
+ <div id="slide-43">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide">
<h1>Examples</h1>
<div class="notes">
<ul>
<li>The pyramids were build by having loads of peope work in parallel</li>
- <li>Same with the LHC. I don't believe there is a single person in the world who fully understands it</li>
- <li>Instead of having one chef "make a burger" - staff make individual parts of the burger and compose it together - I think McDonald's was the first place to do this</li>
+ <li>Same with the LHC - I don't believe there is a single person in the world who fully understands it</li>
+ <ul>
+ <li>But with lots of people working together we can create this amazing thing which recreated conditions similar to that at the near-instant our universe began!</li>
+ <li>That's pretty amazing</li>
+ </ul>
+ <li>And with McDonald's - Instead of having one chef "make a burger" staff make individual parts of the burger and compose it together (I think McDonald's was the first place to do this)</li>
+ <ul>
+ <li>You can make a lot more burgers that way!</li>
+ </ul>
<li>And Moodle does it too! Let's think about how we tackle projects...</li>
</ul>
</div>
</div>
- <div id="slide-56">
- <div class="slide-title">=<< Composition >>=</div>
- <div class="slide"></div>
- <div class="notes">
- <ul>
- <li>So... do we get one mega awesome dev to bash out features?</li>
- </ul>
- </div>
- </div>
- <div id="slide-57">
+ <div id="slide-44">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div style="height:80%;" >
</div>
<div class="notes">
<ul>
+ <li>Do we get one ultimate developer to smash out the whole thing?</li>
<li>idk about you, but I wouldn't be keen to work with this person</li>
- <li>There's a thing in dev called the 10x developer, and it is something that simply does not exist</li>
- <li>The correct way to work on software is of course...</li>
+ <li>Check out <a href="https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/">this story</li>
</ul>
</div>
</div>
- <div id="slide-58">
+ <div id="slide-45">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div class="textbox"><h1>No, you get friends to take a piece and help!</h1></div>
</div>
<div class="notes">
<ul>
- <li>As a team!</li>
+ <li>Of course not, we do it as a team!</li>
<li>This is why it's worth spending the time to plan things and figure out how to "chop up" the work</li>
- <li>We need to make sure we are chopping the problem up in to pieces that can be composed together later</li>
+ <li>It's very important to make sure the way we "chop" the problem allows the solutions to be composed together later</li>
</ul>
</div>
</div>
- <div id="slide-59">
+ <div id="slide-46">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide flexotron">
<div class="textbox" style="text-align:center; font-size:40px; text-shadow: 4px 4px #000; padding:20px;" >Composition is nature's greatest hack</div>
</div>
<div class="notes">
+ <h1>Why was all that relevant?</h1>
<ul>
<li>My goal here was to try and convince you that composition really is important and is fundamental to the way we think</li>
- <li>Humans are amazing for our ability to break down problems in to manageable chunks and then compose them together.</li>
+ <li>Humans are amazing for our ability to break down problems in to manageable chunks and then compose them together - I don't think other animals do that</li>
+ <ul>
+ <li>Which is probably a big part of how we dominated this planet so fast</li>
+ </ul>
<li>At its core, composition is about relationships, and building complexity by combining them. Hey, wasn't the whole declaritive thing about relationships?</li>
- <li>And that brings me to my final point</li>
+ <ul>
+ <li>At the beginning I said in the declaritive paradigm we express things in terms of relationships...</li>
+ </ul>
+ <li>And that brings me to the final point</li>
</ul>
</div>
</div>
- <div id="slide-60">
+ <div id="slide-47">
<div class="slide-title">=<< Composition >>=</div>
<div class="slide">
<h1>What's this got to do with FP?</h1>
</div>
<div class="notes">
<ul>
- <li>Go back to the composition slide and explain that in FP the composition is gauranteed to exist, while in other paradigms it is not</li>
- </ul>
+ <li>Functional programming is great because it gaurantees composition</li>
+ <li>In a procedural language, things don't necessarily compose</li>
+ <li>The building blocks we use for our compositions matter (whether it be programs, teamwork, whatever)</li>
+ <ul>
+ <li>The restrictions that the funcational paradigm places on you means you cannot work with blocks that do not compose</li>
+ <li>So by taking away our "instruction words" we have gained another powerful tool: composition</li>
+ <li>Remember that slide I said to go back to? Do that now pls! Then comeback here cos there's a few more slides after this one.</li>
+ </ul>
</div>
</div>
- <div id="slide-61">
+ <div id="slide-48">
<div class="slide-title">=<< Closing Notes >>=</div>
- <div class="slide"></div>
+ <div class="slide">
+ <h1>Very big brain thoughts:</h1>
+ <div class="textbox" style="width: 60%; margin: auto; text-align: left;">
+ <h1>Functional programming is awesome because:</h1>
+ <div class="textbox" style="width: 60%; margin: auto; text-align: left;">
+ <ul>
+ <li>By taking away convenient, but dangerous tools we are left with tools that are incredibly powerful, but more difficult to wield</li>
+ <li>In particular</li>
+ <ul>
+ <li>Atemporality: The ability to express things independant of time</li>
+ <li>Infinity: Infinite recursion can't stop you now!</li>
+ <li>Composition: The fundamental way humans solve problems is available to you at all times</li>
+ </ul>
+ </ul>
+ </div>
+ </div>
+ </div>
<div class="notes">
<ul>
- <li>I'd like to finish this talk with some food for thought...</li>
+ <li>New super powers!</li>
</ul>
</div>
</div>
- <div id="slide-62">
+ <div id="slide-49">
<div class="slide-title">=<< Closing Notes >>=</div>
<div class="slide">
<h1>Very big brain thoughts:</h1>
</ul>
</div>
</div>
- <div id="slide-63">
+ <div id="slide-50">
<div id="cloudguy2">
<div style="height: 20%; text-align: center;">
<img style="height: 100%; display: block; margin-left: auto; margin-right: auto; margin-bottom: 10px;" src="img/cloudguy.gif" />
<div class="notes">
<ul>
<li>If nothing else, I really hope you're now just a little bit more curious about functional programming</li>
- <li>And even though functional programing is not incredibly relevant to our roles just now, learning more about it will make you a better programmer</li>
+ <li>And even though functional programing is not incredibly relevant to our roles just now, learning more about it will make you a better programmer, and that benefits everyone :)</li>
<li>If you have any questions please message me, I'm always happy to talk about this stuff</li>
<li>I'd suggest going to the pub to talk about it, but, well, we can't do that just now</li>
+ <li>Bas mentioned that Haskell has a reputation for being academic</li>
+ <ul>
+ <li>It's true that it was initially written for academic purposes</li>
+ <li>But that was over 30 years ago and it has now evolved in to something that is usable in production</li>
+ </ul>
+ <li>Bas also asked about real world Haskell applications, here's a few I know of</li>
+ <ul>
+ <li>Facebook's spam filter is written in Haskell (and they even contributed back to the Haskell project)</li>
+ <li>Loads of banks use it for the reason that it's hard to write software that "goes wrong" in Haskell</li>
+ <li>Target use a program written in Haskell to optimise supply chains</li>
+ <li>NASA!</li>
+ </ul>
+ <li>And here's some resources!</li>
+ <ul>
+ <li>https://haskellbook.com/</li>
+ <li>http://learnyouahaskell.com/introduction</li>
+ <li>Me! I'm no master, but I'll always be happy to talk about Haskell and functional programming - send me a mesage!</li>
+ </ul>
+ <li>And remember, you can't spell "Functional Programming" without "Fun"!</li>
</ul>
</div>
</div>
document.onkeydown = checkKey;
notes = document.querySelectorAll('#slide-' + currentSlide + ' .notes');
- if(!!notes[0]) {
+ if(!!notes[0]) {1
bc.postMessage(notes[0].innerHTML);
}
+ numSlides = document.querySelectorAll('div[id^="slide-"]').length;
+
function checkKey(e) {
e = e || window.event;
}
- if (currentSlide == 1 || currentSlide == 63) {
+ document.location.hash = currentSlide;
+ if (currentSlide == 1 || currentSlide == numSlides) {
confetti.start();
} else {
confetti.stop();
projects / fp-lecture.git / commitdiff
