Podcast appearances and mentions of evan czaplicki

Evan Czaplicki—the creator of the Elm programming language —joins me to discuss the state and future of Elm, the friendly, type-safe functional programming language. On many fronts Elm has been a huge success: it's been popular with new and seasoned programmers alike; it's helped push several language ideas into the mainstream; it's been a key part of several successful software businesses and he even found himself employed as a kind of Language Designer in Residence. And yet, the material rewards of a successful open-source project were…lacking. Was he naive? Can an open-source developer stay true to open-source principles and still make a decent living? Is open source being exploited by commercial software businesses? These topics and more tumble out of what has to be the first question in the podcast: What's happening with Elm?--Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinElmLang: https://elm-lang.org/The Economics Of Programming Languages: https://www.youtube.com/watch?v=XZ3w_jec1v8Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.socialKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/

Fredrik talks to Evan Czaplicki, creator of Elm about figuring out a good path for yourself. What do you do when you have a job which seems like it would be your dream job, but it turns out to be the wrong thing for you? And how do you escape from that? You can't put the success of something you build before your own personal and mental health, no matter how right the decision may be for the thing you build. Is there ever a reproducible path? Aren't most or all successful things in large part a result of their circumstances? Platform languages and productivity languages - which do you prefer? Thoughts on the tradeoffs of when and how to roll things out and when to present ideas. Evan's development mindset and environment, and the ways it has affected Elm's design - all the way down to the error messages. Finally, of course, the benefits of country life - out of the radiation of San Francisco. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Evan Elm Prezi Guido van Rossum Brendan Eich Bjarne Stroustrup Hindley–Milner type inference Gary Bernhardt Talks by Gary SIMD Standard ML Ocaml Haskell Lambda calculus Algebraic data types Type inference Virtual DOM Webbhuset Dart Safari's no performance regressions rule Sublime text GHC Nano Emacs Titles The personal aspects A culture clash I wasn't supposed to be here This numb feeling I've never really been to the real world Is this even real? The path that Guido did This is you This isn't for me, and it's your fault Valuing my own health Reckless indifference A dispute between colleagues A nice solution will come out if you're patient enough Here's your error message: good luck Farmer's disposition These are good years Getting paid in chickens for web development Finding a place

Fredrik talks to Evan Czaplicki, creator of Elm about figuring out a good path for yourself. What do you do when you have a job which seems like it would be your dream job, but it turns out to be the wrong thing for you? And how do you escape from that? You can’t put the success of something you build before your own personal and mental health, no matter how right the decision may be for the thing you build. Is there ever a reproducible path? Aren’t most or all successful things in large part a result of their circumstances? Platform languages and productivity languages - which do you prefer? Thoughts on the tradeoffs of when and how to roll things out and when to present ideas. Evan’s development mindset and environment, and the ways it has affected Elm’s design - all the way down to the error messages. Finally, of course, the benefits of country life - out of the radiation of San Francisco. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Evan Elm Prezi Guido van Rossum Brendan Eich Bjarne Stroustrup Hindley–Milner type inference Gary Bernhardt Talks by Gary SIMD Standard ML Ocaml Haskell Lambda calculus Algebraic data types Type inference Virtual DOM Webbhuset Dart Safari’s no performance regressions rule Sublime text GHC Nano Emacs Titles The personal aspects A culture clash I wasn’t supposed to be here This numb feeling I’ve never really been to the real world Is this even real? The path that Guido did This is you This isn’t for me, and it’s your fault Valuing my own health Reckless indifference A dispute between colleagues A nice solution will come out if you’re patient enough Here’s your error message: good luck Farmer’s disposition These are good years Getting paid in chickens for web development Finding a place

Mario Rogic comes back to interview Jared about his road to Elm, from the Tandy to JavaScript fatigue, and the inevitable, relieving discovery of Elm. The love for Elm never stops.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2024.02.05GuestJared M. SmithShow notes[00:00:28] Sponsored by Logistically[00:00:54] The exclusive wrapElm Town 68 – Shared joy with Mario Rogic[00:01:55] Getting started in computing & programmingElm Town 65 – Let's roll with it with Jeroen EnglesElm Town 66 – A gateway to scientific research with Chris Martin[00:08:09] Informing the path to Elm"Solving the Boolean Identity Crisis" by Jeremy Fairbank"Mogee or how we fit Elm in a 64×64 grid" by Andrey KuzminElm Town 61 – Turning the pages with Dillon Kearns [00:15:39] JavaScript fatigue[00:21:24] elm-poolhttps://github.com/w0rm/elm-poolhttps://jaredmsmith.com/dev/elm-pool-collaboration[00:25:34] Why did you choose to introduce Elm at work?[00:30:13] Failing to introduce functional programming at work"How to Use Elm at Work" by Evan Czaplicki[00:34:31] Elm at LogisticallySimon Lydell's elm-watchMatthew Griffith's elm-codegenWolfgang Schuster's elm-open-api[00:37:42] Meta Elm TownElm Town 72 – 435 million reasons to love Elm + Elixir with Erik Person[00:43:26] Hit record vibe shiftElm RadioZed (May 2024 Jared's daily driver)[00:48:01] PicksJared's pickMDNMario's picksNixLamdera

Lindsay Wardell tells how she persevered to write her own story as a programmer and shares her views on JavaScript frameworks & fatigue.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.11.06GuestLindsay WardellShow notes[00:00:20] Sponsored by Logistically[00:00:49] Introducing LindsayHuman Side of DevElm and Vite on Elm Radio, hosted by Dillon Kearns & Jeroen EngelsFunctional programming with Elm on PodRocket, hosted by Paul MikulskisFunctional and Object-Oriented Programming on Software Unscripted, hosted by Richard Feldman"Functional Programming in Vite" at ViteConf 2023elm-vue-bridgevite-elm-template.[00:01:54] Getting started in computing and programming[00:06:06] A break in Brazil"How to teach programming (and other things)?" by Felienne Hermans[00:09:27] Getting back into programmingFunctional and Object-Oriented Programming on Software Unscripted, hosted by Richard Feldman...again[00:18:55] Why Elm?JuralenFunctional and Object-Oriented Programming on Software Unscripted, hosted by Richard Feldman...yet again. Seriously, it's good.[00:28:06] The road to NoRedInkWikifunctionsViews on VueS08E014 Modern Web Podcast - Elm with Richard Feldman[00:33:05] JavaScript fatigue[00:38:04] Standardization around Vite[00:41:13] The challenge of legacy code at NoRedInknoredink-uiElm Landelm-pages[00:46:22] Star CommanderStar Commander (GitHub)Elm Town 63 – Opening the doors of functional programming[00:53:47] What are you excited about?Lamdera"The Economics of Programming Languages" by Evan Czaplicki at Strange Loop 2023[00:55:50] PicksLindsay's picksNuxtNaNoWriMo (National Novel Writing Month)Blood on the ClocktowerBabylon 5Jared's picksBattlestar GalacticaS2E2 - "One Moore", PortlandiaFeel It All Around by Washed Out

Jim Carlson shares his discoveries in software development through the people he's met in the community and the projects he's building. We also discuss how a history in mathematics shapes his work.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.10.13GuestJim CarlsonShow notes[00:00:16] Sponsored By Logistically[00:00:45] Introducing Jim"Making a LaTeX-to-Html parser in Elm" at Elm Europe 2018jxxcarlson/meenylatex"Tarring files with Elm" at Oslo Elm Day 2019jxxcarlson/elm-tarjxxcarlson/elm-markdownjxxcarlson/elm-l0-parserRandom Exchange ModelSchelling's segregation model"Making Elm Talk to Your Personal Supercomputer" at elm-conf 2019Fake Drum Language Apphttps://scripta.ioElm NotebookElm Town 29 - Knode.io with Jim Carlson in 2018 w/Murphy Randle[00:02:10] History in Mathematics[00:04:27] Serious software development[00:06:37] Getting out of the basementMatthew Griffith's elm-uiLamdera[00:09:59] Problem-solving approaches[00:14:43] Scripta.io[00:19:25] Learning Haskell[00:24:40] Elm NotebookBooklib.ioelm-in-elm/compilerMinibill's elm-interpreterElm Land

Ryan Haskell-Glatz talks about making Elm mainstream, learning through iterations of elm-spa, and how experiences at Vendr shaped Elm Land.Note: the quality of Jared's recording is off and there are technical difficulties with the video at the end.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.06.05GuestRyan Haskell-GlatzShow notes[00:00:11] Introducing Ryan@rhg_dev on YouTubeElm Landelm-sparyannhg/date-formatryannhg/graphqlGrowing Programming Communities on Software Unscripted with Richard Feldman[00:00:57] A common computing genesisLet's be mainstream! by Evan Czaplicki at Curry On Prague, 2015Seven Seas Remake[00:12:27] Elm at workelm-spa v3elm-spa v6 on Elm Radio[00:20:15] Solving different problems with Elm Land vs. elm-spaorus-io/elm-spa[00:24:03] Scaling an Elm Land projectelm-pagesDillon's elm-graphql["Incremental Type Driven Development"]](https://youtu.be/mrwn2HuWUiA) by Dillon Kearns at Elm Europe 2019[00:33:54] How the experience at Vendr shaped Elm LandMatthew Griffith's elm-ui[00:39:21] Sponsored by Logistically[00:39:55] Success with Elm at scale at VendrElm Town 60 – Productivity and the culture of moving a little bit slower with Wolfgang Schuster[00:43:12] Exciting stuff with Elm Land 0.19Elm Land: The Sai Update (0.19)The Milkmaid (Vermeer)[00:47:49] PicksRyan's Picks"Let's be mainstream!" by Evan Czaplicki at Curry On Prague, 2015"On Storytelling" by Evan Czaplicki at Deconstruct, 2017Jared's PicksElm RadioSoftware Unscripted

Tessa Kelly shares her experience unblocking users while building quality software, explains how to avoid the "accessibility dongle" using the Elm philosophy, and considers some tesk9/accessible-html design changes.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.04.04GuestTessa Kelly (https://github.com/tesk9)Show notes[00:00:13] Sponsored by Logistically[00:00:47] Introducing Tessa Kelly (she needs no introduction)Elm Town 9 - Getting StartedElm Town 30 - Accessibility with Tessa KellyElm Radio - (2020) Holiday Special!Elm Radio - Accessibility in Elmtesk9/accessible-htmltesk9/palette"Functional Data Structures" at elm-conf 2016"Accessibility with Elm" at elm-conf 2017"Writing Testable Elm" at elm-conf 2019Software Unscripted - Accessibility in Practice with the Accessibilibats!

Aaron Strick shares what it was like learning Elm at NoRedInk, and explains some of the "zany" (delightful) ways Elm is used at Brilliant.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Intro music by Jesse Moore.Outro music (The Elm Song) by Matt Farley. (Commissioned by Michael Glass for elm-conf 2019.)Recording date: 2023.03.10GuestAaron Strick (https://aaronstrick.com/)Show notes[00:00:56] Introducing Aaron Strick[00:01:47] An eclectic background[00:05:12] The impetus for Aaron's journey into computers[00:07:10] Learning Elm at NoRedInk"A Farewell to FRP" by Evan Czaplicki on the move away from signals to The Elm Architecture.[00:10:32] What Aaron likes about Elmiselmdead.info[00:13:27] Challenges when learning Elm as first functional language[00:19:33] Mentors at NoRedInkElm Town 15 - Spotlight on Hardy JonesElm in Action by Richard Feldman"Haskell, in Elm terms: Type Classes" by Tereza Sokol[00:23:26] Richard gives us a memorable moment from NoRedInk[00:27:27] Benefits of the holistic approachElm Town 55 – From algorithms & animation to building a decentralized finance app with Dwayne CrooksDiscourse post with Cal Newport quote & how Evan works[00:30:18] Brilliant ways to use Elm"Diagrammar: Simply Make Interactive Diagrams" by Pontus Granström (Strange Loop 2022)Year End Review 2022 post on Aaron's website about working on a mathematical input boxBrilliant.org math courses[00:52:56] Using elm-pages to build aaronstrick.comaaronstrick.comelm-pages.comAaron's music (including the "Turtlehead Poo" cover)[00:59:02] PicksAaron's picksCSS for Javascript Developers by Josh W. ComeauEverything Everywhere All at OnceJared's picksCourtney BarnettParable of the Sower by Octavia E. ButlerThanks, everyone, for coming to Elm Town! If you're enjoying the show, please share it with friends and like/rate it on your podcast platform.

Kevin Yank shares the challenges Culture Amp faced when scaling Elm & React with a Design System team in the middle, and how an acquisition tipped the ultimate decision to move Elm from “adopt” to “contain” at the company.Oh yeah, and there's a new host, Jared M. Smith...stay tuned for more episodes!Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2023.04.06 (07 on Kevin's side of the world.)GuestKevin Yank (kevinyank.com)Show Notes00:01:03 Some of Kevin's contributions to Elm"Developer Happiness on the Front End with Elm""Elm in Production: Surprises & Pain Points""Elm at Scale: More Surprises, More Pain Points"cultureamp/elm-css-modules-loader00:01:45 History of Elm at Culture AmpElm Town 10 – About being "in production"Elm Town 14 – Spotlight on Kevin Yank00:04:49 "Why didn't you just…"Evan Czaplicki's talk "The Hard Parts of Open Source"00:05:54 The exciting challenge: styling Elmelm-css-modules-loader00:10:50 Sharing a design system00:13:48 Design System team challenges00:16:30 Acquiring a large React codebase00:17:24 Upgrading to Elm 0.1900:19:24 Momentum before the acquisition00:24:12 Communicating the decision to “contain” Elm00:32:43 An alternative reality with Elm for Culture Amp00:42:26 How Elm changed the way that the teams at Culture Amp work00:44:34 Elm as a secret weapon for recruitment00:48:00 “Why didn't you just use web components?”00:49:25 Kevin's blog postOn Endings: Why & How We Retired Elm at Culture Amp00:55:56 Success, or how never adopting Elm at Culture Amp would be worse00:59:34 Take responsibility for user experiencesEvan's tweet01:00:23 Reminiscing on past episodesElm Town 48 - Making Little Games Like PresentsElm Town 51 – You went down the well? That's the cheat way!Elm Town 37 - Upgrading to Elm 0.19 with Luke Westby & Richard FeldmanElm Town 36 - The Risk of Elm with Dhruv Dang…all of them ;)01:06:15 Elm Radio rocks!01:08:10 ThanksKevin YankXavier HoMurphy RandleFergus MeiklejohnFormer sponsorsListeners...and many more

#PLTalk programming language panels#PLTalk panel discussion on fundingElm compiler roadmap documentelm-language-serverelm-format's abstract syntax tree output is in the brainstorming phaseelm-typescript-interop (the old approach)elm-ts-interop Elm Radio episode

Cuarto episodio de la serie especial sobre programación funcional dirigida por Andros Fenollosa. En esta ocasión se dedica al lenguaje Elm, algo particular debido a que ha sido diseñado para funcionar solo en el navegador web. Entre otras características podemos destacar que es declarativo, está influenciado por Haskell y diseñado para obtener robustez, usabilidad y rendimiento. Este lenguaje funcional hizo su aparición en el año 2012 gracias a Evan Czaplicki, creador de Elm. Para este episodio sobre Elm, Andros cuenta con la compañía de David Hernandez, un profesional con más de 10 años programando para empresas de servicios y productos. Aunque principalmente ha estado con PHP, también ha podido tocar Javascript, Node, Python, Java y Elm, lenguaje que le ha traído a nuestro podcast. Sus roles han sido diversos: CTO, development manager y tech lead entre otros. Entre las cuestiones discutidas en el episodio: ¿Cómo te metiste a la programación funcional? Origen y características de Elm Beneficios y diferencias de Elm Desventajas de Elm Frontend con Elm Futuro, comunidad y recursos No te pierdas los otros episodios de la serie sobre programación funcional sobre Clojure, Elixir y Haskell.

Cuarto episodio de la serie especial sobre programación funcional dirigida por Andros Fenollosa. En esta ocasión se dedica al lenguaje Elm, algo particular debido a que ha sido diseñado para funcionar solo en el navegador web. Entre otras características podemos destacar que es declarativo, está influenciado por Haskell y diseñado para obtener robustez, usabilidad y rendimiento. Este lenguaje funcional hizo su aparición en el año 2012 gracias a Evan Czaplicki, creador de Elm. Para este episodio sobre Elm, Andros cuenta con la compañía de David Hernandez, un profesional con más de 10 años programando para empresas de servicios y productos. Aunque principalmente ha estado con PHP, también ha podido tocar Javascript, Node, Python, Java y Elm, lenguaje que le ha traído a nuestro podcast. Sus roles han sido diversos: CTO, development manager y tech lead entre otros. Entre las cuestiones discutidas en el episodio: - ¿Cómo te metiste a la programación funcional? - Origen y características de Elm - Beneficios y diferencias de Elm - Desventajas de Elm - Frontend con Elm - Futuro, comunidad y recursos No te pierdas los otros episodios de la serie sobre programación funcional sobre Clojure, Elixir y Haskell. Todos los enlaces en nuestra web https://republicaweb.es/podcast/descubriendo-la-programacion-funcional-elm-con-david-hernandez/

Cuarto episodio de la serie especial sobre programación funcional dirigida por Andros Fenollosa. En esta ocasión se dedica al lenguaje Elm, algo particular debido a que ha sido diseñado para funcionar solo en el navegador web. Entre otras características podemos destacar que es declarativo, está influenciado por Haskell y diseñado para obtener robustez, usabilidad y rendimiento. Este lenguaje funcional hizo su aparición en el año 2012 gracias a Evan Czaplicki, creador de Elm. Para este episodio sobre Elm, Andros cuenta con la compañía de David Hernandez, un profesional con más de 10 años programando para empresas de servicios y productos. Aunque principalmente ha estado con PHP, también ha podido tocar Javascript, Node, Python, Java y Elm, lenguaje que le ha traído a nuestro podcast. Sus roles han sido diversos: CTO, development manager y tech lead entre otros. Entre las cuestiones discutidas en el episodio: - ¿Cómo te metiste a la programación funcional? - Origen y características de Elm - Beneficios y diferencias de Elm - Desventajas de Elm - Frontend con Elm - Futuro, comunidad y recursos No te pierdas los otros episodios de la serie sobre programación funcional sobre Clojure, Elixir y Haskell. Todos los enlaces en nuestra web https://republicaweb.es/podcast/descubriendo-la-programacion-funcional-elm-con-david-hernandez/

Evan Czaplicki's talk The Life of a File.Richard Feldman's Frontend Masters Elm coursesExplore many different data modeling optionsMake Impossible States Impossible Elm Radio episodeWait until you feel the pain vs create abstractions before you need themDoes the code quality metric of line count apply in Elm since there's no spooky action at a distanceAim for loose coupling, high cohesionLocalized reasoningCore mechanics of Elm modules(Organize) Grouping functions values types(Hide) You can hide some of those things. Allows encapsulation, shielding from breaking changes, avoiding coupling.Create modules around domain conceptsUse ubiquitous languageGiant update functionsYou can think of the update function as a delegator - get things to the right place rather than doing the work itselfelm-reviewTCC (test && commit || revert)What are you gaining from extracting a module?Protecting invariantsHiding internalsDecouplingTDD helps drive module design.Experiment, but review your experiments before they become deeply ingrained.Pain in code is for sending a message.Technical debt isn't about "clean code". It's abstractions that serve what the code is doing. Abstractions are inherently expensive and a type of tech debt if they don't serve a purpose for your specific needs.Be proactive - immediately as soon as there is a clear way to make code better (not perfect, small improvement) - do itRelentless, Tiny Habitselm-test Elm Radio episodeTesting is helpful for identifying modules - see keystone testing habit blog postProperty based testing is a sign that something is a module - it has a clear property, which means you want to protect the internalsIt's okay to get it wrong, just don't get it all wrong up front with premature abstractions.

Was ist das Besondere an der Programmiersprache Elm? In Folge 60 haben wir Jonas Coch eingeladen uns mehr über die einsteigerfreundliche Sprache für funktionale Programmierung zu erzählen. Jonas ist Front-End-Entwickler bei itravel und arbeitet in Vollzeit und bereits jahrelang mit Elm. Die von Evan Czaplicki aus einer Abschlussarbeit entstandene Programmiersprache zeichnet sich besonders dadurch aus, dass sie zu JavaScript kompiliert ohne Runtime-Exceptions zu erzeugen. Das ist der wohl größte Vorteil von Elms strikten Typsystem. Noch dazu ist die Sprache unschlagbar schnell, da sie eine eigene virtuelle DOM-Implementierung besitzt, die auf Einfachheit und Geschwindigkeit optimiert ist. Insbesondere im Vergleich zu anderen großen Frameworks wie Angular und React tritt hiermit ihre zeitliche Effizienz in den Vordergrund. Mit der JavaScript-Welt kann über Ports kommuniziert werden, was einen Austausch einzelner Elemente eines bestehenden Projekts ermöglicht. Im Livestream sprachen wir außerdem einen Artikel von Stefan Krause an, der die Performance verschiedener Front-End-Frameworks vergleicht.Jonas ist als @klaftertief auf Twitter unterwegs! Picks of the Day Jonas: Den parceljs.org Module Bundler hat Jonas in der Folge besprochen und kann ihn empfehlen. MDN web docs – Auf der Lernplattform des Mozilla Developer Network gibt es zusammengefasste Grundlagen für Web-Technologien. Fabi: Dan Abramovs mental models über JavaScript – In diesem 5-Minuten-Newsletter stellt Dan die grundlegenden Konzepte von JavaScript auf die Probe und regt zu neuen Gedanken an. Dennis: Krisp ist eine Noise Cancelling App für alle Videochat-Programme, die für ruhige Konversationen aus dem Home Office sorgt – selbst mit Hund oder Kind im Hintergrund. Streamt uns! Die nächste Live-Folge nehmen wir am Mittwoch, den 6. Mai, um 18 Uhr auf. Seid dabei und bringt eure Fragen und Anregungen ein! Auch auf unserer Webseite erhaltet ihr mehr Informationen dazu. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback. podcast@programmier.bar Folgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. Twitter Instagram Facebook Meetup Musik: Hanimo

Chris is joined by Devon Zuegel who recently joined GitHub in the new Open Source Product Manager role. Devon and Chris discuss the complexities inherent to open source including funding models, managing motivation and burnout, different open source models, and end with a discussion around how we can be better open source citizens, both as consumers and maintainers. Devon on Twitter Devon's Blog Nadia Eghbal - Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure Patreon Sindre Sorhus on Patreon Open Collective ESLint on Open Collective Webpack on Open Collective Babel on Open Collective Sidekiq Pro GraphQL Pro GitHub related issues Clojure Rich Hickey Elm Evan Czaplicki Matz replies to post around Ruby moving slowly Open Source Maintainers Group on GitHub Thank you to CircleCI for sponsoring this episode.

Sponsors Kendo UI Sentry use the code “devchat” for $100 credit Clubhouse CacheFly Panel Joe Eames Aimee Knight Joined by special guest: Richard Feldman Episode Summary In this episode of JavaScript Jabber, Richard Feldman, primarily known for his work in Elm, the author of “Elm in Action” and Head of Technology at NoRedInk, talks about Elm 0.19 and the new features introduced in it. He explains how the development work is distributed between the Elm creator – Evan Czaplicki and the other members of the community and discusses the challenges on the way to Elm 1.0. Richard also shares some educational materials for listeners interested in learning Elm and gives details on Elm conferences around the world touching on the topic of having diversity among the speakers. He finally discusses some exciting things about Elm which would encourage developers to work with it. Links Elm in Action Frontend Masters – Introduction to Elm Frontend Masters – Advanced Elm Small Assets without the Headache Elm Guide ElmBridge San Francisco Renee Balmert Picks Aimee Knight: Most lives are lived by default Joe Eames: Thinkster Richard Feldman: Framework Summit 2018 – Keynote speech Nix Package Manager A Philosophy of Software Design

Sponsors Kendo UI Sentry use the code “devchat” for $100 credit Clubhouse CacheFly Panel Joe Eames Aimee Knight Joined by special guest: Richard Feldman Episode Summary In this episode of JavaScript Jabber, Richard Feldman, primarily known for his work in Elm, the author of “Elm in Action” and Head of Technology at NoRedInk, talks about Elm 0.19 and the new features introduced in it. He explains how the development work is distributed between the Elm creator – Evan Czaplicki and the other members of the community and discusses the challenges on the way to Elm 1.0. Richard also shares some educational materials for listeners interested in learning Elm and gives details on Elm conferences around the world touching on the topic of having diversity among the speakers. He finally discusses some exciting things about Elm which would encourage developers to work with it. Links Elm in Action Frontend Masters – Introduction to Elm Frontend Masters – Advanced Elm Small Assets without the Headache Elm Guide ElmBridge San Francisco Renee Balmert Picks Aimee Knight: Most lives are lived by default Joe Eames: Thinkster Richard Feldman: Framework Summit 2018 – Keynote speech Nix Package Manager A Philosophy of Software Design

Panel: Charles Max Wood Eric Berry Josh Adams Mark Erikson Special Guests: Claudio Ortolina In this episode of Elixir Mix, the panel talks to Claudio Ortolina about Process and OTP pitfalls. Claudio works for Erlang Solutions where he is a developer consultant, working with customers on long projects, and he has been working full-time with Elixir for the past 3 years. They talk about OTP, the importance of reading the sources when working with Elixir, and if beginners should dive right away into OTP. They also touch on Process, how Elixir allows your code to be more available, and more! In particular, we dive pretty deep on: Claudio intro Works at Erlang Solutions Ruby Rogues Episode 208 Is there one thing that stands out to you as the easiest thing to fix? People pick up this language quickly Repetition Excited about OTP Pattern matching People come from Ruby background to Elixir How do you address people who won’t put the effort in to learn OTP Rare to find greenfield projects now Building blocks Reading the sources Do you recommend beginner dive into OTP or should they postpone getting into it? It’s okay to postpone The missing link Is the domain model inherently concurrent? Concurrency is not always an obvious tool Elixir Process Thinking about what needs to work no matter how your infrastructure is affected by problems Elixir gives you a lot of tools to make your code more available Elixir syntax And much, much more! Links: Erlang Solutions Elixir Ruby Rogues Episode 208 Ruby Elixir Process @cloud8421 Claudio’s GitHub Sponsors: Digital Ocean Picks: Charles Home Depot Tool Rental Podcast Movement Framework Summit Josh Evan Czaplicki talk at Elm Europe Brian Hicks talk at Elm Europe Elm Europe Talks Mark Absinthe Library Claudio Code Elixir London YouTube Channel to help animals

Panel: Charles Max Wood Eric Berry Josh Adams Mark Erikson Special Guests: Claudio Ortolina In this episode of Elixir Mix, the panel talks to Claudio Ortolina about Process and OTP pitfalls. Claudio works for Erlang Solutions where he is a developer consultant, working with customers on long projects, and he has been working full-time with Elixir for the past 3 years. They talk about OTP, the importance of reading the sources when working with Elixir, and if beginners should dive right away into OTP. They also touch on Process, how Elixir allows your code to be more available, and more! In particular, we dive pretty deep on: Claudio intro Works at Erlang Solutions Ruby Rogues Episode 208 Is there one thing that stands out to you as the easiest thing to fix? People pick up this language quickly Repetition Excited about OTP Pattern matching People come from Ruby background to Elixir How do you address people who won’t put the effort in to learn OTP Rare to find greenfield projects now Building blocks Reading the sources Do you recommend beginner dive into OTP or should they postpone getting into it? It’s okay to postpone The missing link Is the domain model inherently concurrent? Concurrency is not always an obvious tool Elixir Process Thinking about what needs to work no matter how your infrastructure is affected by problems Elixir gives you a lot of tools to make your code more available Elixir syntax And much, much more! Links: Erlang Solutions Elixir Ruby Rogues Episode 208 Ruby Elixir Process @cloud8421 Claudio’s GitHub Sponsors: Digital Ocean Picks: Charles Home Depot Tool Rental Podcast Movement Framework Summit Josh Evan Czaplicki talk at Elm Europe Brian Hicks talk at Elm Europe Elm Europe Talks Mark Absinthe Library Claudio Code Elixir London YouTube Channel to help animals

Correl Roush is back to talk about Elm. Show Notes: This is Correl's second episode. Be sure to check out the Erlang episode Elm website Haskell site Evan Czaplicki on Github Book: Seven More Languages in Seven Weeks No Red Ink Richard Feldman on Github Text editors mentions: Atom, Emacs Elm-package command line tool Book: Elm in Action by Richard Feldman Elm slack channel Video: Time traveling debugger with a Mario platforming game Correl Roush is on Twitter. Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Music is by Joe Ferg, check out more music on JoeFerg.com!

Philip Poots @pootsbook | GitHub Show Notes: 00:53 - What is Elm? 03:45 - The Essence of User Interface 07:59 - “Messages” 08:31 - Scalability 14:04 - Error Handling 18:47 - The Business Case 22:35 - Where is Elm on the curve of scalability? 28:36 - Learning From Elm 32:32 - “Whole Meal Solutions” Resources: Philip Poots: Elmber @ Wicked Good Ember 2016 Cycle.js Functional Reactive Programming Evan Czaplicki Test-driven Development (TDD) NoRedInk The Elm Mailing List Try Elm Elm Guide elmtutorial.org Elm For Beginners by James Moore Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 56. I am Charles Lowell, a developer here at The Frontside. With me is Jeffrey Cherewaty, also a developer here at The Frontside. JEFFREY: Hey-o! CHARLES: We're going to be talking today with Philip Poots, who is a fantastic individual, who I have known over the Twitters, over the e-mails, interacted with at conferences, seen him speak on at least one occasion and today we're actually going to be talking about the thing that I saw him speak at Wicked Good Ember last June. It was actually one of my favorite talks from that conference. It was on Elm for Ember developers. Thank you very much for being on the show, Philip. Why don't you tell us a little bit about what Elm is and how you came to find out about it and really kind of dive deeply into it? PHILIP: Yeah, sure. First of all, pleasure to be on the show. The Frontside is one of my favorite podcast, if not my favorite, given a cross-section of the Dadcast, the love of programming and balancing that with the business of programming. That's right, I'm an independent developer. I started off with Rails then got into the Ember quite early on. Last year, I think around January, that's when I started really investigating Elm in detail. It's actually a funny story how I came about because I was at Ember Amsterdam and it was a night where we had three members of the core team: we had Erik Bryn, he gave a talk, Alex Matchneer, gave a talk and Igor also came over because he's based in Europe. Alex always loves to investigate new things and one of the things he was getting into was Observables. I'd never heard about Observables at all so after the talk, I kind of pulled him aside and I asked him some very stupid questions. He was gracious enough to bear with me and to dive a little deeper into this stuff. Alex is kind of a quiet member of the core team, unless he's got his drum sticks but he's the guy that rewrote the [inaudible]. That was no mean feat because I got into Ember just before that moment and the way he managed to make that incredibly easy was fantastic so I kind of had an extra ear open to what he had to say. I went on this Observables talk. You know, you start off with React that was the framework that was using Observables the most. That brought me to Cycle.js -- CHARLES: Cycle.js? I haven't heard of that. Is Cycle.js a framework built on top of Observables? PHILIP: It is. There's a guy called André Staltz or André Medeiros but he uses Staltz as his name. It's largely based off the same principles as React. Cycle, basically one of his inspirations or at least one of the things which cycle is most like was the Elm architecture. He calls it Model-View-Intent. We have Model-View-Controller and Elm was model update view but essentially, the same principles. You know, I'm the kind of guy that likes to get stuck in, to go deep and where I started with Observables then I ended up at Elm. I started playing around with that, I started looking into it and I loved what I saw. The thing above all that really attracted me to it was the pure simplicity of what was going on. It was almost like they boiled down the UI paradigm to its essence and removed all the extra cruft and you just saw what you meant what you wanted and it gave you these, what I thought at the time, composable way to put things together. CHARLES: Can we unpack that just a little bit? I really love that idea of it boiled down to the essence of UI. I assume there are certain coordinating mechanisms that Elm employs. It's interesting to hear you say that Cycle.js has used Elm as an inspiration. I also understand that Redux is inspired also by the Elm architecture. I'm very curious, what are those kind of essential mechanics that drew your attention? PHILIP: I think you can look at it from two points of view. The first is, which I didn't actually learn until later but the first is essentially boiling down functional programming. You're decoupled, you're using functions and not only functional programming and there's a lot of arguments over this term but functional reactive programming. The idea of functional programming is stateless. Therefore, time is kind of the beast that you have to deal with. But FRP, then essentially boils time into the concept of values that can change over time so you have a reference to one value but in JavaScript that's an Observable. In Elm, in the beginning, when I was getting into it, that was signals. That's not all kind of hidden underneath so you don't really need to get over that conceptual hurdle anymore. Then the boiling down to the essence, I guess that's more from a code point of view with Ember. Especially at the beginning, there were a ton of different concepts that were thrown at you to begin with. It was billed as an MVC framework. It was sold as an MVC framework but you had helpers in there, you had components, you had views model controller. You had this cluster of things. You could see MVC in there but there were enough things surrounding it to kind of think, "Where does this piece of code go? Where does that piece of code go? Where should I do this?" CHARLES: There are a lot of blog posts trying to explain what exactly is the view, is the template the view? Is the controller the view? What's the difference between a view and a controller? PHILIP: The way I think about frameworks is they give you buckets to put your code. The buckets are kind of all connected together. I'm thinking at a really simplistic level. I need to write this feature, I need this bit of code, I need this bit of logic, where do I stick it? A framework says you should stick it here or you should stick it there. It's solves the need of having to think about the broader architecture and how things interact because those things have been solved for you. Now with Elm, it was just so straightforward to say, "This goes here: all the data, the model. It lives in this record, which is equivalent to a JavaScript object, we can say on a simple level. Anything you need to do with state, happens there. Then you've got the view and the view is simply a function, which takes that data structure and then you tell it how to render it to HTML and then all of the action, everything that happens in your application is also defined in one place in your update function. That's it, like no more than you need and no less than you need. CHARLES: Yeah, I love that. I feel like it is very much as 'data down, actions up' kind of boiled down to the essence. It's almost better at that paradigm than Ember is in itself, with having your view as just a function. Your state transition or your update is just a function. Then your model is just unadorned data. That's all it is. PHILIP: The type system as well in Elm, also made it really straightforward. My model is a record. That's it. My view is HTML in the beginning but then it moves to HTML, which contains messages. Essentially, I've got HTML and in the HTML, there are events or actions and those actions will send messages and really straight forward. Then the update function, I take in the current model, I take in the message and I decide via pattern matching what I want to do. There are a few extra bits and pieces around there but that's the essence of it. CHARLES: Now, when you say messages, I'm thinking this is a way of declaring what actions you will take when certain HTML elements, like events happen, like you declaratively mapping an event to the dispatch of an action. PHILIP: That's correct, with any extra data so a message is itself. Like the actions hash in Ember essentially and along with the parameters for that action, which would passing through the HTML. CHARLES: Some might argue that if something is simple to get something working, I can have a pure function that's a view, I can have a simple data structure which is my model. I can have a pure function which is my update or my state transition, how I change my data or affect changes to the model. Some might say, "That's very simple," but simple is great for simple cases. But then there's the question of scalability. As my application becomes more complex and has the interactions become more complex, does that simple paradigm actually scale? What has been your experience there? PHILIP: Straightforward answer -- it's a learning curve to scale. Why? Because it's so new and also because the things that you would have reached for in the past aren't available to you. When I think of Ember scaling, the scale is built into the framework. You need another component, you just add another component. You need another model, you add another model. There's a clear story or there's a clear way that you deliver a new feature. I think that's a fantastic aspect of Ember that you also say no. I can remember being at Wicked Good Ember and just realizing how many of the people that were speaking and how many of the people that I was talking to work for bigger companies -- Heroku Dashboard, you had LinkedIn and the fact that Ember scales across a large team size, it's a real testament to Ember, which is slightly different for the reason why I got into Ember. Also you know I had a few issues just on a side project with a friend, the pace of Elm's change meant that when you only have a limited time to devote to the project, then you don't want to be spending that time for going out where you should be in terms of the upgrade process, etcetera. That's a known path and I think that's a really clear advantage of Ember over Elm. The path in Elm is not as well-fleshed out and there's a bit of tension between Elm as a single page application and then Elm as an application that you stick on every page of your server generated app, for example. The main people who use Elm NoRedInk could employ Evan Czaplicki, the creator of Elm, there up at the minute is a Rails up. I think in Elm up for every page, I believe that certainly was the case, whether that's [inaudible], I don't know. It's not an area where it's like here's the path, go for it because the scalability of Elm, everyone came into Elm thinking, "I know react. I know Ember, the components system, 'data down, actions up'," and in React, you're really encouraged to make a component for the smallest thing on the page as a component. Then you have container components, you make your way out of the onion skin and hope you don't cry on the way. [Laughter] PHILIP: But the thing about Elm was everyone jumped in and tried to do it this way. I certainly got the impression when I was beginning that the Elm architecture was infinitely Nestable Russian dolls. It is in a way but the difficulty is then passing into component communication between parent and child and people had been figuring it on a weird ways with signals to do it but then became obsolete. The main encouragement is basically go so far with a single component that you can and then once you had problems, try not to create new components or new bits of UI but to extract the bits you need into modules. This is actually one of the things that really attracted me to Elm is that you're encouraged to lean on your programming skill set, rather than learning a whole new frameworks way of doing things so that the things that work in functional programming will work in Elm. But that's also a down side because all of a sudden, you have to exercise your programming chops. Let's be honest, a lot of the stuff we're building we're like gluing things together. We're not thinking up new architectures or ways of doing things. That's definitely a learning curve and that's definitely a struggle or something that I find difficult. CHARLES: Yeah, I feel like that touches a lot on the messages you get from the FP community. I know certainly in the interactions I've had with the Clojure community, they're very big on that and it's like, "Let's have very powerful primitives." They have that term 'decomplecting', like let's get at the core. It's like understand that essence so if we can compose and we can enable composition of these low level functions and allow you to compose the data, then you don't have to worry so much about everything else. There will be a way. I think the counterpoint to that is that you end up with a lot of different ways because there are a lot of different ways that you can compose a very small set of primitives. PHILIP: Yes, that's right. But I think one of the advantages of Elm over maybe other FP languages and this is where the similarity with Ember comes in as well. It tries very much to cement simple convention but not only by convention but actually baked into the language so people that are coming from more powerful functional programming languages often come to Elm and think, "Why can't I do that? Why do I have to write all this boilerplate code," and the reason is because then it's not going to be simple enough anymore for people to use it. Also the goal of Elm, which is this long term maintainability of large code bases, you kind of shoot yourself in the foot a bit just like you said, Charles. CHARLES: Yeah, I think that's actually a great point. It's actually one of the things that was most memorable, I think about your talk at Wicked Good was -- just a quick anecdote. I remember in 2007, when iPhone came out, I had an iPhone and my father in law came over from Finland and this is a guy who was a Nokia partisan. I mean, part of Finnish pride was everybody own -- JEFFREY: National phone of Finland. CHARLES: Yeah, exactly. Everybody owned the Nokia mobile phone. He came over, He visited me and I had an iPhone and he was like, "Can I see it?" He took it, he had the swipe to unlock and he swiped it and it unlocked and all the app icons just kind of came right into the screen and he was like, "I want one." [Laughter] CHARLES: That was all it took. I've never seen a sales process so utterly complete and so rapid in its realization. For me, I think that moment when I saw you talk was when you made a mistake like where you were trying to match against an improper attribute on the model inside the update function. The first thing that happened was that Elm caught it before you could even compile your program and the error was just beautiful. It put its finger right on and it's like you need to fix this right here so there's much tied up into that because I feel like it addresses a lot of the learning curve problems that we have in Ember. PHILIP: I don't think that's Ember specific -- CHARLES: No, it's not, it's -- PHILIP: That's the JavaScript thing, isn't it? CHARLES: Yeah. PHILIP: In many ways, I think of JavaScript as a very low level substrate. It's like sand, it's very granular and it's very hard to put together well without falling apart, whereas in Elm gives you bigger blocks, so to speak but it also defines a way through the type system where if you don't put those blocks together in the right way, it's going to tell you. That's why despite some of the ignorance of how best to do Elm apps, that's why people continue to use it because it gives them this delightful experience. CHARLES: Yeah, it was fantastic where when you fail, it picks you up, dust you off and sets you right back on the right track. I think one, that's just a freaking awesome feature and I think also two, the thing that struck me when I saw that was like, "Wow, this community has a different focus than other FP communities that I've come into contact with because I have encountered that exact same error message in Haskell and it left me puzzling and wondering what to do. It's like, "No instance for type class blah-blah-blah for class blah." Then if you're an experienced Haskeller, it does point right to the problem in the same way that like you've learn the parse Perl stack traces. You know, you see a Perl stack trace and you understand it. But they could have gone that way with Elm but the other thing that it demonstrated, it has kind of a different focus there. PHILIP: Absolutely and that really comes down to Evan Czaplicki, the creator of Elm. I was able to get over to London in October a couple of years ago or a year and a half ago now to do a workshop with him at the Code Mesh Conference. You know, just seeing him teach this stuff and saying go into this and talk about the things in a bit more detail, it was very clear. First of all that he'd had a negative experience picking up Haskell, I think it was and he just thought, it doesn't have to be this hard. The things aren't actually that hard. It's the way that we're explaining them that makes it hard. The things that are actually under the surface is really simple. He has a blanket ban on this kind of technical jargon. In the Elm community, he prefers to get things really straightforward names. I think he said to me that one of his thesis advisors or his university professor said, "Evan, that's what you get when you put a usability specialist into a programming language creator's shoes," that he does have this focus where he understands the benefits of static-type systems but he also deeply cares about the experience of not only picking up the language and learning it but also the day you solve it and that's something that just shines through. I think even if Elm never makes it into the pantheon of great programming languages like that in itself and the influence of that had already on other communities, this is fantastic. It's the tide that lifts all boats in many ways and we all benefit from that. JEFFREY: We kind of touch on this a little bit earlier. We've been talking about the ergonomics of being an engineer working with Elm or Ember. What about the business case? We've mentioned how Ember has prevent a scale fairly well in large organizations. What's Elm's path to being able to do that and where is the niche to that it fits in right now? PHILIP: I definitely think Ember comes out of Apple, I believe with sprite core. That's where it started and it's interesting to see that that's also where it's gone in terms of the focuses and making it easy to build these rich applications. I think also that Elm has a similar genesis in the sense that Evan, I believe he did an internship at Microsoft and one at Google and I think there's a conference talk as well from large JS or elm lock or something, millions of lines of code. It's definitely gunning for the CM area which is applications which are large and hairy and trying to make the maintainability a lot better by bringing the strengths of the static type system to bear and bring the simplicity that that enables. That means that the learning curve maybe is a little sharper at the beginning, in a similar way, also that Ember was and is. But then you should reach this point where the maintainability of the app outweighs the time spent in learning. I think about it a bit like test driven development. I remember back when I was doing Rails and DHH had baked TDD into the Rails itself and there was the years of the testing discussions whether to test all the time, test everything, 100% coverage or even full circle tests are a waste of time. but it's a similar philosophy in that if the tests are doing what they should be doing, which is giving you great feedback, the time it takes to get up to speed in testing, the time it takes to set up testing, the time it takes to write the tests, they pay off further down the line and that's not music to the ears of the people who want to get something into production immediately. But it's definitely music to the ears of people who will be spending a long time on maintenance in an application. That NoRedInk application is huge. They have millions of users. They've build software for teaching grammar and skills in the US and they talk all the time about the benefits of Elm. Mainly, in the sense of confidence, I have the confidence to go in and change this code. All of bits or majorities of our code bits, which are things that we've rather not like to touch. We kind of section them off. If a feature request comes in and instead of saying, "Yeah, we can do that," you try and slowly push it out the door. Elm is supposed to give you then the confidence to be able to go to any part of your code base and to change it without the fear that you're going to break something or break everything because the type system, the compiler will tell you, "You change this type, you change the signature of this function, here's where it's broken and as soon as you fix the compiler errors, functionally it works, you'd probably have a few tests to test the actual business logic of it." Probably not so with technical stuff but it's a huge time saver. That's where we want to be as developers and our relationship with our tools. We don't want to be fearing our tools. We don't want to be anxious every time we open our editor. We don't want to fear the feature requests coming in. We want to be in control of our environment and we want to be able to deliver the business value. I think that's certainly the promise of Elm. That's certainly where it wants to be. CHARLES: I love that. It sounds like that is where they want to shoot for is these big applications and they do want to scale massively. Let me ask the question then. Where is Elm do you think right now today on that curve of scalability? PHILIP: To put it in Ember terms, that's maybe the best way I can describe it. If anyone remembers the early days of Ember, I definitely feel that they're in 0.9 approaching one rather than later than that. One of the things as well, I think it's important to note is that Evan is not rushed. It just blew my mind when I heard him speak about it and it wasn't anything big or anything but just the whole kind of tenor of the conversation of the way he was teaching of how he was talking about Elm was so in contrast to the JavaScript type machine. In contrast to a new framework every month, he was like, "If Elm is going to be around in 10 years, then this is the decision that I'm going to make." In that sense, where is Elm in that journey. I'd say it's still pretty early on. I'd say also, Evan is really focused on use cases so if there's not a use case for something, there's no reason to add it. This is actually quite frustrating maybe for people who are coming out of JavaScript ecosystem and they think of a feature that they want and they submit a pull request and it just gets closed or it get set, is there use case for this? Why do you need it? Is this generalizable to everyone? Will it make sense to add this to the language? Can you do it in a library? Then figured out later, can you do it in JavaScript with port, instead of having to bring it into Elm? He's definitely building it very slowly but that may sound like a down side right now but the upside is we're going to come up with something at the end, hopefully that is battle-tested, that fits the use case and a good example of that was the URL handling at the navigation. It didn't live in Elm. Do we actually need it because he's building single page applications? Can you give me your experiences? There are a couple of libraries also built. Then the things from those libraries were then taken a little bit like Ember as well, where you use the add-on ecosystem to try new things and then things may get brought into core or make it kind of the official stamp of approval. But it's a lot slower and not as committee-based. Evan is the benevolent dictator for life. CHARLES: I really like that approach. I don't withhold my opinion from the benevolent dictator versus kind of the oligarchy that you see elsewhere. But I was thinking as you were describing it that maybe the framework really, and this is me, I'm kind of a little bit of a tree nerd, mostly in and around the trees that grow in central Texas but I love trees. Unfortunately, it sounds like oak or maybe redwood would have been like a more appropriate name because those are very slow growing, have a very hard wood, whereas in Elm, it's actually fairly short lived and has a softer wood. JEFFREY: And you also don't want cedar because that will come back and bite you -- highly allergic and toxic to humans. [Laughter] CHARLES: Right. Named Elm but slow growing hardwood that you can build a house out of. But I like that. It's so important to get things right the first time because that's where you realize exponential gains. Unfortunately, there is no substitute for exponential gains, rather than deep thought. At least that's been my experience. You can realize gigantic short term gains with taking cut corners but in terms of long term exponential, ultimately those will taper off. PHILIP: I think as well, what we've seen in Ember's experience is the decisions that you take to open up a private API or not to make something private. They limit you because all of a sudden, everyone starts using those APIs. A year down the line, you realize, "Oh, hang on. We don't want to design it in this way. We want to do it in that way," but given the commitment that Ember has to stability, you have to deal with that. Sometimes, the dealing with that actually takes more energy, more time, more effort in education, in actual code, in maintaining two branches, all of that kind of stuff then actually takes away from the time that you could have had to think up better solutions and it's a danger, you know? It's almost like as soon as you throw this into the water that it becomes firm. As soon as you throw it into the crowd, the crowd will take it and they will use it and your chance to change it or mold it will have gone. Evan talks a lot with language designers and at least I got that impression that he opens up channels of communication with people who've done this before and he thinks very deeply. He's not closed off to the idea of adding more powerful features to Elm but he would only do it when it's right to do it. It's not just is this feature right but is this the right time for this feature? That as well is just the kind of mind blowing like who thinks about this stuff, who cares about this stuff? CHARLES: Yeah, because certain features become accessible once other features are in place. I feel like it would have been as feasible to have an entire compiled language as an acceptable option before people started transpiling CoffeeScript and then with Babel, transpiling future versions of JavaScript back into JavaScript. If those intermediate steps happened, if CoffeeScript and Babel would have happened, would people be as receptive to things like Elm or things like PureScript? it's definitely there is kind of the zeitgeist of the development community really informs what features are even possible or appropriate tomorrow, even though they might have some ejectively sound qualities out to them. JEFFREY: They want to make sure they're not too far ahead of their time. CHARLES: Right, exactly. Folks got to be ready for it. Then the other thing that I wanted to ask was given the trajectory of where Elm is, some people are using it in production. You said it was around like a 0.9, 1.0. if we are actually quite happy with our current code bases, whether we're using Ember, whether using React, whether using some other framework, what are things that you can learn from Elm that you can bring home with you to your own town, wherever that is to use and make your own life better, as you develop code, to kind of increase that confidence, as you say? PHILIP: This is very relevant to my suggestion because in the past couple of months, I haven't had a chance to do any Elm but what I find is after kind of my deep dive, I've come out the other end and I feel like I've come out a better programmer. I feel like Elm is simple enough conceptually to learn quicker, faster, at least the basics more than maybe even to JavaScript framework. I think that the things that you will learn in that process are tremendously beneficial, even if you don't ever end up using Elm in a professional capacity. The thing I think that grabbed me most is because of the way the type system is, you have to deal with every error and this is something when writing Ruby or when writing Ember, you always focus on the happy path. Then once you've got the happy path in place, often the business will say, "That's done. Let's move on." Your better instincts say, "No, we haven't actually made this robust enough." But sometimes the value is also not the great in kind of shoring up all those cases. But what Elm does because of the way it's build is it forces you to deal with failure. The classic no runtime errors in production, the reason that is it may have taken you a bit longer to write your code in Elm. But you come out of it with a confidence that if something explodes, it's either something incredibly rare or it was JavaScript and not Elm. Just the forcing like, "How can I think better about how this code can fail," means a bit of extra mental effort when you do it in a language that's not Elm but it's definitely something that's worth doing, if you want to build good software. Another thing related to the failure stuff is maybe the idea of what's called an abstract data type or a union type or an enum, like the fact that you can encode different states in one object, that you deal with all of those states in a cohesive way. One of the things actually, I think it was Jack Franklin of JavaScript Playground who brought this back from Elm into Java Script was when you have a screen, you want to load some data via Ajax or Fetch, instead of just loading the page, sending off the request, getting the request back, deciding what to do with it, it's like, "Why don't we encode those states in our code." We have the waiting state, we have the find state but we have find but it was an error, we have find and it worked, we have find and it actually has no values. Instead of just dealing with those on the fly, if statements like why don't you create an object that encodes the states that your UI can be in and then you react and the UI will know what to do and you write the code to do that. But in some ways, at least to me that's a lot better than kind of hit and hope when we got an error. That's, "If do this, if do that, let's nest some callbacks or let's chance some promises." The sheer act of taking a step back and this is something Elm forces you to do because the way it is, like thinking about the domain and thinking about how best to model the domain. To be honest, it's probably just good programming practice but how often do we not do it? CHARLES: Absolutely. It seems so obvious, except it's only obvious when you're put into a system that you can't slide on it. What you're describing reminds me of this concept that I came across in the Haskell community. They talk about wholemeal solutions versus piecemeal solutions. Most of the time, they talk about wholemeal solutions as kind of finding the most general set of abstractions that solve a problem for all cases. But I hadn't applied it to this concept of that all the potential states kind of envisioning your application. As you execute your code, you'll only come across one state of the time but kind of thinking of your code as all of these sort of quantum states of your application existing at once and you need to account for them all and draw that whole picture. PHILIP: This is a really stupid analogy but I don't know if anyone's played Age of Empires or any other kind of war-based game where you have a map, you've got the fog of war and you can only see a few meters around you and you have to send out your scouts and you need to find them -- CHARLES: Yeah, yeah. PHILIP: -- Different tactics. You shore up your base and you concentrate on where you are, you send your scouts into the far ends of the map. In terms of seeking out of the unknown, I feel like Elm forces you to know the map where is when I'm programming in JavaScript or in Ruby, it's more like, "I'm here. I need to do this. I do it," and you don't necessarily force yourself to think of all the potential states or all the potential things that can happen, the events that can happen, whereas with Elm, if you don't have those, then it will tell you that those things in place. [Laughter] CHARLES: Yeah, I love that analogy. Like actually sent out your scouts to know the map. PHILIP: Yep and I think as a person, and this is maybe why it appeals to me it's like I like the feeling that I haven't left a stone unturned. I like shipping something that I'm confident in and I know it won't bite me or if it does bite me, it's purely because it was an unknown-unknown. It's like doing your due diligence. As I'm saying this, Elm is not the silver bullet. Elm is not the panacea. Elm will not solve all of your problems. But speaking in terms of contrast with JavaScript or Ruby and more dynamic languages than Elm, these are the things that happen. I think that kind of leads me on to another point which is Evan in the mailing list conversations and the decisions that he takes with Elm, I don't know if this are stages of maturity as a developer but you find your tool, you love it, it's the only thing that can do the job and then you realize other people are doing jobs pretty well, doing their other stuff, I guess each to their own. But I feel like there's another stage where it's like what are the tradeoffs involved in taking this decision or using this tool and what are the tradeoffs involved in taking this decision or using that tool. Just the way of thinking in terms of tradeoffs, instead of absolutes I find really, really valuable and that's definitely something that I've been able to apply and what are the benefits of this decision. Not only from a code point of view but from an organizational point of view, from a team point of view, from a long term point of view, from a short term point of view, having a wider arena to make those decisions, it has been really helpful for me, valuable on both side of them. CHARLES: I can see it. I believe you and I think we're coming to the end of our time here, I think I'm going to make the same recommendation that I made to everybody last week when we were talking with Toran about Redux and that is you should go out and you should try Elm. It's really easy to get started and it will guide you. The guides are excellent. The air handling is excellent and yes it is quirky and weird but it supports you. There's going to be some big functional programming boulders thrown at you but it gives you a [inaudible] to deal with them. JEFFREY: I think you need a suit of armor so we can stick with the Age of Empires metaphors. [Laughter] CHARLES: Yeah. Go out there, try it and experience the things that Philip is talking about because I feel like they are very real and they will have a good effect on you, whatever it is that you do the next day or the next week or the next month. PHILIP: They'll challenge the way you think, they'll give you new perspective and they'll give you a good counterpoint as well. You know, elm is not for everyone but only if you try it will you understand that. I think that's one of Evan and everyone in the Elm community is try it yourself. I'm not going to say Elm is right for you, Elm is right for your business. Rewrite everything in Elm, not at all, try it out, try it on a side project, try it to just having fun hacking around. If you do want to make the jump to using it in your company or whatever, don't take a decision to rewrite everything. Take one very small part of your app and do it in Elm and see how it goes. If you don't like it, you can take it out. If it works, you can build another small thing. This kind of gradual approach were far too quick to jump on a bandwagon: trash the old thing, do the new thing. Especially now, when we are building applications that are going to be maintained, when we are building applications that are going to be around for a few years, it's also just not feasible and sometimes it's not right. You just got to make that decision maturely rather than I want to use this or I want to use that, which can be tough. But ultimately, you want to deliver the value. Try Elm at Elm-lang.org/Try. You can try on the browser and see how you go. The official guide is really good. There's also Elm-Tutorial.org, which is kind of a complement to the official guide. Pragmatic Studio have released recently an updated course for learning Elm. James Moore at KnowThen.com. He has a couple of Elm courses, one is free introductory and then there's a paid course, which goes into deeper topics, whether text or whether video, whatever your thing is, there's resources available to get you to the point where you'll be able to make a decent decision. CHARLES: Well, fantastic. I'm certainly excited. I haven't dip my toes in Elm for a while and I'm actually, after this conversation pretty stoked to get it on again. I hope everybody else does. Thank you so much, Philip for coming on to the podcast. This was just a fantastic and enlightening conversation. PHILIP: Not at all. It's been an absolute pleasure. Thank you. CHARLES: All right. That's it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that is engineered to make your UX dreams come true.

Jamison Dance: @jergason | Blog | GitHub | Fivestack | Soft Skills Engineering Podcast | React Rally Show Notes: 00:58 - The Elm Programming Language 01:36 - Who should try Elm? What is the attraction? 03:09 - Scaling an App Across a Team; Conventions 06:19 - Routing 07:48 - Writing Tests 09:38 - Jumping Into Elm from a Component-based Framework 12:20 - Tooling 17:28 - Productivity 19:21 - The Elm Community 25:13 - Could Elm Replace JavaScript? 28:28 - Lessons Learned from Elm to Write Better JavaScript 33:45 - The Elm Syntax 35:49 - Checking Out New Languages and Communities 37:31 - Data Modeling Resources: Elm Packages elm-format Evan Czaplicki: Let's Be Mainstream! User-focused Design in Elm The Elm Guide Elm on Slack The Elm Tutorial Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 Transcript: ALEX: Hey, everybody. Welcome to The Frontside Podcast Episode 49. I am your host, Alex Ford, developer at The Frontside. With me as well is Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hi, everybody. I'm Chris. I'm also a developer at The Frontside. ALEX: We have a really special guest for today. I'm really excited. Jamison Dance is with us. JAMISON: Hello. ALEX: Jamison runs Fivestack Software Consulting Company, hosts Soft Skills Engineering Podcast, organizes React Rally Conf, and spells 'array.length' incorrectly sometimes. Is this true? JAMISON: It is true, yeah. I think I have a special ESLint plugin to yell at me now when I do that or something. But that has caused some pain in my life. CHRIS: Oh, that was very brave. Thank you. ALEX: We're going to be talking Elm today and writing better JavaScript with Elm. This is really exciting for me. I've gotten the chance to dive into the Elm tutorial a little bit, which is an absolutely beautiful tutorial if you haven't checked it out yet. JAMISON: Yeah, Elm is a programming language that runs in the browser and compiles down to JavaScript. It's a pure statically-typed programming language, which if that doesn't mean anything to you, don't worry. The take away for you is that Elm tries really hard to make it easy to write programs that don't crash and are easier to refactor and easier to work on and maintain, basically. CHRIS: And Elm is a language in of itself but it is pretty specifically intended for front-end development. Is that correct? JAMISON: Right now, there are some long term plans, but yeah. For now, it's front-end for building UIs and applications in the browser. ALEX: I heard about Elm. When should I check it out? Who do you see jumping into this language? JAMISON: I think it's aimed at people that want to build robust applications which is so vague, it sounds meaningless. Maybe I talk about what attracted me to it. The two things where I was interested in functional programming -- that's kind of like the technical language wonk, like geeky side of it. But the other side is I've worked for a while in some fairly large JavaScript applications and I've seen the nightmares that I can create for myself In just building something that works and is just really hard to work on. So the idea of a language that's focused on keeping your productivity high as the application skills and as the team skills was really attractive to me. Like the bio says, if I spell array.length wrong, sometimes I catch it, sometimes I don't, then my program breaks. Elm has a compiler that runs on all your code and basically, make sure that your code cannot crash. You could still have bugs and you can still just make your code do the wrong thing but it helps eliminate whole categories of errors. It just makes them impossible to create in Elm. If you're interested in functional programming or if you're interested in just building stuff that is easy to work with, like this kind of this curve of productivity over time where some environments and some languages start out really high, it's really easy to build something fast at the beginning and then maintaining it is just really hard so the productivity drops over time. Elm is trying to kind of flatten that out so your productivity stays high throughout the lifetime of your application. CHRIS: I actually have a question about that. I'm planning on bringing this up later but you gave me such a good segue that I feel compelled. You mentioned that one of the things that is nice about Elm-type system is that it helps scale an app, especially when it comes to a team. My experience there are kind of true different facets to what scaling an app across a team looks like. One is the categories of bugs that something like [inaudible] compiler helps you catch. But the other is, and this is totally coming from the fact that I use Ember every single day, that conventions also help scale across a team. I'm curious like what I've looked at with Elm, it looks like they definitely have the type system there and error messages there to help quite a bit. But I haven't seen conventions arising yet in terms of a lot of things, about how you build a front-end application. I'm curious, is it that those conventions are there and just haven't found them yet or they're still very much in development? Or is that not even really a goal for Elm in the same way that it might be nothing like Ember or Angular. JAMISON: You mentioned first the kinds of bugs that the compiler will help you catch. I want to talk about that really quickly. If people aren't familiar with what a compiler or type system will do at build time, it checks all of your code to make sure that all of the variables and inputs and outputs from functions match up. So you say this function takes in an 'int' and returns a string and it will go find everywhere that calls that function and make sure that they're always passing in an 'int' and return it, so that it always return a string. It kind of does that throughout the whole flow of the program. It eliminates those kind of areas where you just get the interface wrong. The program is huge. You don't remember all the inputs to a function so you just like passing an object when it expects a string or something and then later on it will explode. You don't get those errors with Elm which is the first kind of thing you're talking about. You mentioned that conventions and I'm not on the Elm core team or whatever. I don't have any special insight but my experience is Elm very much wants to create strong conventions around how you build applications. The Elm architecture is kind of a way to build front-end applications that is basically baked into the language. There isn't like a UI framework for Elm. It is Elm. That to me is a huge point on the strong convention side. There isn't like an Elm fatigue because there isn't a choice between a hundred different UI frameworks in Elm. Some patterns around how you build apps this small, I think are still being established but I think there are strong conventions already and the trend of the Elm community is towards picking strong conventions. You'll see Evan, the creator of the language, He'll talk about how he wants to have one really good library instead of 15 overlapping libraries of varying quality to solve the same problem. Elm has conventions already. The places where it doesn't have strong conventions are I think places that will get filled in but the goal is to pick up the language and you get everything you need to build an application attached to it that's all kind of figured out for you. CHRIS: It's been interesting you mentioned the thing about it's better to have one good library, rather than 15 libraries of varying quality. I've seen that a little bit in practice. One of the things that I started looking for pretty early on when I was messing with Elm was what client-side routing look like. There are a couple of different routing libraries. But if you look at them, you can see that they're actually kind of this progression, like you can see how they have built on each other and they're kind of like building up the stack of abstractions toward one final solution. It's very interesting because it's not like those other libraries that are still there. If you really wanted to use just a regular URL parser and build your own, you could. But you can also see this development towards something that anyone could take off the shelf and start using. JAMISON: Yeah, and Elm has been around, I think it was 2011 when it first started. But really, Elm as like a popular thing that people hear about and use in production is only a couple of year's old maybe. There are still some things that are evolving like that. I think you're right that they're evolving towards convention instead of, in my mind JavaScript values, the proliferation of tons of different ideas and just wild exploration. Elm seems like it values a little more consensus and aligning the community behind one solution. I think it's happening, if it's not there yet, it'll get there, I guess. ALEX: I have a question about writing test in Elm and how that feels different than writing tests in JavaScript because the way I find myself writing tests right now is I understand the language to be fragile and I understand some frameworks have some fragility because of that language so I find myself writing really strong tests that are easy to break. I imagine that maybe in Elm, that's a little bit different with this very strong convention that you're talking about. JAMISON: Yes, some of it is around not having to be as defensive in your testing. If you wanted to get really, really down in the nitty-gritty in JavaScript, there are just an incredible array of different inputs you would have to test to make sure someone doesn't pass in like [inaudible] to this function where you think it's an array or whatever, like you just don't have to write any of those tests because the compiler catches that. We haven't talked about purity at all and this concept in functional programming where your functions can't cause side effects. They can't just go make a network request or write to disc or console.log like right in the middle. The functions take an input and return an output. You can do that in JavaScript. You can write your functions that way but because that feature is built into the language, it's the only way to write functions in Elm which makes it really easy to test functions because you just pass them stuff and you check what they return. In my experience, that makes them easier to test. You still build UIs and you still make network requests so you still construct some HTML at some point in your program. You can if you want to test that the HTML looks right or that elements have certain classes and stuff. But I guess what I'm saying is the tests feel like they're testing the behavior more than the edge cases when I write tests in them just because the compiler eliminates a bunch of weird edge cases you don't have to worry about. ALEX: Coming from a component-based JavaScript framework, what is going to be my experience jumping into Elm? How is that going to feel different for me? JAMISON: That's a great question. Myself and almost everyone I've seen get started in Elm that comes from something based around components that the instinct is to create components in Elm for everything. You have a select box in Ember or React or whatever and you wrap it in components. You can just reuse it everywhere. In Elm, if you try to do that, you will hate it and think Elm is broken and horrible and just sucks. It's because the Elm architecture comes with, I guess, you could call it boilerplate, there's some work you have to do to build a component that can do IO and respond to events and stuff. That work is... I don't know, maybe like a dozen lines of code. Then there's some work to wire those components up together, that's maybe a couple more lines of code. So if you have like 300 components in your Elm application, you'll have... I don't know, like thousands of lines that just wiring stuff together code which won't really buy you that much because in my experience, using components is an attempt to make things understandable and isolate concerns. You get a lot of that from having peer functions and having a strong a static-type system. In Elm, you end up making a lot wider components, instead of having this deep tree of lots of components nested inside of each other. You'll have a much flatter but wider tree. That took a while to get used to but I think it makes sense for the language now. You can still create reusable things but you focus more on creating reusable functions instead of creating components that are black boxes, that you kind of package up and pass around. You can still do reuse but it's a little bit different than reuse in a component-based framework. This is a thing. I would say, in the last year, there's been a lot more discussion on blogposts and screencasts and stuff on a year ago, a couple of people were talking about it but there weren't really lots of great examples of this and now, I think, even the Elm Guide has some examples of reuse without components. ALEX: Yes. One of my favorite things about component-based JavaScript is because I've learned to test them so well. Even though, sometimes they can turn into a configuration ball, I've been able to make them very reliable, even if they are deeply nested so going away from that scares me. JAMISON: Yeah, it totally scared me. It felt wrong and weird and bad. But now, it doesn't. I don't know, I'm used to it, I guess, and I still write a lot of JavaScript. It's not that hard switching back and forth between those two mental models but I definitely had to develop a different mental model when writing Elm code. CHRIS: I'm interested in talking about some of the tooling. I know Elm has a lot of tooling. They have elm-reactor and they have the compiler. But I think I know that you also do the kind of dip into some of the JavaScript tooling if you are getting into bigger Elm application. You're probably still going to need something like a Webpack or Browserify, I guess. I'm curious what's your experience with that has been? JAMISON: You can definitely just write an Elm application and then compile it into this JavaScript file then drop that in a script tag on your page and it will all work. The complexity can get very low. If you want to do more advanced stuff like talking to JavaScript, You can still do all that without any additional tooling, if you would like. If you have a lot of dependencies in your JavaScript or you have a large JavaScript application or code base that you want to integrate with Elm, then you can use something like Webpack or Browserify. In my experience, it's no more painful than Webpack or Browserify. All the rest of that stuff already is. I don't know, there's an Elm Webpack plugin that will run the Elm compiler and allow you to import your Elm application into JavaScript file and I think there are similar stuff for Browserify and some of the other module bundlers. I don't think there's anything radically new on the Elm side as far as bundling up your application or anything like that. It just kind of works like you expect. The places where, I think Elm tooling is cool in ways that I haven't seen that much in JavaScript are in the Elm package manager. If you are building a package yourself, it has automatic semantic versioning built in so they have a type system. They can detect when your interfaces change automatically. If you try and release a version that you change the interface and you don't bump the version, they will like yell at you because that's a breaking change. There's some cool stuff around that that you get with the language having a static-type system. The debugger is a new thing as of a couple of weeks ago. That's built into the language. You might have seen similar stuff in other frameworks but it's all kind of extra add-ons. In Elm, because it has kind of a framework built into the language, they can also build in a debugger for that framework in the language. You can enable debug mode, pull up an application, click around, do a bunch of stuff, and then it'll record a log of all those actions and you can scroll back through them and jump to any point in that timeline to reload the state of the application to that point. You can export that log to a JSON file and then kind of send that around, have someone load that log in, and it'll get your application back into the same state. It's a really good for creating bug reports. You click some button 15 times and then it breaks -- do that, export the logs, send that to someone else. Instead of having to follow all the steps, they can just load your state and then figure out what's broken about that. I think that there are some tooling advances that are enabled by both the language itself, like the static type system and also the focus on strong conventions and frameworks built into the language. Does that makes sense? CHRIS: Yeah, absolutely. As you were talking, I thought about was that some tooling that you lean a lot on in JavaScript is kind of rendered unnecessary by the error messages in Elm. All of the things that you may bring in an extra tool to catch in JavaScript when in Elm will just tell you when it compiles and it will give you this just unbelievably friendly, informative, and easy to diagnosed error message that tells you like, "This is the exact line where this happened. Maybe you mean to do this instead," because it can make all sorts of inferences about, like what you probably meant to do based on the type signature you gave to a function or something. I could see that going a long way toward making a subset of tools just unnecessary in Elm. JAMISON: Yeah, a lot of tooling around JavaScript has sprung up to address... I don't know, not weaknesses but areas where people have identified JavaScript needs a little help now. If that's passive aggressive enough way to say it. The language is 20 years old. It was created way before people were building giant, million line code bases in it. But Elm is much younger and has the benefit of a lot of history and hindsight. It turns out you can avoid a lot of tools if you eliminate their need. I have had that weird feeling where I'm building a JavaScript project and it feels like I'm flying a 747. There's a thousand switches everywhere. I'm like powering up a bunch of different things. It feels like I'm being really productive because I'm configuring ESLint in Webpack, in Flow, and all these different tools. Then I go to Elm and I just start typing and it feels like I'm less productive but I've just skipped so many steps. It is a different feeling. ALEX: Would you say that maybe you feel so productive in JavaScript because it has such a strong community, with so many examples and so much shared code? Elm being a younger community, and this is strictly an assumption, may not be at that maturity level where you can share code and have that particular level of productivity. JAMISON: Yes. There are definitely third party libraries in Elm. There's probably a few orders of magnitude difference in the community sizes between Elm and JavaScript. There are just way more people writing JavaScript. The likelihood that someone will have ended up at your weird feature that you need for some random program is probably a little higher. There are some numbers differences. In my experience, the people that are really into Elm right now enjoy solving their own problems because it does feel like they're a little bit more of your own problems to solve. It's a tradeoff. I was going to say, if you value 100% focus on building business features, JavaScript might be better but I don't necessarily think that's the case. Using a bunch of third party code comes with a cost and some of that cost is you have to understand the API and some of it is you have to kind of take some responsibility for knowing where it breaks down. In Elm, I think that responsibility is lessened by the language because the API is a lot easier to understand when you can look at the types that the API creates and uses. It's a lot harder for it to just break your stuff. I think you could make the argument that even though there's a giant repository of JavaScript code out there, a lot of it might not be great for your program. But if you're using Elm, the smaller amount of code that is out there already could be easier to use and help you even more productive. ALEX: I would like to try to segue into the Elm community now and what that looks like? What is this Elm community? How do you get involved, say, I'm coming from JavaScript or any language and I love it? Maybe my work doesn't use Elm just yet but how can I contribute? How can I continue to write more Elm code for not just my specific use cases? JAMISON: I think my favorite thing about the Elm community is its focus on friendliness and learnability. I call it 'ruthless focus'. They are aggressively committed to building a language that is easy for people to pick up. If you are coming to Elm for the first time, you're pulling your hair out because it looks totally different from JavaScript. That might not make any sense to you. But a lot of the ideas that Elm has come from other languages like Haskell or ML languages and those languages, I would say, are proudly hard to get into. It's like a badge of honor to learn Haskell and then you like bleed to do it and then you enter this elite club where you got to talk about monoids all day. Elm is like a strong negative reaction against that, like they want this to be a language that people can learn and get some of the benefit. Because there are cool things in languages like Haskell so the goal is to take some of those cool things and other cool things from other places too. But put them in a package that is easy for people to pick up without devoting their life to an arcane branch of mathematics. I think they do a really good job of that. I've done Haskell pretty hard a few times and I'll bounce off it some more. I don't feel confused about Elm at all in anyway. In Elm, it's not like I'm some genius that can pick it up. It's that they have eliminated a lot of complexity and made it friendly and easy to learn. I think that carries over into the community. They're really interested in helping people who are new to functional programming or are new to programming in general. They're also just nice. if there's an Elm Slack channel that you hang out in and like any internet chat channel, sometimes people will get a little testy and in the Elm one, they're so good at defusing situations, calming people down, like apologizing, and like being human beings. You don't see a lot of rage-y arguments where people say mean things about each other. I've been really impressed with that. I want to talk a little bit more about what the community is like and then maybe talk about how to get into it, if that's okay. I would say the community is -- I know, it's evenly split but it seems fairly evenly split between people coming from JavaScript's who don't have any functional programming experience and people coming from functional programming who don't have any UI experience. It's interesting seeing those two very different groups come together and they're both attracted to Elm for different reasons and they kind of pull it a little bit in different ways. But it makes an interesting group of people to be around because you learn a lot of cool UI stuff, a lot of cool functional programming stuff. ALEX: Sounds like a recipe for success, really. JAMISON: Yeah. I think if they can make functional programming not have the snootiness that it has sometimes in genders and people, then I think functional programming is great technically. I think the culture around it can be just obnoxious. So I think if Elm can take the good things without the bad things, that's amazing and that's kind of what it's trying to do. As far as getting into the Elm community, are you talking about writing open source or contributing to open source or just where they hang out? ALEX: Yeah, I was talking about contributing to open source but maybe Elm is just a better community for a certain style of contribution and maybe that looks like a blogpost and a coding example of how to do something yourself. JAMISON: Like any new technology, there are definitely in the kind of evangelism phase. If you do write a blogpost that says nice things about Elm, there's like a horde of people that will swarm all over it because they like people to say nice things about Elm. There's a bunch of people like writing books, doing screencast, speaking on it, introducing people to it, and that's well received very well. I think there's at least one podcast on Elm already. So all that to say that I think the community receives kind of education and I guess, you can call it evangelism stuff very well and they're excited about that. If you are interested in contributing to open source, you can actually go to Package.Elm-Lang.org and you can see all of the Elm third party libraries and they all have these GitHub for the backing of its package manager. They all have source links right there. You can just find any random library and get to its source. I think the community is pretty open to contributions from people. If you want to see Elm source code and contribute to it, they're very open to that. This is kind of a culture shock to me coming from other communities where you can't just like show up, submit a patch to Elm core, and then have a discussion, and get it accepted or rejected. They're not super open to direct code level contributions. They would prefer more use case feedback, discussion, and suggestions. Then the core team will take all these feedback in, think about it, come up with a plan, and then implement it, instead of take a lot of little patches from people. Some of the core libraries are a little bit harder to directly contribute code to but they are very open. If you try and use it, you run into something that doesn't work the way you expected and you can create a small example that demonstrates that. They're super open to discussions about that to influence the direction of the API. CHRIS: I think over the course of JavaScript and front-end development, there has been kind of waves of abstraction over JavaScript. There were just libraries and there were things like backbone and then it kind of moved into doing something like CoffeeScript or TypeScript and a couple others where the idea is -- ALEX: Good old Objective-J. CHRIS: Yeah, exactly. You might be transpiling down a JavaScript but there are still very much a clear link between something like CoffeeScript and JavaScript. Elm seems like it is one of a new batch of approaches where we're actually going to just sidestep JavaScript almost entirely. Like it is going to be like JVM bytecode or a browser and we're going to build an entirely new language on top of that. I know there's also a bit like ClojureScript, Scala.js, and PureScript and I'm curious, do you think that is going to be a continuing trend that front-end development is going to land on a mainstream solution that might not actually be JavaScript at all? Or do you see it as eventually circling back and pulling a lot of these features into JavaScript itself? JAMISON: I don't think that front-end development will be Elm in like five years or whatever. I don't think it's going to replace JavaScript at all. I think it might definitely influence tooling libraries or the language itself. The Elm architecture looks a lot like Redux because the Redux author read Elm and they're like, that's cool and then they wrote it in JavaScript. There are other places where like time-travelling debugging. I believe the JavaScript thing came from the Elm time-travelling debugger as well. There are cases where it has influenced JavaScript's already and I think that will continue to happen. Flow is a gradual-type system. You can lay it on top of JavaScript and they have done a lot of work on their error messages influenced by Elm. It's super cool to see all those influences back into the JavaScript community as a whole. I think there are classes of people who are more interested in doing some sprinkling of JavaScript on to pages. They might not even be like programmers really. They're kind of like designers who do a little bit of coding and I don't know if Elm makes sense for that kind of role where you just need to add a little bit of interaction. You can do that but it doesn't seem like a thing that group would focus on. It's just really hard to change the world. I write a lot of JavaScript so I'm bias but it feels like it's the most popular language in the world and being the most popular Language in the world is not a thing that's easily overthrown. But I think it will grow, like programming will look more like Elm does just in general in the future and I think JavaScript will as well. But I also think Elm will continue to grow. There's a lot of excitement about it and there's not a ton of people bouncing hard off of it. There's some people they're looking at it and they're like, "Eh, not yet." Some people just look at it and hate it. But from people that use it, I don't see a lot of those people dropping out. I've seen most of them sticking around. I think the trend is definitely -- Elm will grow. But I don't know if that will take over the world. ALEX: Then what lessons are developers bringing back to say and to write better JavaScript? JAMISON: I think a lot of people are learning about types and data modeling. If you learn programming through JavaScript, the idea that there's this defined shape that your data has and some tool will help you make sure that your data always looks like that is kind of like strange and foreign. I think a lot of people are learning that there's value in that. If you grew up in the MongoDB / Angular world like everything is schema-less, you just kind of slam some JavaScript objects everywhere, it all works, then it breaks, and you don't know why and you need to track it down. But I think seeing the value and thinking a little bit more clearly about what your data looks like and then forcing that through tooling is one lesson. That is taking a little bit more root in JavaScript. All the stuff around functional programming in JavaScript is like achieved buzzword status by now. But there is definitely still some education happening around how it's easier to test peer functions, how they're easier to understand and reuse, and how it's good to write them. I think Elm will continue to push that. Some of it though is there are some ideas you can take from Elm but it's just so much easier to use them to their fullest potential in a language and environment built around those ideas. You can kind of like cram a type system on to JavaScript. It's still really easy to get around and it does not model side effects at all. The elm type system modeled side effects so it helps you reason about where my program can talk to a network, where it can do things that are going to take a while to come back, and kind of sandbox those things into a place where you expect them, instead of have them sprinkled all over your program. CHRIS: I definitely feel that uncanny valley of trying to bring FP -- functional programming -- things back into JavaScript when it comes to pattern matching. That's something that in Elm or Elixir or any number of more functional languages. Pattern matching enables a lot of these higher level patterns that don't always translate super great back to JavaScript land. JAMISON: Yeah, the uncanny valley is a great way to put it. There are a lot of things that you can do that will lead to better JavaScript. But you always have to take the environment that you're working in into consideration. There are just some things you can't do or some things that are going to be more pain than they're worth to do. On the other hand, it is kind of nice to just type console.log wherever you want or type like '$.getJSON' or whatever. The added security that Elm brings comes at a cost of locking you down a little bit and that can be a little frustrating to people sometimes. But I think the payoff is worth it. ALEX: A side story. About six months ago, I tried to get into the Haskell programming book. That's currently being worked on. That's because I want to learn some functional programming lessons, maybe bring them back into my JavaScript, or just learn something new. It's useful to learn a new language and bring it back to your work. Of this 1300 page book, I got just past Chapter 2 and I was in a Haskell book club like everybody held each other accountable to finish this book. I did not make it. I could not figure out how to bring any of these lessons back into my code which is what I wanted to do here. Elm takes that functional programming concept and says, "We're applying it to UI right away." There's no, "How do I apply this? How do I side step this?" No, you're doing it immediately. Really, you're getting me excited to jump back into this tutorial and learn it and check out the community, just to be able to bring this back to my day to day and bring those lessons and do it. JAMISON: Yeah, the first time I tried to learn Haskell, I learned that I could sort an array of integers in memory and that was it. That was as far as my Haskell skills took me so I definitely feel you there. In Haskell, they'll tell you it's a research language so they have a lot of reasons why it kind of works the way it does and learning it takes the pathway it does. Elm is definitely not a research language. It's trying to be incredibly pragmatic so you build UIs. In the guide, that's how they teach you the language. It's the stuff you normally build. Thank you for bringing that up. I think, it's a thing that they focus on. I'm glad you picked it out. ALEX: Yeah, at the learning curve is the syntax but you're still solving those same problems. If you're coming from UI, you already have that context. That is probably the majority of the hard work -- it's solving problems that are meaningful to you. JAMISON: Yeah, for me the syntax, I had learned enough Haskell that the syntax wasn't hard -- how to make HTTP requests and do site-affecting things like that. It was the hang up for me but Elm, there is a way to do it and they show you and that's how you do everything and it all works the same way and it's fairly easy to understand. I don't want to call it easy because that makes people that struggle to feel that but they put a lot of work into making that both robust so it won't break your program and also learnable. CHRIS: One thing I would love to mention about the syntax, I have learned a number of languages, I guess and the Elm syntax was definitely one that threw me the most and it put me off for, I guess it wasn't so much just the syntax, it was the syntax combined with how people do things that I would call more like style choices. JAMISON: The formatting? CHRIS: Yeah, Elm formats things in weird ways. Except that there is a tool called 'elm-format'. Once I've discovered that it has a really great editor integration for a lot of editors, it effectively remove that problem because I discovered that I can essentially write garbage basically in my editor and I can say that anything will make it look beautiful. It's fantastic. It removes such a big barrier for me when I was trying to learn it. JAMISON: Yeah, elm-format, there were some great debates about it while it was being created but now that it exists, it's awesome. Speaking a little bit more of tooling, Elm comes out with new releases of the language with some backwards and compatible changes. But along with that, they release a tool to upgrade your Elm code automatically. It's not perfect and it won't run on 100%. It won't fix everything but with most projects, it fixes everything. Again, the benefit of having such a strict language is there's tools that will just upgrade all your stuff for you. That's pretty awesome. It lowers the cost of evolving the language because they can keep adding new things and changing things without just leaving the community in the dust like we've seen in some other stuff. That's kind of an Ember-ish thing, I guess. Ember has the whole stability... What is it? Something without stagnation? Stability without stagnation? CHRIS: Stability without stagnation. JAMISON: Where you just get all these free upgrades that are really easy to opt into and Elm has that same philosophy. ALEX: What made you decide to check out Elm, to check out this community? Do you like to jump into new languages, new communities, and poke around and see what sticks? Or is there something that attracted you to Elm in particular. JAMISON: Yes to both of those. I do poke around in a lot of new languages. I have a good friend, Sean Hess who's really into functional programming and he's a Haskell true believer. I am not but he is, so he teaches me stuff by Haskell. I think, he told me about it. I might be misremembering though. It might have been just some random blogpost or podcast somebody did a few years ago. But I was already excited about new languages and functional programming and I had tried to learn Haskell and bounced off so the idea of a functional programming language that takes some good ideas from Haskell, that runs in the browser that's new. It was like all the shiny things that I look for altogether in one thing. I tried it and I liked it. I, also was really impressed by Evan Czaplicki, He's the creator of Elm. His philosophy around creating a language and the goals he wanted to accomplish with it. There's a really good talk he gave and called 'Let's be mainstream' which talks about some of the stuff we talked about around if functional programming is pure statically-typed functional programming is so amazing and it has all these people that love it and swear it's the only way to write software, why no one does it? Why the number of people use it is so small? His thesis is basically because the languages that do this are kind of user hostile so he's trying to make it a user friendly, the one that takes all those ideas. I just really liked that philosophy. CHRIS: I want to go back to something that you mentioned a little bit ago and that was data modeling because that is definitely something that I noticed being extremely helpful, any time I'm using a statically-typed language. It is very much something that I brought with me back to JavaScript. But I was wondering, Maybe you could talk a little bit more in depth about what data modeling really means in terms of Elm, the type system, the record type, and that kind of stuff. JAMISON: Yeah, if you've worked with statically-typed languages like Java or C++ or something, you might have an idea of things like classes as a way to model data where you create a class and you say it has all these fields on it. I think, in the Elm type system, I'm going to say it's a lot better than those languages because it has a lot less ceremony and it is a lot more powerful. Elm has type inference which means you don't have to declare the type of everything. It can just figure it out from a lot of places. That's the thing that makes your code a lot friendlier to write. To model data in Elm, there are two main ways to do that. One is with these record types that you mentioned, Chris. You basically declare an object that has a certain shape like I'll make a type called 'user' and it has a user ID and a hash password and... I don't know, a list of my favorite cats or whatever. Then you can just refer to that user type in function arguments or in return types or anything like that. In Elm, because you created that type, it knows that these are all the fields it has. If you try to access a field that's not on there, it'll yell at you because you're doing something that won't work. Because you have to think through all of the different fields that are on your types, it forces you to do a little bit more. It's kind of like the other side of TDD instead of writing test first. You have to think about your data first. You could call it type-driven development, I guess. CHRIS: That's awesome. JAMISON: In my experience, that's helpful. In the same way, TDD is, right? It helps you to do a little bit of design first. Think about how you're going to interact with the program in some way. Instead of writing tests, you're thinking what data do I need here. They also have these things that you could call them -- there are a bunch of different names for them: algebraic data types, I guess. Some people call them tagged unions. They're kind of like enums where you say this type can take any of these finite list of values. But instead of an enum being like an integer, like it is in some languages with a fancy name wrapped around it, the enum types can contain other value. You can say... what's a good example for this? You could say a user is either an authenticated user with a user record inside it or an unauthenticated user. Then when you're using that type in your program, you check, "Is this user type the authenticated user?" Then, if so it has this user field inside of it that you can pluck out and use. Or, "Is it an unauthenticated user?" Those two different things, the super enums, the algebraic data types plus the record types are really powerful for modeling what data looks like in the real world. I haven't run into that many issues where it's been hard to do something I want to do with just those two concepts. Type systems are hard to explain over the air but hopefully, that helped a little bit. ALEX: I thought that was great. CHRIS: I think a good example of the algebraic data type thing is looking at messages in Elm versus actions in Redux. If our listeners are familiar with those, they are very, very, very similar at a high level. But in Redux, you just have string then you do a switch statement or something and you match on some strings. You hope that you synced everything up correctly. JAMISON: Yeah, you say, "This action has a message and then has a payload that looks like this." See if it match against the message and then hope that the payload somebody sent actually looks like you expect it to look. CHRIS: Yeah, whereas in Elm, you can actually say, "My message type is a union of all of these different things," and now, Elm knows exactly what you're saying and you can't accidentally send the wrong payload to the wrong update function or something. It's one of the cases where I found that there's a very, very clear similarity in JavaScript and it highlights, I think a lot of the nice features that Elm brings to that equation. JAMISON: Yeah and there's even more strictness around that, like you have to handle every message type in Elm. So if you say, "This function takes in a message and does something with it," and then you check against what kind of message it is, you have to check every case or Elm won't compile because they don't want you to just blindly miss something, I guess. But in Redux, you could just happily forget a thing in your case statement and then you send a message and it doesn't do anything and then you have to kind of trace through it and debug why that's happening. There's just more helpful stability stuff built in. CHRIS: Cool. I am so incredibly happy with how this podcast went. I'm just excited to start coding and start getting into Elm. I think people and developers maybe at an inflection point with JavaScript and just going and checking out something else that they can immediately apply back to their day to day. I think, it's so incredibly valuable and something that I'm going to be looking to explore very certain. JAMISON: The value pitch is pretty strong because everyone that's written JavaScript has just written code that breaks when things get passed around that they don't expect. I do that all the time and Elm makes that impossible. You can break it in other ways but you just eliminate this class of errors that plagues your existence in JavaScript. If you want to experience that life, check out Elm. It's got a lot of other good things too but just writing code that does not crashes is a pretty strong pitch, I think. ALEX: Jamison, are there any resources that you might recommend for someone who wants to get started with Elm? JAMISON: Somebody mentioned the guide a few times. Everyone says that about every language, check out the official tutorial or whatever, and they have wildly varying quality. The Elm guide is the thing that worked a ton on. It's pretty good, I think and geared towards people that have no knowledge of Elm, no knowledge of functional programming stuff. That's a Guide.Elm-lang.org. Then there's a Slack channel. If you just go to Elm-lang.org, it will have links to the Slack channel and there are lots of helpful friendly people there. I think those are the two best resources because with those, you can find all the other stuff. CHRIS: There's also another one that I really like to mention which is the elm tutorial. I think, it's Elm-tutorial.org. I found it to be a really great compliment to the official Elm Guide. I think it walks through a little more in building a full app where the Elm Guide kind of touches on a bunch of different related topics. But they're not necessarily one narrative. The Elm tutorial did a really good job of tying all that together for me. JAMISON: Yeah and this is been around for a long time and has kept it up through the evolution of the language. This is good stuff. ALEX: Jamison, thank you for coming on the Frontside Podcast. We really appreciated talking to you. JAMISON: Thanks for having me. ALEX: If you love Jamison's voice, you should check out his React Conf talk from 2016 also about Elm. It's a wonderful talk. Go check that out as well. JAMISON: Thank you. Can I pitch my other stuff too? Is that kosher? ALEX: You can absolutely pitch it. CHRIS: Soft skills engineering! JAMISON: Yeah, I do a podcast called Soft Skills Engineering with my friend Dave Smith where we talk about all of the non-technical stuff in writing code. It's like you [inaudible], you can submit questions, and we answer them. If you're interested in talking about building software together, you should talk to the Frontside first. But after that, you can find me at Fivestack.computer. That's where my consultancy lives. Consults is maybe a strong way of describing it. That's like saying the three toddlers standing on top of each other in a trench coat is like an adult. But if you want to work together, then check that out. ALEX: Great. All right. That wraps it up for us. Thank you very much for listening and we'll talk to you next week.

Evan Czaplicki, creator of Elm, and Richard Feldman of NoRedInk joined the show to talk deeper about Elm, the pains of CSS it solves, scaling the Elm architecture, reusable components, and more.

Evan Czaplicki, creator of Elm, and Richard Feldman of NoRedInk joined the show to talk deeper about Elm, the pains of CSS it solves, scaling the Elm architecture, reusable components, and more.

In episode 13 of the Front End Happy Hour podcast, we’re joined by Jafar Husain from Netflix to talk with us about the future of JavaScript. Jafar is part of the TC-39 committee that helps determine the future specs of ECMAScript. Jafar shares a lot of interesting insights into how the committee works and how a feature makes it's way into the spec. Jafar also talks to us about Observables and cancellable promises. Items mentioned in the episode: TC-39, ECMAScript, Iterators and Generators, Proxies, Observables, Promises, Evan Czaplicki, Yehuda Katz, Rust Language, TypeScript, Elm Language, PureScript, Flow, Jay Phelps, LazyDOM, Tracy Lee Guests: Jafar Husain - @jhusain Panelists: Ryan Burgess - @burgessdryan Jem Young - @JemYoung Derrick Showers - @derrickshowers Brian Holt - @holtbt Picks: Jafar Husain - Idris Language Ryan Burgess - Status, process, and documents for ECMA262 Ryan Burgess - Octomore Scotch 07.1 Jem Young - Morbotron Jem Young - Full Stack Toronto Derrick Showers - Glimmer 2 Deep Dive Derrick Showers - Rogue varieties Brian Holt - I Really Like Angular 2 - Trailer for The Jeff Cross Show on Modern Web feat Jafar Husain Brian Holt - Modern Web Podcast

Elixir Fountain Evan Czaplicki 2016-07-11 by Johnny Winn

02:00 - Gilad Bracha Introduction Twitter GitHub Blog Dart JavaScript Jabber Episode #008: V8 and Dart with Lars Bak and Kasper Lund Dartium 09:17 - Programming Language Evolution and Design Elm Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki 10:47 - Capabilities and Language Features Newspeak “Functional” 12:46 - Actors 16:41 - Live Programming Bret Victor on Live-Coding 19:07 - Smalltalk REPL (Read–eval–print loop) Monkey patching 29:01 - Designing a Language “Programming is an experience.” 38:59 - Complexity 42:41 - Newspeak (Con’t) 45:58 - Smalltalk or Newspeak? Squeak Pharo Dolphin Smalltalk VisualWorks 48:13 - How are programming languages like shrubberies Picks Stroopwafels (Chuck) Staked: The Iron Druid Chronicles by Kevin Hearne (Chuck) Calamity (The Reckoners) by Brandon Sanderson (Chuck) Katrina Owen: Here be Dragons (Jessica) The Slow Party Parrot Emoji (Jessica) Umberto Eco (Gilad)

02:00 - Gilad Bracha Introduction Twitter GitHub Blog Dart JavaScript Jabber Episode #008: V8 and Dart with Lars Bak and Kasper Lund Dartium 09:17 - Programming Language Evolution and Design Elm Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki 10:47 - Capabilities and Language Features Newspeak “Functional” 12:46 - Actors 16:41 - Live Programming Bret Victor on Live-Coding 19:07 - Smalltalk REPL (Read–eval–print loop) Monkey patching 29:01 - Designing a Language “Programming is an experience.” 38:59 - Complexity 42:41 - Newspeak (Con’t) 45:58 - Smalltalk or Newspeak? Squeak Pharo Dolphin Smalltalk VisualWorks 48:13 - How are programming languages like shrubberies Picks Stroopwafels (Chuck) Staked: The Iron Druid Chronicles by Kevin Hearne (Chuck) Calamity (The Reckoners) by Brandon Sanderson (Chuck) Katrina Owen: Here be Dragons (Jessica) The Slow Party Parrot Emoji (Jessica) Umberto Eco (Gilad)

02:00 - Gilad Bracha Introduction Twitter GitHub Blog Dart JavaScript Jabber Episode #008: V8 and Dart with Lars Bak and Kasper Lund Dartium 09:17 - Programming Language Evolution and Design Elm Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki 10:47 - Capabilities and Language Features Newspeak “Functional” 12:46 - Actors 16:41 - Live Programming Bret Victor on Live-Coding 19:07 - Smalltalk REPL (Read–eval–print loop) Monkey patching 29:01 - Designing a Language “Programming is an experience.” 38:59 - Complexity 42:41 - Newspeak (Con’t) 45:58 - Smalltalk or Newspeak? Squeak Pharo Dolphin Smalltalk VisualWorks 48:13 - How are programming languages like shrubberies Picks Stroopwafels (Chuck) Staked: The Iron Druid Chronicles by Kevin Hearne (Chuck) Calamity (The Reckoners) by Brandon Sanderson (Chuck) Katrina Owen: Here be Dragons (Jessica) The Slow Party Parrot Emoji (Jessica) Umberto Eco (Gilad)

Derek shares some Elixir annoyances with Sean and they discus how a consulting role colors their perception of languages and frameworks, both for better and for worse. Sean provides an update on SQLite and Association support in Diesel. GoodTImes, Timex, and Ecto.DateTime When should you use DateTime and when should you use Time by Andrew White Twitter conversation with Brandon Hikert Postgres RETURNING Preloading in Ecto User Focused Design in Elm by Evan Czaplicki Getting Started with Diesel Rust API Evolution

02:52 - What’s up Merrick Christensen? Twitter GitHub Blog 03:43 - Favorite Episodes Episode #124: The Origin of Javascript with Brendan Eich Episode #037: Specialized vs Monolithic with James Halliday and Tom Dale   Episode #071: JavaScript Strategies at Microsoft with Scott Hanselman Episode #044: Book Club: Effective JavaScript with David Herman Episode #161: Rust with David Herman Episode #008: V8 and Dart with Lars Bak and Kasper Lund Episode #175: Elm with Evan Czaplicki and Richard Feldman Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki Adventures in Angular Episode #80: Aurelia with Rob Eisenberg 08:58 - How have ideas about JavaScript changed since being a panelist on the show? jQuery adding 2 numbers from input fields 15:01 - Off the Air Experiences         20:23 - Work/Job Changes Kuali 23:54 - JS Jabber = Newbie-Friendly 24:58 - Work/Job Changes (Cont’d) Daplie All Remote Conferences 35:25 - Organizing Conferences and Name Recognition Dave Smith: How React literally waters my lawn from React Rally 40:55 - Spinoff Shows Adventures in Angular Web Security Warriors React Native Radio JavaScript Air Angular Air 45:08 - Podcast Administration and Organization; Episode Release Timeline Mandy Upwork Picks JavaScript Jabber (Joe) The Harry Potter Audiobooks (Joe) Calamity by Brandon Sanderson (Joe) AngularConnect (Joe) Dennis Overbye: Gravitational Waves Detected, Confirming Einstein’s Theory (AJ) The God Who Weeps: How Mormonism Makes Sense of Life by Terryl Givens (AJ) Julia Evans: Have high expectations for your computers (Jamison) January 28th GitHub Incident Report (Aimee) Denzel Brade: Front End Dev — Running before you can walk (Aimee) Captivating Revised and Updated: Unveiling the Mystery of a Woman's Soul by John Eldredge and Stasi Eldredge (Aimee) drone (Merrick) Haskell Book (Merrick) Amazon Prime (Chuck) nexxt Maine Wall Shelf/Floating Ledge (Chuck) Read the presidential candidate’s books (Chuck)

02:52 - What’s up Merrick Christensen? Twitter GitHub Blog 03:43 - Favorite Episodes Episode #124: The Origin of Javascript with Brendan Eich Episode #037: Specialized vs Monolithic with James Halliday and Tom Dale   Episode #071: JavaScript Strategies at Microsoft with Scott Hanselman Episode #044: Book Club: Effective JavaScript with David Herman Episode #161: Rust with David Herman Episode #008: V8 and Dart with Lars Bak and Kasper Lund Episode #175: Elm with Evan Czaplicki and Richard Feldman Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki Adventures in Angular Episode #80: Aurelia with Rob Eisenberg 08:58 - How have ideas about JavaScript changed since being a panelist on the show? jQuery adding 2 numbers from input fields 15:01 - Off the Air Experiences         20:23 - Work/Job Changes Kuali 23:54 - JS Jabber = Newbie-Friendly 24:58 - Work/Job Changes (Cont’d) Daplie All Remote Conferences 35:25 - Organizing Conferences and Name Recognition Dave Smith: How React literally waters my lawn from React Rally 40:55 - Spinoff Shows Adventures in Angular Web Security Warriors React Native Radio JavaScript Air Angular Air 45:08 - Podcast Administration and Organization; Episode Release Timeline Mandy Upwork Picks JavaScript Jabber (Joe) The Harry Potter Audiobooks (Joe) Calamity by Brandon Sanderson (Joe) AngularConnect (Joe) Dennis Overbye: Gravitational Waves Detected, Confirming Einstein’s Theory (AJ) The God Who Weeps: How Mormonism Makes Sense of Life by Terryl Givens (AJ) Julia Evans: Have high expectations for your computers (Jamison) January 28th GitHub Incident Report (Aimee) Denzel Brade: Front End Dev — Running before you can walk (Aimee) Captivating Revised and Updated: Unveiling the Mystery of a Woman's Soul by John Eldredge and Stasi Eldredge (Aimee) drone (Merrick) Haskell Book (Merrick) Amazon Prime (Chuck) nexxt Maine Wall Shelf/Floating Ledge (Chuck) Read the presidential candidate’s books (Chuck)

02:52 - What’s up Merrick Christensen? Twitter GitHub Blog 03:43 - Favorite Episodes Episode #124: The Origin of Javascript with Brendan Eich Episode #037: Specialized vs Monolithic with James Halliday and Tom Dale   Episode #071: JavaScript Strategies at Microsoft with Scott Hanselman Episode #044: Book Club: Effective JavaScript with David Herman Episode #161: Rust with David Herman Episode #008: V8 and Dart with Lars Bak and Kasper Lund Episode #175: Elm with Evan Czaplicki and Richard Feldman Ruby Rogues Episode #212: Elm with Richard Feldman and Evan Czaplicki Adventures in Angular Episode #80: Aurelia with Rob Eisenberg 08:58 - How have ideas about JavaScript changed since being a panelist on the show? jQuery adding 2 numbers from input fields 15:01 - Off the Air Experiences         20:23 - Work/Job Changes Kuali 23:54 - JS Jabber = Newbie-Friendly 24:58 - Work/Job Changes (Cont’d) Daplie All Remote Conferences 35:25 - Organizing Conferences and Name Recognition Dave Smith: How React literally waters my lawn from React Rally 40:55 - Spinoff Shows Adventures in Angular Web Security Warriors React Native Radio JavaScript Air Angular Air 45:08 - Podcast Administration and Organization; Episode Release Timeline Mandy Upwork Picks JavaScript Jabber (Joe) The Harry Potter Audiobooks (Joe) Calamity by Brandon Sanderson (Joe) AngularConnect (Joe) Dennis Overbye: Gravitational Waves Detected, Confirming Einstein’s Theory (AJ) The God Who Weeps: How Mormonism Makes Sense of Life by Terryl Givens (AJ) Julia Evans: Have high expectations for your computers (Jamison) January 28th GitHub Incident Report (Aimee) Denzel Brade: Front End Dev — Running before you can walk (Aimee) Captivating Revised and Updated: Unveiling the Mystery of a Woman's Soul by John Eldredge and Stasi Eldredge (Aimee) drone (Merrick) Haskell Book (Merrick) Amazon Prime (Chuck) nexxt Maine Wall Shelf/Floating Ledge (Chuck) Read the presidential candidate’s books (Chuck)

02:54 - John A. De Goes Introduction Twitter GitHub Blog SlamData 06:34 - Phil Freeman Introduction Twitter GitHub Blog 07:38 - What is PureScript? 09:11 - Features Extensible Effects 12:24 - Overcoming the Vocabulary Problem in Functional Programming Gang of Four Book (Design Patterns) purescript-halogen 20:07 - Prerequisites to PureScript 26:14 - PureScript vs Elm JavaScript Jabber Episode #175: Elm with Evan Czaplicki and Richard Feldman No Runtime General Purpose vs UI-Focused Generic Containers 40:37 - Similar Languages to PureScript 44:07 - PureScript Background Roy 47:48 - The WebAssembly Effect 51:01 - Readability 53:42 - PureScript Learning Resources PureScript by Example by Phil Freeman PureScript Conf 2015/6 55:43 - Working with Abstractions purescript-aff Audrey Popp: Fighting Node Callback Hell with PureScript Picks Philip Robects: What the heck is the event loop anyways? @ JS Conf EU 2014 (Aimee) loupe (Aimee) The Man in the High Castle (Jamison) Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (Jamison)   Lambda Lounge Utah (Jamison) Michael Trotter: Intro to PureScript @ Utah Haskell Meetup (Jamison) Utah Elm Users (Jamison) Screeps (Joe) Most Likely to Succeed: Preparing Our Kids for the Innovation Era by Tony Wagner (Joe) Dark Matter (Joe) LambdaConf (John) @lambda_conf (John) ramda (John) Proper beef, ale & mushroom pie (John) Tidal (Phil) purescript-flare (Phil) The Forward JS Conference (Phil)

02:54 - John A. De Goes Introduction Twitter GitHub Blog SlamData 06:34 - Phil Freeman Introduction Twitter GitHub Blog 07:38 - What is PureScript? 09:11 - Features Extensible Effects 12:24 - Overcoming the Vocabulary Problem in Functional Programming Gang of Four Book (Design Patterns) purescript-halogen 20:07 - Prerequisites to PureScript 26:14 - PureScript vs Elm JavaScript Jabber Episode #175: Elm with Evan Czaplicki and Richard Feldman No Runtime General Purpose vs UI-Focused Generic Containers 40:37 - Similar Languages to PureScript 44:07 - PureScript Background Roy 47:48 - The WebAssembly Effect 51:01 - Readability 53:42 - PureScript Learning Resources PureScript by Example by Phil Freeman PureScript Conf 2015/6 55:43 - Working with Abstractions purescript-aff Audrey Popp: Fighting Node Callback Hell with PureScript Picks Philip Robects: What the heck is the event loop anyways? @ JS Conf EU 2014 (Aimee) loupe (Aimee) The Man in the High Castle (Jamison) Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (Jamison)   Lambda Lounge Utah (Jamison) Michael Trotter: Intro to PureScript @ Utah Haskell Meetup (Jamison) Utah Elm Users (Jamison) Screeps (Joe) Most Likely to Succeed: Preparing Our Kids for the Innovation Era by Tony Wagner (Joe) Dark Matter (Joe) LambdaConf (John) @lambda_conf (John) ramda (John) Proper beef, ale & mushroom pie (John) Tidal (Phil) purescript-flare (Phil) The Forward JS Conference (Phil)

02:54 - John A. De Goes Introduction Twitter GitHub Blog SlamData 06:34 - Phil Freeman Introduction Twitter GitHub Blog 07:38 - What is PureScript? 09:11 - Features Extensible Effects 12:24 - Overcoming the Vocabulary Problem in Functional Programming Gang of Four Book (Design Patterns) purescript-halogen 20:07 - Prerequisites to PureScript 26:14 - PureScript vs Elm JavaScript Jabber Episode #175: Elm with Evan Czaplicki and Richard Feldman No Runtime General Purpose vs UI-Focused Generic Containers 40:37 - Similar Languages to PureScript 44:07 - PureScript Background Roy 47:48 - The WebAssembly Effect 51:01 - Readability 53:42 - PureScript Learning Resources PureScript by Example by Phil Freeman PureScript Conf 2015/6 55:43 - Working with Abstractions purescript-aff Audrey Popp: Fighting Node Callback Hell with PureScript Picks Philip Robects: What the heck is the event loop anyways? @ JS Conf EU 2014 (Aimee) loupe (Aimee) The Man in the High Castle (Jamison) Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (Jamison)   Lambda Lounge Utah (Jamison) Michael Trotter: Intro to PureScript @ Utah Haskell Meetup (Jamison) Utah Elm Users (Jamison) Screeps (Joe) Most Likely to Succeed: Preparing Our Kids for the Innovation Era by Tony Wagner (Joe) Dark Matter (Joe) LambdaConf (John) @lambda_conf (John) ramda (John) Proper beef, ale & mushroom pie (John) Tidal (Phil) purescript-flare (Phil) The Forward JS Conference (Phil)

02:19 - Matthew Podwysocki Introduction Twitter GitHub Microsoft 04:01 - RxJS Reactive JavaScript Interview w/ Jeffrey Van Gogh & Matthew Podwysocki @ JSConf 2010 “First-class Events” 10:18 - Practical Experience of Use Observables 17:28 - observable-spec 21:43 - Observables and Promises 25:06 - Using RxJS in Common Frameworks RxJS Git Book RxJS Gitter Channel 27:53 - Are there places where observables might not be better than callbacks/Promises? 29:16 - Why would someone use RxJS on the backend in place of Node streams? RabbitMQ 32:28 - Are Promises dying? 36:13 - Observable Gotchas Hot vs Cold Observables 40:29 - Influence Elm Functional Reactive Programming (FRP) 47:47 - Will observables in ES2016 replace RxJS? Picks A cartoon guide to Flux (Aimee) Promisees (Aimee) The Dear Hunter - Act IV Rebirth in Reprise (Jamison) Jessie Char: Expert On Nothing @ NSConf7 (Jamison) XHR Breakpoints (Dave) Glove and Boots (Dave) Computer Programming (Joe) Evan Czaplicki’s Thesis for Elm (Joe) The Alchemist by Paulo Coelho (Chuck) thaliproject (Matthew) BBC Micro Bit (Matthew) Minutemen (Matthew)

02:19 - Matthew Podwysocki Introduction Twitter GitHub Microsoft 04:01 - RxJS Reactive JavaScript Interview w/ Jeffrey Van Gogh & Matthew Podwysocki @ JSConf 2010 “First-class Events” 10:18 - Practical Experience of Use Observables 17:28 - observable-spec 21:43 - Observables and Promises 25:06 - Using RxJS in Common Frameworks RxJS Git Book RxJS Gitter Channel 27:53 - Are there places where observables might not be better than callbacks/Promises? 29:16 - Why would someone use RxJS on the backend in place of Node streams? RabbitMQ 32:28 - Are Promises dying? 36:13 - Observable Gotchas Hot vs Cold Observables 40:29 - Influence Elm Functional Reactive Programming (FRP) 47:47 - Will observables in ES2016 replace RxJS? Picks A cartoon guide to Flux (Aimee) Promisees (Aimee) The Dear Hunter - Act IV Rebirth in Reprise (Jamison) Jessie Char: Expert On Nothing @ NSConf7 (Jamison) XHR Breakpoints (Dave) Glove and Boots (Dave) Computer Programming (Joe) Evan Czaplicki’s Thesis for Elm (Joe) The Alchemist by Paulo Coelho (Chuck) thaliproject (Matthew) BBC Micro Bit (Matthew) Minutemen (Matthew)

02:19 - Matthew Podwysocki Introduction Twitter GitHub Microsoft 04:01 - RxJS Reactive JavaScript Interview w/ Jeffrey Van Gogh & Matthew Podwysocki @ JSConf 2010 “First-class Events” 10:18 - Practical Experience of Use Observables 17:28 - observable-spec 21:43 - Observables and Promises 25:06 - Using RxJS in Common Frameworks RxJS Git Book RxJS Gitter Channel 27:53 - Are there places where observables might not be better than callbacks/Promises? 29:16 - Why would someone use RxJS on the backend in place of Node streams? RabbitMQ 32:28 - Are Promises dying? 36:13 - Observable Gotchas Hot vs Cold Observables 40:29 - Influence Elm Functional Reactive Programming (FRP) 47:47 - Will observables in ES2016 replace RxJS? Picks A cartoon guide to Flux (Aimee) Promisees (Aimee) The Dear Hunter - Act IV Rebirth in Reprise (Jamison) Jessie Char: Expert On Nothing @ NSConf7 (Jamison) XHR Breakpoints (Dave) Glove and Boots (Dave) Computer Programming (Joe) Evan Czaplicki’s Thesis for Elm (Joe) The Alchemist by Paulo Coelho (Chuck) thaliproject (Matthew) BBC Micro Bit (Matthew) Minutemen (Matthew)

02:27 - Evan Czaplicki Introduction Twitter GitHub Prezi 02:32 - Richard Feldman Introduction Twitter GitHub NoRedInk 02:38 - Elm @elmlang 04:06 - Academic Ideas 05:10 - Functional Programming, Functional Reactive Programming & Immutability 16:11 - Constraints Faruk Ateş Modernizr The Beauty of Constraints Types / Typescript 24:24 - Compilation 27:05 - Signals start-app 36:34 - Shared Concepts & Guarantees at the Language Level 43:00 - Elm vs React 47:24 - Integration Ports lunr.js 52:23 - Upcoming Features 54:15 - Testing Elm-Test elm-check 56:38 - Websites/Apps Build in Elm CircuitHub 58:37 - Getting Started with Elm The Elm Architecture Tutorial Elm Examples 59:41 - Canonical Uses? 01:01:26 - The Elm Community & Contributions The Elm Discuss Mailing List Elm user group SF Stack Overflow ? The Sublime Text Plugin WebStorm Support for Elm? Coda grunt-elm gulp-elm Extras & Resources Evan Czaplicki: Let's be mainstream! User focused design in Elm @ Curry On 2015 Evan Czaplicki: Blazing Fast HTML: Virtual DOM in Elm Picks The Pragmatic Studio: What is Elm? Q&A (Aimee) Elm (Joe) Student Bodies (Joe) Mike Clark: Getting Started With Elm (Joe) Angular Remote Conf (Chuck) Stripe (Chuck) Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck) Understanding Comics: The Invisible Art by Scott McCloud (Evan) The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan) The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard) Rich Hickey: Simple Made Easy (Richard) NoRedInk Tech Blog (Richard)

02:27 - Evan Czaplicki Introduction Twitter GitHub Prezi 02:32 - Richard Feldman Introduction Twitter GitHub NoRedInk 02:38 - Elm @elmlang 04:06 - Academic Ideas 05:10 - Functional Programming, Functional Reactive Programming & Immutability 16:11 - Constraints Faruk Ateş Modernizr The Beauty of Constraints Types / Typescript 24:24 - Compilation 27:05 - Signals start-app 36:34 - Shared Concepts & Guarantees at the Language Level 43:00 - Elm vs React 47:24 - Integration Ports lunr.js 52:23 - Upcoming Features 54:15 - Testing Elm-Test elm-check 56:38 - Websites/Apps Build in Elm CircuitHub 58:37 - Getting Started with Elm The Elm Architecture Tutorial Elm Examples 59:41 - Canonical Uses? 01:01:26 - The Elm Community & Contributions The Elm Discuss Mailing List Elm user group SF Stack Overflow ? The Sublime Text Plugin WebStorm Support for Elm? Coda grunt-elm gulp-elm Extras & Resources Evan Czaplicki: Let's be mainstream! User focused design in Elm @ Curry On 2015 Evan Czaplicki: Blazing Fast HTML: Virtual DOM in Elm Picks The Pragmatic Studio: What is Elm? Q&A (Aimee) Elm (Joe) Student Bodies (Joe) Mike Clark: Getting Started With Elm (Joe) Angular Remote Conf (Chuck) Stripe (Chuck) Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck) Understanding Comics: The Invisible Art by Scott McCloud (Evan) The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan) The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard) Rich Hickey: Simple Made Easy (Richard) NoRedInk Tech Blog (Richard)

02:27 - Evan Czaplicki Introduction Twitter GitHub Prezi 02:32 - Richard Feldman Introduction Twitter GitHub NoRedInk 02:38 - Elm @elmlang 04:06 - Academic Ideas 05:10 - Functional Programming, Functional Reactive Programming & Immutability 16:11 - Constraints Faruk Ateş Modernizr The Beauty of Constraints Types / Typescript 24:24 - Compilation 27:05 - Signals start-app 36:34 - Shared Concepts & Guarantees at the Language Level 43:00 - Elm vs React 47:24 - Integration Ports lunr.js 52:23 - Upcoming Features 54:15 - Testing Elm-Test elm-check 56:38 - Websites/Apps Build in Elm CircuitHub 58:37 - Getting Started with Elm The Elm Architecture Tutorial Elm Examples 59:41 - Canonical Uses? 01:01:26 - The Elm Community & Contributions The Elm Discuss Mailing List Elm user group SF Stack Overflow ? The Sublime Text Plugin WebStorm Support for Elm? Coda grunt-elm gulp-elm Extras & Resources Evan Czaplicki: Let's be mainstream! User focused design in Elm @ Curry On 2015 Evan Czaplicki: Blazing Fast HTML: Virtual DOM in Elm Picks The Pragmatic Studio: What is Elm? Q&A (Aimee) Elm (Joe) Student Bodies (Joe) Mike Clark: Getting Started With Elm (Joe) Angular Remote Conf (Chuck) Stripe (Chuck) Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck) Understanding Comics: The Invisible Art by Scott McCloud (Evan) The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan) The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard) Rich Hickey: Simple Made Easy (Richard) NoRedInk Tech Blog (Richard)

Get your Ruby Remote Conf tickets and check out the @rubyremoteconf Twitter feed for exciting updates about the conference.   03:09 - Evan Czaplicki Introduction Twitter GitHub Prezi 03:15 - Richard Feldman Introduction Twitter GitHub NoRedInk 03:42 - Elm @elmlang 04:18 - Elm vs JavaScript dreamwriter 06:52 - Reactivity 07:28 - Functional Principles Immutability Union Types 09:42 - “Side Effects” (Reactivity Cont’d) JavaScript Promises Signals React Flux Excel Spreadsheet Comparison Two-way Data Binding vs One-way 24:19 - Syntax and Semantics Haskell ML ML Family of Programming Languages Strict vs Lazy 30:45 - Testing Elm-Test elm-check Property-Based Testing elm-reactor 34:49 - Debugging Elm’s Time Traveling Debugger 42:12 - Next Release? 46:00 - Use Cases/Getting Started Resources elm-architecture-tutorial dreamwriter 48:45 - Why should Ruby devs care about Elm? Picks The Expanse (Avdi) Git LFS (Jessica) The City & The City by China Miéville (Jessica) Patterns (Coraline) Ruby Remote Conf (Chuck) Find a change of pace (Chuck) Listen to other people’s views (Chuck) Richard Feldman: Functional Frontend Frontier (Richard) EconTalk (Evan) elm-architecture-tutorial (Evan)

Get your Ruby Remote Conf tickets and check out the @rubyremoteconf Twitter feed for exciting updates about the conference.   03:09 - Evan Czaplicki Introduction Twitter GitHub Prezi 03:15 - Richard Feldman Introduction Twitter GitHub NoRedInk 03:42 - Elm @elmlang 04:18 - Elm vs JavaScript dreamwriter 06:52 - Reactivity 07:28 - Functional Principles Immutability Union Types 09:42 - “Side Effects” (Reactivity Cont’d) JavaScript Promises Signals React Flux Excel Spreadsheet Comparison Two-way Data Binding vs One-way 24:19 - Syntax and Semantics Haskell ML ML Family of Programming Languages Strict vs Lazy 30:45 - Testing Elm-Test elm-check Property-Based Testing elm-reactor 34:49 - Debugging Elm’s Time Traveling Debugger 42:12 - Next Release? 46:00 - Use Cases/Getting Started Resources elm-architecture-tutorial dreamwriter 48:45 - Why should Ruby devs care about Elm? Picks The Expanse (Avdi) Git LFS (Jessica) The City & The City by China Miéville (Jessica) Patterns (Coraline) Ruby Remote Conf (Chuck) Find a change of pace (Chuck) Listen to other people’s views (Chuck) Richard Feldman: Functional Frontend Frontier (Richard) EconTalk (Evan) elm-architecture-tutorial (Evan)

Get your Ruby Remote Conf tickets and check out the @rubyremoteconf Twitter feed for exciting updates about the conference.   03:09 - Evan Czaplicki Introduction Twitter GitHub Prezi 03:15 - Richard Feldman Introduction Twitter GitHub NoRedInk 03:42 - Elm @elmlang 04:18 - Elm vs JavaScript dreamwriter 06:52 - Reactivity 07:28 - Functional Principles Immutability Union Types 09:42 - “Side Effects” (Reactivity Cont’d) JavaScript Promises Signals React Flux Excel Spreadsheet Comparison Two-way Data Binding vs One-way 24:19 - Syntax and Semantics Haskell ML ML Family of Programming Languages Strict vs Lazy 30:45 - Testing Elm-Test elm-check Property-Based Testing elm-reactor 34:49 - Debugging Elm’s Time Traveling Debugger 42:12 - Next Release? 46:00 - Use Cases/Getting Started Resources elm-architecture-tutorial dreamwriter 48:45 - Why should Ruby devs care about Elm? Picks The Expanse (Avdi) Git LFS (Jessica) The City & The City by China Miéville (Jessica) Patterns (Coraline) Ruby Remote Conf (Chuck) Find a change of pace (Chuck) Listen to other people’s views (Chuck) Richard Feldman: Functional Frontend Frontier (Richard) EconTalk (Evan) elm-architecture-tutorial (Evan)