Podcasts about PureScript

Charles Scalfini, the CTO of Panoramic Software, makes the case for why programmers should make the leap to functional programming, which promises more maintainable code, and eliminates some of the problems inherent to conventional languages. 

大哥大嫂新年好！时隔九个多月，我们终于复播了（老父亲的眼泪）。 复播第一期的话题有些 hardcore：函数式编程。也许你偶尔会在各种场合听到这个词，那它究竟与传统的过程式、对象式编程有什么区别？这里的「函数」又与我们常见的函数有什么关系？它为什么又被许多人奉为全新且优秀的编程范式？ 当然，本期话题可以聊的东西实在是太多，本期节目姑且也是抛砖引玉。如果大家还希望我们来聊聊相关内容的话，欢迎留言告诉我们。 章节 00:00 开场寒暄 02:16 何为函数式编程？ 16:35 与函数式编程有关的语言 29:05 深入了解更多概念 36:44 吟唱魔法 40:53 尾声 相关链接 MesoTroniK（为 Echo.js 制作新的 intro / outro）的 SoundCloud 主页 (https://soundcloud.com/mesotronik) 和 Patreon 主页 (https://www.patreon.com/mesotronik)。 Haskell (https://www.haskell.org/)：函数式编程范式的「元汤化元食」之语言。 Ramda (https://ramdajs.com/)：在 JavaScript 中使用的函数式编程框架。 Fantasy Land Specification (https://github.com/fantasyland/fantasy-land/)：在 JavaScript 中实现函数式编程的规范。 PureScript (https://www.purescript.org/) 与 Elm (https://elm-lang.org/)：JavaScript 的超类，编写后可直接编译为 JavaScript 的语言。 白羊写的介绍 ADT 的文章 (https://github.com/lsby/ts_adt_tutorial/)。 关于 Echo.js & 联系我们 Echo.js 是一档关于编程与开发的播客节目。官网地址是 www.echojspodcast.com 。我们推荐使用支持 RSS 方式订阅（即「泛用型」）的播客客户端收听。 有话想说？你可以： 发到官网评论区 来小宇宙 app 订阅 Echo.js 并给节目发评论 加入听众反馈 QQ 群 (https://www.echojspodcast.com/qq)（白羊说进群可以教学编程，包教包会） 发邮件至 hello(a)astrianzheng.com 关注我们的：Telegram 频道 (https://t.me/echojspodcast) 获取本期节目转写文稿 （PDF 格式） (https://www.jianguoyun.com/p/DcHdr0UQxabKChjpjsUEIAA)

In today's episode, I talk about Why PureScript. You can find me here: Twitter: @codingedgar Instagram: @codingedgar Website: codingedgar.com

时隔两个月的更新，我们迎来新的 官网 (https://www.echojspodcast.com)、新的 会员计划 (https://www.echojspodcast.com/member) 和新的话题。从这期开始，我们拥有新的固定栏目：开源项目与文章摘要（暂定）；之后我们将大家写代码时的习惯、工具等等都拿了出来，看看究竟哪种最好用。 节目索引 00:00 开场 00:22 厚脸皮地来说说这两个月里的公告 03:20 新固定栏目：开源项目与文章摘要 15:53 大乱斗话题的由来 18:01 代码习惯大比拼 35:57 有 Lint，当然少不了 Linter 41:31 说脚到手架，两位 JS 程序员可就不困了 49:05 终于开始聊编辑器 01:01:16 最后来聊聊 GitHub Copilot 相关链接 06:07 - WeKan 开源看板工具 (https://wekan.github.io/) 07:42 - draw.io (https://draw.io) 08:50 - 数据绘 开源绘图工具 (https://github.com/zxhm001/DataDraw) 12:25 - How to win on CORS (https://jakearchibald.com/2021/cors/)：CORS 跨域限制机制是怎么来的，到底该怎么解决？ 19:05 - 维基百科中对「制表键」的定义 (https://zh.wikipedia.org/wiki/%E8%A3%BD%E8%A1%A8%E9%8D%B5)：键盘上俗称的 Tab 键正式名称叫「制表键」（tabulator key），它可以提供最大 4 长度（有些是 8 或是其他长度）的可变长度空格，在需要跨行进行列对齐（制表等场景）时非常好用而得名。白羊说「Tab 键本身就是做这种事的」是这个原因。 25:55 - JavaScript Map, Reduce, and Filter - JS Array Functions Explained with Code Examples (https://www.freecodecamp.org/news/javascript-map-reduce-and-filter-explained-with-examples/)：JavaScript 中操作数组常用的 map、reduce 和 filter 三个函数的解释。 29:26 - PureScript (https://www.purescript.org/) 30:17 - 中文编程了解一下 (https://www.echojspodcast.com/2)：我台以「在编程中使用中文」为话题的一期节目。 36:22 - EditorConfig (https://editorconfig.org/) 41:37 - Vue CLI (https://cli.vuejs.org/) 41:50 - Create React App (https://create-react-app.dev/)：两位主播都忘记叫什么名字的 React 脚手架。 44:07 - WebPack (https://www.webpackjs.com/) 44:12 - Next.js (https://nextjs.org/)（React）和 Nuxt.js (https://nuxtjs.org/)（Vue.js） 47:16 - Parcel (https://parceljs.org/) 01:01:16 - GitHub Copilot (https://copilot.github.com/) 01:02:37 - What does Copilot Mean for Open Source (https://opensource.org/copilotimpact)：开源组织在 GitHub Copilot 推出之后针对 AI 补全代码的合法性发文。 关于 Echo.js & 联系我们 Echo.js 是一档关于编程与开发的播客节目。官网地址是 www.echojspodcast.com 。我们推荐使用支持 RSS 方式订阅（即「泛用型」）的播客客户端收听。 有话想说？你可以： 发到官网评论区 来小宇宙 app 订阅 Echo.js 并给节目发评论 加入听众反馈 QQ 群 (https://www.echojspodcast.com/qq)（白羊说进群可以教学编程，包教包会） 发邮件至 hello(a)astrianzheng.com 关注我们的：Telegram 频道 (https://t.me/echojspodcast)、Twitter (https://twitter.com/twitter) COPYRIGHT DISCLIMER 开场/尾声音乐： Track: TOKYO MACHINE & Guy Arthur - GET UP [NCS Release] Music provided by NoCopyrightSounds. Watch: https://youtu.be/HV7mLcsUp5U Free Download / Stream: http://ncs.io/GetUp Play the Flappy Duck game: http://ncs.io/GetUp 奏间音乐： 来自北京干燥文化传媒有限公司。

Category theory may strike you as intimidating, but trust us, you can (and after this episode, are probably itching to) talk applicative functors and parser combinators over afterwork drinks. Listen in to learn why Esko and Antti – both of whom started programming with dynamically typed languages – are so into category theory right now that they see applications of it everywhere.GuestAntti Holvikari is endlessly fascinated by pure functional programming languages such as Haskell and PureScript. Software quality and personal productivity are two things he’s constantly improving.HostEsko Lahti is an engineer who always wanted to learn about category theory in practice – but never knew where to start. Then he met Antti Holvikari.Episode linksPureScript: https://www.purescript.org/Parser Combinators, a Walkthrough: https://hasura.io/blog/parser-combinators-walkthrough/fp-ts: https://github.com/gcanti/fp-tsio-ts: https://github.com/gcanti/io-tsAlgebraic Data Types: https://dev.to/gcanti/functional-design-algebraic-data-types-36kfDiscriminated Unions in TypeScript: https://basarat.gitbook.io/typescript/type-system/discriminated-unionsMaybe Not, a talk by Rich Hickey: https://youtu.be/YR5WdGrpoug

Still writing bespoke functions and boilerplate to immutably manipulate a complex data structures? Statically typed optics will both do the heavy lifting for you, AND give your TypeScript hustle an unforeseen boost.GuestPetri Lehtinen started programming with Basic in the mid-90s. Open source projects and functional programming in typed programming languages are close to his heart.HostEsko Lahti is an engineer who saw the light after first encountering the partial.lenses optics library in 2017. Episode linksoptics-ts: https://github.com/akheron/optics-tsMonocle: https://www.optics.dev/MonocleMonocle-ts: https://github.com/gcanti/monocle-tspartial.lenses: https://github.com/calmm-js/partial.lensescalmm.js: https://github.com/calmm-jsProfunctor optics: http://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/poptics.pdfA comprehensive study about different optic types: http://oleg.fi/gists/posts/2017-04-18-glassery.htmlAbout ReaktorFork Pull Merge Push is a podcast by Reaktor, a strategy, design and technology company changing how the world works. Reaktor has offices in New York, Amsterdam, Stockholm, Tokyo, Helsinki, Turku and Tampere.Reaktor is always on the lookout for bright software developers to work in health, security, emerging technologies, and much more. See www.reaktor.com/careers.@ReaktorNow#FPMPod

РОЗЫГРЫШ книги в первом комментарии! Почему TypeScript - трата времени, Flow чуть получше, но все равно победил ReasonML? Про сильные стороны и фейспалм. Видео версия https://youtu.be/nZDN6XCM1X0 Антон Тужик, Frontend Developer из SEMrush рассказывает про год использования ReasonML в продакшене. 00:00 - Вступление 00:33 - Из геолога в программисты. Курсы, книги, подкасты 11:39 - Как и почему уходили от Javascript 13:20 - Почему выбрали Flow, а не TypeScript 16:25 - Что такое Soundness 19:45 - Как типы изменили тестирование 24:18 - Как Flow показал себя 26:52 - Поиск альтернатив: Elm, ClojureScript, ReasonML, Purescript, Dart 30:57 - ReasonML - это отдельный язык? 31:32 - Зачем извратили OCaml? 32:49 - OCaml и Javascript 35:34 - Что такое BuckleScript 38:07 - Javascript на выходе, хорош ли? 47:36 - Про фейсбук и OCaml 50:34 - Чем хорош OCaml 51:36 - Причины почему ReasonML 52:20 - Interop и монадки 53:58 - Скорость разработки на ReasonML 54:34 - Как затащили ReasonML в компанию 56:23 - Рынок ReasonML 01:00:47 - ReasonML подхватывается командой 01:01:52 - Аннотации и вывод типов 01:04:00 - Кривая обучения ReasonML 01:09:53 - Про модули в ReasonML и OCaml 01:16:41 - Сколько месяцев на изучение? 01:20:59 - Hegel лучше или хуже ReasonML 01:25:38 - Инструменты ReasonML и интеграция 01:31:21 - ReasonML в компании 01:32:37 - BuckleScript и ReScript 01:42:30 - Как так вырасти за 4 года 01:47:16 - Самообразование и баланс работы

Many of you are probably using TypeScript in your daily work. And why not, types make our code safer and tooling can help us more. But from time to time you probably encounter some weird behaviour of the type system that you cannot fully understand. This week I want to explain the foundation of the type system of TypeScript and also contrast it a bit with other languages like PureScript. Presenter - Jan van Brügge

Many of you are probably using TypeScript in your daily work. And why not, types make our code safer and tooling can help us more. But from time to time you probably encounter some weird behavior of the type system that you cannot fully understand. This week I want to explain the foundation of the type system of TypeScript and also contrast it a bit with other languages like PureScript. Presenter - Jan van Brügge

GUEST BIO: My guest on today’s show is a functional programming advocate.  He has worked in the IT industry for more than 15 years in a variety of roles including software support, development lead, project management and systems analysis. He is the co-founder of the Knoxville Functional Programmers group and is currently a senior consultant for Result Stack. EPISODE DESCRIPTION: Phil’s guest on today’s show is a functional programming advocate called Reid Evans. He started his IT career 15 years ago, working mainly in software support. Since then he has moved on and worked as a development lead, a project manager and systems analyst. Today is a senior consultant for ResultStack. In 2017, he co-founded Functional Knox Inc. and is currently the president. The group supports a network of functional programmers by organizing meetups and via an annual conference. KEY TAKEAWAYS: (1.07) – So firstly, I wanted to pick up with you could you perhaps tell us a little bit about the Knoxville functional programmers group and what your involvement was with setting it up? Reid explains they have been operating as a hangout for 3 or 4 years. But, in 2018, they hosted their first conference, which was a great success. The 2019 conference was even bigger and even more successful with speakers traveling in from all over the US. (2.02) – Is this an annual event and why did you decide to set it up? Reid responds by explaining that both himself and the co-founder of the group Cameron Presley had been speaking at conferences for a while. They enjoyed doing it but found that they had to keep things fairly rudimentary to deal with the fact the audience had mixed skills. Both of them felt it would be beneficial to deliver talks that went a bit beyond the basics. So, they decided to address that gap and start their own group and conference. They wanted a place where people could come together and discuss things that were slightly outside of the mainstream. (2.54) Presumably, the focus is very much on functional programming? Yes, that is very much the case, but FuctionalKnox events are very diverse. For example, this year’s conference covered Haskell, Purescript, C#, Javascript, Typescript and much more besides, across 12 sessions. (3.38) – So, are you planning future events? Reid says yes, for sure. There is a lot of demand for this kind of conference. So, they will be arranging more. But, these events are not just for speakers with decades of experience. This year, 2 of the speakers had only just completed boot camp. It is clearly a form of education that works because they had a similar level of knowledge as someone who had been programming for years would have. Something Reid finds very encouraging. Becoming a programmer is now far more attainable. New people have not had to learn how to follow the traditional object-oriented way of working. Instead, they have gone straight into functional programming and been able to learn quickly because they have not had to unlearn other ways of working. (6.00) – Can you please share a unique career tip with the I.T. career audience? Reid’s advice is not to let people put you into a singular box. You need to expand your horizons and learn more than one thing. If you do not, you stagnate and it is really easy for someone to replace you with another programmer who has more or less the same skill set as you. If you can move a JIRA ticket across the board, don’t stop there. Learn some design and UX patterns too. He also points out that becoming a good communicator is a good way to progress your career. It is something that sets you apart. (7.06) – Is this something you have done yourself? Reid explains that his path into development was an unusual one. For a while, he was technically a vice president of a small software support company. In that role, he started to do a bit of software writing. When he started programming, he was shocked to find that he was expected to simply take the ticket and move it across the board. Adding anything or making suggestions to improve things was generally not welcome. Basically, his bosses did not want him asking questions. Now, he works as a consultant he gets to go in and actively ask questions. It is the only way to find out what the problems actually are. Reid believes that without knowing why you are doing something it is all easy to get cynical about anything you are developing. When you feel like that you do not do good work. (8.44) – Can you tell us about your worst career moment? And what you learned from that experience. That happened when Reid joined a team that had already been working on a huge project, for 10 years. It was massive. Reid, along with everyone else, spent months in a little cubical blindly creating their bits of code. Finally, it was delivered to the customer. Unsurprisingly, it was a total disaster. Basically, they ended up delivering a system that offered the customer virtually nothing new. The old system did everything the new system did. Worse, the new system took much longer to carry out each process than the old one did. It was stuffed full of needless code. At some point, people had got it into their heads that they could not ask questions. As a result, the project had drifted badly off course. When it comes to software design, you need to be able to ask the right questions to make sure you build the right solution. (11.27) – What was your best career moment? Reid could not nail down a specific highlight. But, he explains that he finds working with and helping others to be incredibly fulfilling. It feels great to be able to get someone who has been stuck for ages, unstuck. It is these micro wins that keep Reid engaged and happy working in the industry. In those situations, you have much more control than when you are working on some huge project. You can see that you have made a positive difference. (13.08) – Can you tell us what excites you about the future of the IT industry and careers? Reid is very excited by the fact that functional programming opens up the opportunity for new developers to make a big impact at a very early stage in their careers. It is great to see enthusiastic new developers being inspired by the work they are doing. The fact that there are so many new languages emerging is also exciting. With so much choice, it is possible to quickly find a solution to practically any issue. Developers just need to be willing to let go and move on to something new, when the need arises. They should never let a single language define them. Fortunately, the more languages you learn the easier it becomes to learn the next one. Each new one you learn gets you thinking in a slightly different way. This makes you a much better programmer and improves your ability to find your way through any coding challenge. (15.53) – What first attracted you to a career in IT? Reid was at music school and working as a cook. But, he wanted to quit. When he told his dad this, he invited him to work for him answering the phones at his software firm. Reid agreed and discovered that he loved the IT world. (16.36) – What is the best career advice you have ever received? That is – “don't seek feedback from someone you wouldn't ask their advice? Reid wishes he had been told that early in his career. He feels he would have got a lot further if he had. (17.04) - Conversely, what is the worst career advice you've ever received? Someone once told Reid to follow the money and not worry about what type of work he was doing. The rationale was that there is plenty of time to enjoy yourself after work. In reality, that is terrible advice. It is all too easy to end up spending a significant percentage of your week doing something that makes you miserable. You need to find a job that pays enough, but, you also have to enjoy doing it. (18.31) – If you were to begin your IT career again, right now, what would you do? Reid would put himself through a boot camp. This despite the fact he has a bachelor’s degree. The environment in a good boot camp is great. You are surrounded by people striving to do the same as you. Plus, more importantly, the boot camp staff are highly motivated to help you to find a job. Following the boot camp route gets you out there really fast. The best way to learn anything is to do it rather than spend 4 years learning with relatively little doing. (19.29) – What are you currently focusing on in your career? Reid says he loves helping people, so that is one of his focuses. His consulting work and FunctionalKnox role both feed into this objective. But, he is also moving into being a consultant for other consultants. He is having a great time doing that. (20.15) – What is the number one non-technical skill that has helped you in your IT career? Reid jokes that is his superpower of asking dumb questions. Phil responds by saying there are no dumb questions, which Reid agrees with. Reid goes on to say that he has asked so many dumb questions in his life that he is no longer afraid of looking silly. As a consultant, one of his roles is asking questions. He has learned to preface them by saying – “this may be a dumb question, but...” He finds that this helps people to understand that he is asking questions to seek understanding, not as a way to quietly challenge them. (22.30) - What do you do to keep your own IT career energized? Attending conferences and speaking to other programmers both keep him energized. Talking about things you are passionate about always feels great regardless of the platform you do it from. (23.02) - What do you do in your spare time away from technology? Reid says that he spends a lot of time with his family and also enjoys running and cycling. He describes himself as a suboptimal triathlete. Physical exercise enables him to unburden his mind, so he can start each workday feeling good and able to look at things from a fresh perspective. Running is particularly good for this. On a tempo run, after about 20 minutes he is able to switch off to the point where all he is thinking about is putting one foot in front of another one.  (24.41) – Phil asks Reid to share a final piece of career advice with the audience. Reid’s advice is to find a place where you are respected. He goes on to point out that the easiest way to gain respect is to give it. When you do that your working relationships become a lot easier. BEST MOMENTS: (2.46) REID – "We wanted a place where people could come together and share ideas that were maybe slightly outside of the mainstream." (6.25) REID – "If you let people put you in a box, they will gladly do so." (10.44) REID – "You need to be able to ask the right questions to make sure you build the right solution.” (15.03) REID – "The more languages you learn, the easier it is to learn the next one." (16.47) REID – "Don't seek feedback from someone you wouldn't ask for advice?" (20.24) PHIL – "There are no dumb questions." CONTACT REID: Twitter: https://twitter.com/reidnevans LinkedIn: https://www.linkedin.com/in/reidevans/ Website: https://medium.com/@reidev275

Jason Fry and Taylor Fausak compare frontend and backend languages, including PureScript and Elm.

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

On this episode of the Bike Shed, Chris is joined by Josh Clayton, thoughtbot's managing director in our Boston studio. Chris and Josh spend the episode discussing the various patterns and trends they see in the world of web development. Specifically, they touch on server side frameworks like Ruby on Rails and Phoenix in the Elixir world. In addition, they discuss a variety of front end trends including the move towards typed languages like ReasonML, TypeScript, Elm, PureScript, and Scala.js, as well as frameworks like React, Ember, Angular, and Vue.js. Bike Shed 20 w/ Josh Clayton: Intentionally Excruciatingly Painful Google Lighthouse Beyond React 16 by Dan Abramov - JSConf Iceland AirBnB Moving Away from React Native Josh Steiner - Elm native UI in production Announcing Purple Train ReasonML Elm TypeScript PureScript Scala.js Software disenchantment blog post 166: Are Services the New Rewrite? Apollo Client Vue.js Thoughtworks Technology Radar Parcel Bundler Terser javascript minifier Rufo - Ruby autoformatter

It's time to talk about Functional Programming. Chris Bimson hosting, with Gabriele Cipriano, Richard Wild, and Jorge Gueorguiev Garcia given their opinions We mention briefly the books: Purescript by Example by Phil Freeman and Functional Programming in Scala by Paul Chiusano and Runar Bjarnason. Photo: Prairie Dog by DigiPD is licensed under CC0Music: "Sweeter Vermouth" by Kevin MacLeod is licensed under CC-BY 3.0

Stephan Ango, Co-founder and Head of Product at Lumi, discusses merging creative and scientific mindsets in industrial design, the logistics of packaging, developing custom solutions by slowly replacing 3rd party tools, and building your ideal culture while balancing operational needs. Lumi Inkodye PureScript PureScript and Haskell at Lumi Well Made Podcast Shipping Things "1,000 True Fans"- Kevin Kelly Stephan on Twitter See open positions at thoughtbot! Become a Sponsor of Giant Robots!

Purescript is a functional programming language that compiles to javascript.  It is a strict haskell dialect that can run anywhere that javascript does. Justin Woo is a self described Purescript evangelist and enthusiast. We talk about purescript vs elm and working with expressive type systems.  Justin also had some great metaphors about phantom types and masking tape as well as avacados and testing.   Contact Justin: twitter github website Show notes: Purescript purescript training videos     My team at Tenable is hiring.  We are a distributed team of scala developers working on static analysis of docker containers (among other things). We are a team of smart people, working fairly autonomously on interesting problems.  We are one of many teams working on interesting problems at Tenable.  I think its a great place to work. I am in Peterborough, in Canada, and our team has people working in the US, Ireland and the UK as well. Here is the job posting:  https://www.linkedin.com/jobs/view/586241797/ Tell them Adam sent you, or you can email me directly at work abell at tenable.com or use this link to apply.

In this episode I talk with Claudia Doppioslash. We catch up with what she has been doing since Episode 42, which includes PureScript and Elm, GRiSP, applying functional ideas to game programming, and more.

Panel: Andrew Jaim Erica In today's episode,  the iPhreak panel speaks with  Stephen about how Swift could benefit from higher level types like in Haskel, Reactive programming and testing in the Kickstarter app. Stephen is a software engineer living in Brooklyn, New York. He previously helped build and open source the Kickstarter mobile apps. He's a co-founder of Point-Free , a consultancy and upcoming educational video series on functional programming and Swift. In particular, we dive pretty deep on: Open Source Language Renaissance Higher Types Maps & Arrays Functional & Reactive Programming Swift Swift as a gateway to functional programming Future features in Swift? What can you do with higher level types? How has application development evolved Declarative State is back! Programming by contract Testing Testing timecode Unit Testing Examples of testing code from Kickstarter app Point Free https://www.pointfree.co/ Picks: Jaim: Realm  Andrew: Cities Skylines Advent of Code Erica Anti-pick High Sierra missing Network Diagnostics App Stephen Reducers Purescript Test Driven Reactive Programming  

Panel: Andrew Jaim Erica In today's episode,  the iPhreak panel speaks with  Stephen about how Swift could benefit from higher level types like in Haskel, Reactive programming and testing in the Kickstarter app. Stephen is a software engineer living in Brooklyn, New York. He previously helped build and open source the Kickstarter mobile apps. He's a co-founder of Point-Free , a consultancy and upcoming educational video series on functional programming and Swift. In particular, we dive pretty deep on: Open Source Language Renaissance Higher Types Maps & Arrays Functional & Reactive Programming Swift Swift as a gateway to functional programming Future features in Swift? What can you do with higher level types? How has application development evolved Declarative State is back! Programming by contract Testing Testing timecode Unit Testing Examples of testing code from Kickstarter app Point Free https://www.pointfree.co/ Picks: Jaim: Realm  Andrew: Cities Skylines Advent of Code Erica Anti-pick High Sierra missing Network Diagnostics App Stephen Reducers Purescript Test Driven Reactive Programming  

Julie Moronuki: @argumatronic | argumatronic.com Show Notes: 00:57 - Julie's Unique Origin Story Into Programming 03:47 - Good Resources vs Bad Resources for Learning Haskell 11:18 - Areas to Look at Before Taking on Haskell and Functional Programming 15:56 - Terminology 17:50 - The Haskell Pyramid 25:51 - Learning Haskell Vocabulary 28:20 - Monoid and Functor 42:06 - Advice for Someone Who May Not Be Interested in Programming Resources: Haskell Programming From First Principles (Haskell Book) Natural Language Processing (NLP) Learn You a Haskell for Great Good! Programming in Haskell by Graham Hutton Haskell: The Craft of Functional Programming by Simon Thompson Real World Haskell by Bryan O'Sullivan, John Goerzen, and Don Stewart Introduction to Functional Programming Course with Eric Meijer The Joy of Haskell Haskell eXchange 2017 - A Monoid For All Seasons Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 83. My name is Charles Lowell, a developer here at the Frontside and your podcast host-in-training. With me today on the podcast is Elrick also. Hello Elrick. ELRICK: Hello. How you doing? CHARLES: I'm doing well. I'm glad to have you on this one. I'm glad to be doing this podcast in general. We have someone on the podcast today who I've been following for, I guess probably about two years because she published a book that has been very, very helpful to me. It's one that I recommend to a lot of people. It is learning Haskell from first principles. With us on the show is Julie Moronuki, who is co-author of that book. Thank you so much, Julie for coming. JULIE: Yes, hi! Happy to be here. It's nice to finally get to talk to you. CHARLES: Yeah. One of the reasons I wanted to have you on the podcast was because I feel as though you have one of the most unique origin stories because of programming and entering in the tech world. Most of us are curious, we either come from video games or maybe we just start fiddling with the web browser. You enter the maze from the entrance that is like hidden from all, I would say. You went straight to writing a book on Haskell, is that --? JULIE: That is what happened. In 2014 on Twitter, I met my co-author, Chris Allen and he has been trying to figure out better ways to teach people Haskell because the on-ramping, I guess of people to Haskell can be quite difficult. The materials that exist are not always accessible and people felt like they need the advanced math degrees before they can write Haskell. He was trying to figure out better ways to introduce people to it. Since I was this person who's never programmed before -- I have no background -- and then he thought, "This will be a very different experience, trying to teach Haskell to her." Because I have a linguistics background and stuff he thought, "That would be interesting too and maybe, she'd be interested eventually in doing NLP." I said, I'm not -- CHARLES: What's that? Acronym alert. JULIE: Oh, yeah. Sorry. Natural Language Processing. I said, "You know, I've never done any programming and I don't play video games and I never have had any desire to learn computer programming. I don't think I'm going to like this. I don't think this is going to last but sure, I will try," and so I did a little bit. I read a little bit of 'Learn You a Haskell for Great Good.' I've read some other things. CHARLES: This was before you guys had the idea of actually writing a book. JULIE: Yes. He had the idea of turning some of his thoughts about teaching Haskell into a book and as he would explain things to me, like the questions I had about 'Learn You a Haskell,' I'd be like, "We should write this down," and he would say, "It's so hard to write it though. It's easy when I'm explaining it to you and it's so hard to write it." Initially, it started that I was helping him at things that he was teaching me and then as we got further into the book and I started reading a lot of other Haskell stuff on my own and figuring stuff out, I was writing more and more of it. Then we were kind of equal co-authors after not too long. That's how it happened. I really didn't think that I would stick with Haskell or with programming. I'm still sometimes I'm not sure about programming. I'm not sure about this whole making software thing. But Haskell is so interesting to me that I'm still here. CHARLES: That is fantastic and it's a great story. I'm curious, when you were doing the proto-research to learning Haskell, coming from really truly first principles and having no experience of programming, what made a good resource versus a bad resource? What are the things that you gravitated towards and say, "This is really instructive." What was the tone there? JULIE: One of the major problems ahead of most of the Haskell resources that exist is they assume that you've done programming before because nobody learns Haskell as a first language so they all assume that you have done some programming before. They would make references to things that if you were a programmer, you would know what they meant but I didn't. That was one of the hardest things for me. Even 'Learn You a Haskell' does that to some extent. CHARLES: What's an example of that? JULIE: I had learned a little bit about recursion from linguistics because that's a thing in human language so I really understood recursion but most of the Haskell resources explain it to you primarily in terms of, "This will be like your loops in other languages." I'm going to be like, "I don't know what a loop is. This isn't helpful for me." There are a lot of things that I didn't understand so when people talk about Haskell as being a pure functional language, neither pure nor functional necessarily, I didn't have anything to contrast them with so they didn't necessarily make sense to me as things that make Haskell different from other languages. I didn't know what imperative programming was and people would say, "In contrast to imperative programming, functional programming does this," and I'd be like, "Okay, but I don't understand what the imperative programming way is so this contrast isn't making any sense to me and same thing with purity." There were a lot of things I had to learn, in fact about mutable state because I didn't know anything about it. I had some understanding of how computer memory works but still some of the ways that people talk about it were not obvious to me. CHARLES: Do you find that seeking out that contrast actually wasn't helpful? Is it noise since at least at the beginning, it's something you'll never do. It's like saying, "Over in France, they wear these kind of socks." Since I'm going out into the street in front of my house, I don't really care. JULIE: Right. In the beginning, it was a lot of noise and I understand why they do that because they are making the assumption that everybody who is learning Haskell has come from some other programming language, probably an imperative one so I understand why that happens but in the beginning, it was very much noise for me. I noticed a lot of Haskell resources, one of the first things they tell you is that in Haskell you can't do 'x = x + 1'. I was like, "If I'm reading this like it's mathematics, why would I think I could do that." If you come from a different programming language, you might well think that you can do that but in Haskell, we can't so making that contrast, when I didn't have that background was really just confusing for me. Now, because I teach people and most of them do have some background in an imperative language, understanding the contrast is more helpful to me but in the beginning it was just confusing and noise. When we wrote Haskell book, we tried not to make those kinds of references and like, "Let's assume that everybody is just like Julie, doesn't know a different programming language that we can contrast it with and let's try to write a book like that." CHARLES: Right. I think that's a key insight because some people would say there's a lot missing or that difference might stand out. Now, that you pointed out, I can see it but I don't think I noticed it while I was reading it. But one of the things that I like is because I also tried to learn Haskell through 'Learn You a Haskell,' and I didn't find it very helpful. I found it entertaining and it's not a knock against the authors. Some of the sketches were really cute but it was still more explaining... I don't know. It was explaining more of the how, than the why, if that makes any sense where I felt as though in your book, there were a lot more analogies to actual human experiences, using the visceral language saying, "A mono is something you can mash together or squeezed together." That really connected for me. Whereas, explaining it in terms of concatenation and laws and stuff like that. Those things seem cited to the secondary resources to the primary resource. JULIE: Yeah. I think that's kind of helpful for me too. There are different Haskell books that have, I think different things about them that are good. I forget the name of the book but Graham Hutton's book, the way he talks about recursion was really helpful to me. The way he explains recursion and of course, folds but folds are things that he's known for so those parts of that book are helpful for me. But really the best book other than my own of course, for me is Simon Thompson's. I think it's called ‘The Craft of Functional Programming' and I think it does better at explaining things just in terms of Haskell. Real World Haskell, I guess is really good. It was harder for me because I hadn't been a programmer before. I think it's got so many practical exercises that -- CHARLES: Was that the O'Reilly book by Irish gentleman whose name eludes me? JULIE: Yes, Brian O'Sullivan. It makes more sense to me now but there were things in it that are sort of programmer things. Because I'd never made software before, that were really confusing for me. But Simon Thompson's, because his book does have exercises and they were ones that I could understand and do. They were fairly self-contained. My first experience actually in writing a program that does IO was from his book and I was just so thrilled. I was like, "I got it. I did it." That was really helpful book for me but I don't see people recommend that one as often but that was probably the best one for me. CHARLES: Yeah, it's always a balance because the Real World Haskell didn't really worked for me, almost because the examples were too pragmatic or too complex and I picked this up when I was 10 years into my programming career and I struggled to follow the JSON parser example, which is parsing JSON is something that I've actually done several times in multiple languages and I still struggled with it. JULIE: Whereas for me, I don't even know what JSON is. This is not something I've ever dealt with. I know what it is now sort of, but it's still not something that I deal with very much. I was just like, "What is this? I don't even know what to do here." It wasn't quite as helpful for me. I've heard a lot of people have success with that one but I think they don't share quite the same richness of programming experience with Brian O'Sullivan. I think it's a little bit more difficult. ELRICK: These are a lot of amazing resources that I wish I knew about when I try to learn Haskell. I took an online course with, I think it's like Eric Meijer and that class was very intense. Looking back, what would you say are some areas that someone should, either start to look into before they step into the Haskell world, being that you didn't come from a programming background but connecting to dots backwards now? What would you say are some areas that people can slowly ramp up into to get into Haskell and functional programming? JULIE: When I teach people Haskell, the people who have the easiest time are people who have been writing Scala for a while and they've moved over to the FP in Scala side. When I first started Haskell, I heard a lot of people make jokes about how Scala is a gateway drug to Haskell. I think there's actually might be so truth in that because I certainly have a lot of students that were Java programmers, then they got interested in Scala because maybe Scala is better for some things than Java and then they start moving more and more over to the FP in Scala side. Those are probably the students that have, I think the easiest time making the transition to Haskell that I've had anyway. But you know, I think even JavaScript, trying to write in a more functional style and there are some resources for that and really, there's a very good tutorial about monads that uses all the code examples in JavaScript. I think a lot of the concepts that you can start to approach them from other languages. Haskell is still going to be weird in a lot of ways and another thing that works for a lot of people is going to Elm. Elm is similar to Haskell but different. I think that that has worked also for a lot of people getting them into understanding more functional programming concepts but with the much easier... The word easy is so -- ELRICK: It's like a relative term like, "Oh, this is easy." JULIE: It is. CHARLES: Easy to say, right. ELRICK: That's what I thought when I step into learning Haskell and functional programming. I was like, "How bad could it be?" JULIE: Right. Learning Haskell can be very bad. I'm not going to kid around about that. It's a shame because I don't think that it needs to be that bad but the way it's presented oftentimes, for various reasons, I think why Haskell gets presented the way it does but I don't think it needs to have it like that. The designer of Elm, whose name I'm not going to try to pronounce because I don't know how you say his last name, he really made an effort to for example, the error messages in Haskell can be very intimidating. The situation there has improved since I started learning Haskell but they can be quite intimidating and he really made an effort to make very friendly error messages, very helpful error messages. I think that it shows and then it makes a difference for people who are learning. If you start with Elm and then you do want to see what Haskell or PureScript, which is also frontend language, mostly. It compose of JavaScript but it's very Haskell-like, then from Elm, let's see if we can get a little more hardcore Haskell. I think the transition to Haskell or PureScript is easier from there. I think it does help to move in the functional direction from whatever language you're in, if you do FP in Scala or try moving to more functional JavaScript or even Elm. Then Haskell will make it more sense from there or be a little easier to approach. CHARLES: Yeah, and I definitely think that for, at least from my perspective, I've been able to take a lot of those concepts that I've learned from Haskell and then apply them, even inside Vanilla JavaScript. There are things that have become indispensable like mapping and folding and they exist in JavaScript. You can reduce arrays, which is a similar to a fold and then you can map arrays but understanding that map, the key insight for me that I got from learning Haskell is that there's a whole class of values that you can map, not just arrays. The standard JavaScript object is essentially a Functor and will get a little bit to that because for people listening what that word even means and the meta around the fact that they're all these weird words and how do I go about something I want to ask you about. But the trees can be mapped and the objects can be mapped and all of the sudden, it's like this one concept that I use so much for lists, it's available on all these different data structures and it's get me thinking like, "What other data structures can I use this operation? What are the things are Functors that I'm working with?" Really, it's changed my perspective to think about the type of the data structure, in terms of the operations. JULIE: I'm in favor of keeping the terminology that we have but just explaining it much better. That's the approach that I take but it can be very hard, especially it was your first learning Haskell. I don't know if you've seen the Haskell pyramid but to get sort of productive where you can write programs in Haskell is not a very high bar. It feels like it is when you first start but it's not really very high bar but Haskell just keeps growing and growing and getting deeper and deeper so you're always approaching new libraries that you've never seen before and you feel then you've been learning Haskell all over again because they're written in a very different style of Haskell or they have even more terminology, even more kinds of Functors that you've never heard of before or something like that so you're always approaching these things over again. It can be a very intimidating feeling and it makes a lot of people very uncomfortable and I'd say, if you like Haskell and that does make you feel uncomfortable, then you don't actually need to do that because a lot of people write Haskell very happily every day in their jobs even and don't do that. They don't mess with some of the newer, super cool libraries that have all this funky terminology and stuff. Some of them don't mess with them at all. CHARLES: But certainly, there is some concepts that are core. I'm thinking of like applicative and Functor and all these things that I'm learning about and I'm curious to hear about your experience as you climb that pyramid. What is the pyramid entailed? First of all, I'd love to hear more about it because this is actually the first time I heard about the Haskell pyramid. JULIE: Say you understand monads, then you can write really a lot of Haskell programs. Probably at some point, you will need to understand monads transformers but if you just get to the point where you understand monads pretty decently, you can write a lot of software so after that, then learning more is maybe going to improve your Haskell, maybe let you write some things that you couldn't write before but a lot of it above, not that these things are necessarily in an hierarchical progression. We cover monad transformers in a fair bit of detail in Haskell book but if you get anything beyond what's in Haskell book, one of those things that some of them are very interesting, some of them can make you much more productive but some of them are also people do them for fun to explore the space and some people love them and some people hate them. Haskell lets you do a lot of things for fun and exploring mathematics in ways that are interesting and exciting and may influence and in fact, have influenced other languages like [inaudible] in PureScript but not really necessary for basic Haskell programming. A nice thing happened while we're writing Haskell book. I was writing, I think it's chapter six, which is about type classes. I was writing that chapter and at the same time, my co-author had started writing the Monoid chapter. The type classes chapter comes in chapter six and we introduce a lot of the basic type classes: num and eq and some of those in that chapter because I do think it's important. Type classes are very special thing about Haskell so I think it's important to, at least start coming to groups at them early. Some people disagree with me about that and think they can ignore them for much longer. But at any rate, it is where it is and I felt that that was important. Maybe the real motivation for type classes, really until we started writing the Monoid chapter so he started writing that while I was working on type classes chapter and he sent me the beginnings of the Monoid chapter to look at. At first I thought, "We've got addition and multiplication and list concatenation and this just doesn't seem interesting. What is this generalization of a Monoid that I'm supposed to get from these three things? And why bother making it a type class," because additional and multiplication are already in the num type class and then list concatenation is just for list so why make this into a type class and what's that motivation there. With eq, we want a quality -- CHARLES: Is that how you pronounce 'eq?' JULIE: That's how I pronounce it because 'equal' or equality. CHARLES: Okay, so this is a type class for doing what? Making sure to being able to compare two values on the same value. JULIE: Yes and it's a weird one because for most data types, you can have an eq instance and you want probably, in a lot of cases to have that but we don't want because function is a data type in Haskell so you don't want to have an eq instance for functions and that's why equality is not implemented generally for everything. That's why it's a type class so there's no instance for functions because that's not decidable. You can't decide if two functions are equal, generally. Some functions you can but in the general terms, for datatype, you can't. CHARLES: That's actually a pretty profound statement. Proof of which is left as an exercise for the listener. JULIE: We got to the Monoid and I was like, "What is the [inaudible]," or something. It turns out that there are Monoids everywhere. There's all kinds of things that you want to, either concatenate or make a product of. Then having this as a type class and thinking of it in terms of like, "We've got this abstraction. We've got this category. We've got this algebraic structure. Now, we can look for in all these other places," because once you've named the thing, then you can talk about it and think about it in a little bit of the different way. It's like, "Now, we've got this group of addition, multiplication, list concatenation." Now, we've got an abstraction of that and we can think, "Where else can I see this pattern?" and it turns out it's all over the place. For me, that was one of our thought like, "Type classes are actually really cool and powerful and interesting thing." For me, that was when it seemed like, "The terminology is worth it because, now I want to think about finding these algebraic structures and in all these other places." CHARLES: Right and like a Monoid, it could essentially be called, if you're using a Java interface, like 'mashable togetherable' or 'concatenatable' or something like that. But there's a kind of one-to-one correspondence but it is a vocabulary that just needs to be learned. JULIE: I don't know much about category theory or anything but the other cool thing about Monoid for me was that there are almost always two because there's almost always one that's destructive or additive or concatenative and there's almost always one that is conjunctive or a product or multiplicative. It's often across product that would be the zipless Monoid that exist in base and it's a cross product of the two lists. There's almost always two, whereas when you think of Monoids in the very abstract looking category theory, it doesn't matter if it's addition or multiplication. The operation doesn't matter, whether it's addition or multiplication or concatenation or cross product because you generalize the actual operation to the extent where what it's going to produce. It doesn't matter anymore. For me, I still think of Monoids in terms of like set theory or Boolean Algebra, then that's one of the things that I think is difficult with Haskell where people talk about Monoids in terms of category theory but I think that's not very helpful for the actual programmer who has to actually deal with the two different instances like sum and products or concatenation and zipping are going to actually act different in a program. CHARLES: Right, they're going to yield a different set of values. JULIE: Yes. CHARLES: Is there a baseline vocabulary? I kind of think of it like learning a new language, right? JULIE: Yep. CHARLES: When you're learning Haskell, you're not just learning a new language. You're literally learning a new language. I could go and I could learn Japanese but it's going to be a struggle at some point. People say certain languages are hard and certain language are easy. I don't generally subscribe to that. I think that most of it is just going about and living in a place where they speak this language and you'll absorb it and it's the decision to go and live there -- that's kind of the primary one. But let's say, you're a foreigner and you're travelling to this country called Haskell that's got this strange language. Like other human languages, it's just got different names associated with different concepts and some of the concepts might even just be unique to that country. Just like when you're travelling and acquiring a human language, there's a certain level of vocabulary that you need to achieve before you can do things like buy groceries and be able to transact financial exchanges or have a conversation about the weather. What are the kind of the levels of vocabulary that you need to acquire to be operational in Haskell or I would say, even in functional programming because now that I've been exposed to this, I see it in Clojure. I actually see people doing this JavaScript and in Erlang, in Elixir and what have you. JULIE: Yeah, I don't really know how to answer this question. How to buy groceries in Haskell? CHARLES: Let me let scale that down because I had this horrible tendency to spend five minutes asking what I say is going to be single question but it's actually like 30. Let's take down the scope. When you were learning this vocabulary, at what point did you feel like you're really gaining traction? We're you really starting to connect the dots? JULIE: For me, I think when I got through Functor. It was when I felt like -- CHARLES: Functor and what comes before Functor? JULIE: Monoid. I think once you understand Monoid and Functor, then a lot of other concepts in Haskell will start falling into place because this is not obvious to everyone but I think once you really understand Monoid and once you really understand Functor, then applicatives are monoidal Functors and that's not obvious to everyone. Like I said, it's not obvious at first certainly, and monads have characteristics of both Monoid and Functor as well. Then you start saying, "There's all these other Functors. There's profunctors and bifunctors. I think once you really understand Monoid and Functor, a lot of the rest of Haskell starts falling into place and then type classes like alternative. Alternative is another kind of Monoid. We have all these other names that if you can see the general pattern of Monoids and Functors, I think to me anyway, a lot of it then just started falling into place. Applicatives to me seemed, I don't want to say obvious or simple but in traverse, it's same sort of thing so we have these other names for it -- traversable -- and I was like, "Why was it called traverse. I don't understand this word at all." But once I saw the type signature and what actually happens with what the function traverse does, I was like, "Okay, I see what's happening here." For me, those were the two big hills. Once I got through Monoid and Functor and really understood them well, then a lot of other stuff just come and fell into place for me. ELRICK: This is really interesting. How was a Monoid explained to you when you were first starting to learn Haskell? Then now, how do you explain what a Monoid is to someone that's learning Haskell? JULIE: When Monoid was first explained to me, it was the pattern of there's addition and multiplication and list concatenation so it generalize out that pattern and that was really hard for me to understand at first because list concatenation and addition are similar but multiplication is different. I was like, "What do these three things have in common?" What they have in common is that they take two values of a certain type and return another value of that type and that's the type signature of the main function, that's in the Monoid type class. But that doesn't really tell you very much. A lot of functions could do that, in theory at least. How you combine them is really what's interesting about Monoid and also what makes concatenation and addition different from multiplication. Fortunately in college, I had had a fair bit of exposure to Boolean Algebra so figuring out that like, "There's actually two basic genres or varieties of Monoid and they are disjunctive or additive or they are conjunctive or multiplicative," and figuring that out, to me I always think that Monoid should really be, maybe two different type classes, one for the additive Monoid like list concatenation and addition and things where you are adding two things like a set union. Then conjunctive, which would be this intersections or multiplication or cross products. I always think there's maybe should be two different type classes but there's not a good way to do that really in Haskell. Instead, we have this one type class and then we do this ugly business of wrapping them in different type names. CHARLES: Is that why you'll have a constructor for some so it's just a wrapper for an integer? JULIE: Yeah. CHARLES: I don't know if that's so bad. JULIE: I don't like it but -- CHARLES: Yeah. You know what? You do a lot more than I do so I'm going to take your word for it. JULIE: Yeah, that's exactly why. Sum and product are the wrappers for integers because integer doesn't have a Monoid. It has two Monoids over it. CHARLES: I see. There's lots of ways to combine integers. JULIE: Yeah and those are the two basic ones. Then because Monoids also have an identity so with semi-groups, then you get even more semi-groups for integers because you get max and min, because they don't have an identity so there's semi-groups. CHARLES: There's always risk getting down into the weeds with the vocabulary but I think that there's a message here because your answer to the question is really, "When I understood Monoid and I understood Functor," from that point on, the overhead that you had to expend to get other things was lower than the overhead that you had to expend to get those initial two things. For anyone listening, Monoid and Functor are probably opaque terms. You have no idea what the hell they mean. We've been talking about in things like that a little bit but then it's okay because they're a finite set of opaque terms and they're very achievable and once you can achieve those, then you've done 90% of the work and now, you're just combining them into interesting and novel ways. JULIE: Yes. I will say it that a lot of people do tell us about Haskell book that applicative is actually the hardest chapter in the book, not monad but applicative. CHARLES: Really? JULIE: Yeah. A lot of people do tell us that. Because that's the first time that you've taken the concept of Monoid and the concept of Functor and combining them into a new thing so then, once you've done that with applicative, then after that, really it's all downhill. CHARLES: Right. It seems like there's a couple of key insights. As you're climbing that hill, I like that analogy is like one, just understanding that there things like type classes so you've through attacking Monoid and through attacking Functor, you realize, "There is such a thing." By recognizing there is such a thing as a Functor, you recognize that there is the potential for other type classes like it. Then through combining it with Monoid, to get applicative, you can see, "I can actually compose these things into new instances of those things," and then that's either the crest of the hill or the Pandora's box, depending on which way you look at it. I think there's a hopeful message in there that if you can invest the time to learn these opaque terms and making them transparent to you, you can really, really, really lean heavily on that knowledge in going forward. JULIE: Yeah. I'm writing a new book now called 'The Joy of Haskell.' The idea of The Joy of Haskell is meant to be an intermediate book. For people who already know some Haskell but we want to make words like Functor more general, like in Haskell book we really focused on the type class called Functor when it's actually a concept from mathematics or actually originally from linguistics oddly enough but we really focused on the type class in there, rather than trying to explain what a Functors are generally. In the new book, in The Joy of Haskell, we're going to try to take a lot of these terms like Monoids and Functors and catamorphisms and all these other words that Haskell has used all the time and try to explain them generally. Then also give examples like interesting uses from different libraries and stuff like that. It'll service both, hopefully a guide to the vocabulary of the Haskell ecosystem and also some documentation and examples for libraries and things like that that are useful because these things do have uses. They do get used in interesting and exciting or terrifying -- maybe those are related -- ways. That's the goal of the new book is to try to make a guide to all of this vocabulary that Haskell use all the time. We're trying to do that. How do I explain Monoids, you asked. You've got two values of whatever type. It doesn't matter the type and in general, there would be two ways you can think of to combine them, either making a sum or a union of all the values in them or making some product of those values, if they contain multiple values or even if they only contain one. That's how I explain them now. I'm not certain that addition and multiplication are actually the best ways to start with that because addition and multiplication don't act quite like set union and intersection do. I'm actually thinking of them in terms of and this is how I explain monoids to the people now, I start from set theory and that sounds really heavy but it doesn't have to be because I think a lot of things about sets are -- CHARLES: They're very intuitive, especially if you have visuals. JULIE: They're very intuitive, for people to think about. Yes, exactly. I explain Monoid now more in terms of set union and intersection. I'm actually giving a talk in October. It's coming up in just a couple weeks at Haskell eXchange in October 12th and 13th in London and I'm giving a talk there called 'A Monoid For All Seasons' and I'm going to try to explain the theoretic motivation for Monoids and try to explain them in those terms. Semi-group is a little bit different because lacks the identity but I'll try to explain the alternative type class and monad plus this really the same thing as alternative. These things are also just Monoids so we have these different names because it's a different type class alternative but it's really just another kind of Monoid. I'm giving that talk about set theory in Monoids in October, in a couple of weeks. People keep asking me on Twitter, "What's your obsession with Monoids," because my name on Twitter is Monoid Mary so I try to explain why I love them so much. CHARLES: Actually, it's an awesome point, which I've just gotten to experience it is what you see like, "Oh, there are these abstract things," you start searching for them. A lot of times, you'll uncover them and it'd be a real timesaver. There's the thrill of unearthing it in the first place and then when you could say, "Now that I've identified this thing as a Monoid, there's so much less that I have to write." There's like less work that I have to do. It's the same reason that we write frameworks for ourselves in software. It's like, "We love Ruby on Rails because of all the work we don't have to do." Now, you have to expend a lot of energy to work with it, using Rails an example but there's lots of software frameworks. It's like, "If you can find a good persistence framework or you can find a good thing for making a library for handling HTTP requests and responses, why would you write it all by hand in the first place?" I think the thing that's exciting for me as a developer is being able to see, "Monoid is a thing. Functor is a thing and I can now actually use this and I can use it almost as a looking glass to explore the world around me. When I see something in the landscape that just leaps out through that lens is another great one." I've been on a big kick lately but being able to say, "This is going to save me so much time because of the thoughts that I don't have to think and the code that I don't have to write." I think connecting it back to the pragmatic, I certainly have become really obsessed, maybe not about Monoids but having a type class large in your mind. JULIE: I think it's a really powerful thing. Sometimes that jargon is really useful. It's useful in a sense that it like compresses a bunch of information into a single word to remember. It's like teaching my eight-year old multiplication and we were talking about like, "It's like addition," and for us adult, I'll just go ahead say, "It's associative and commutative," but showing him that you can do those things and that addition is like that too and we're talking about that and he was so excited to learn that there's this word 'commutative' that encapsulates this idea for both concepts so he doesn't have to think like, "Addition does this thing. Multiplication does this thing." He doesn't have to remember both of those things, like he just remembers, "Commutative and they're both like this." It kind of compresses that information and what you have to remember and think about. Then it does make it easier to see that pattern in other things, then we can find commutativity in other things because now we have this pattern that we can look for and we got a name for it. We can talk about it and really, there's a lot of stuff like that in Haskell where we find some pattern that we find useful or we want to be able to talk about or easily translate to a bunch of different types, not translate is quite the right word but you know what I mean, I think. Then we give it a name and we make type class for it and then it's, "Now, we find it even more place for us." CHARLES: Right. It's about thinking less, right? JULIE: Yeah. CHARLES: That's a big misconception is that it's not about thinking more, it's about thinking less. JULIE: It really is. I think it's because there's so much kind of upfront work, where you have to learn all this new stuff upfront, then people mistake that for how much work we're always doing but in Haskell it's like, "We did all this work upfront and now we're now we're not going to think about these things anymore." ELRICK: That sounds like a good title for a book, 'Learn Haskell and you will think less," but it's true. When I struggled through that online class, I came out of that just being able to pick up any functional programming language and just hit the ground running. It is definitely a plus and you will think less. JULIE: Yeah, in the long term, I think that you do. Haskell is not a perfect language. There are things that probably can be improved. CHARLES: Now, before we go, I wanted to ask you, having had this very unique on-ramp into programming, which apparently you're still not convinced about. I'm curious what it would take to actually convince you but the real question that I have is there any advice that you have for someone who does not have a stereotypical background in programming who may not think that they would find programming interesting, who might have any number of roadblocks in terms of their own conceptions about the path forward. What advice would you have for them? JULIE: I am a bit joking when I say that I'm still not sure about writing software. I don't feel like I'm good at it and I think this is really the key. There are a bunch of domains in programming that I don't personally care about. I don't want to make web apps and I have nothing but respect and admiration for people who do. To me, it's very, very hard. CHARLES: Mostly because our tools aren't the same. JULIE: Yeah and there's just so many things outside your own program, there are just so many things that you have to think about and deal with because there's the network and there's other people's computers and they might be doing in other people software and what it might be doing. It is insane so for me it's very hard. There's a lot of domains of programming that I don't care about and when I thought about programming, that's the kind of thing I would think about. I certainly knew a lot of people who are web developers or the common programming jobs, I guess. Some of them just weren't that appealing to me and I'm not interested in making games or graphics so those are the kinds of things that I thought about for programming. There are things though that I am interested in doing. I'm very interested in natural language processing and I guess that's related to machine learning. I've recently taken up an interest in things like the raft protocol, the consensus protocol. Those kinds of things interest me a lot and there's a lot of the theory that interests me. I'm reading a dissertation right now about implementing a non-strict lambda calculus, which is what Haskell is. It's a non-strict lambda calculus and this guy's dissertations are theoretically implementing a non-strict lambda calculus. To me, the theoretical side is really interesting but then I am also interested in certain kinds of software. For some reason, I have developed quite an interest in making Twitter bots. I think that the advice I would give -- I'm rambling a little bit -- to people who think they're not interested in programming so why should they learn or whatever, is just find the thing that you are interested in and there's probably a way you can make software for that and maybe that will be the thing that will get you interested. It might not be Haskell, maybe you are interested in making web apps, in which case I would say go for Elm or PureScript, obviously because I like functional programs but Haskell might not be the best first language for you in that case but find the thing that you're interested in and there probably is a way to write software to do that. There's probably something in programming that will interest you. It's such a vast field. CHARLES: All right. I really, really like that answer. ELRICK: Yeah, that's a beautiful advice. Find your domain. CHARLES: Yeah, it's bigger than you think. JULIE: It's much bigger than you think. CHARLES: And there is a place for you. Thank you so much for coming on the show, Julie. I really, really, really enjoyed our conversation. JULIE: Yes, so did I. This is a lot of fun. CHARLES: Thank you. Now, before we go, I understand that you are going to be in London, was it roughly very, very soon, you said you were giving a talk. JULIE: Yes, the 12th and 13th of October. It will be recorded for people who can't get in. It will be recorded, I believe. CHARLES: You will be talking on 'A Monoid For All Seasons.' JULIE: Yes. CHARLES: And then you've also got The Joy of Haskell book, which you're hacking away right now, right? JULIE: Yes. CHARLES: With that, thank you so much for both of you. Thank you all for listening. What's a good place for people to reach out for you? JULIE: If they're on Twitter, I'm very active on Twitter so I'm @argumatronic on Twitter and my blog is also Argumatronic and that has more contact information. CHARLES: Fantastic. We'll link to those in the show notes. For everybody else, thank you for listening. You can get in contact with us at @TheFrontside on Twitter and Contact@Frontside.io over email. We'd love to hear from you. This just in, we're running a special. If you go to our website and enter the promo code 'ELRICK20,' you can get that 20% discount on your next custom developed web application. Go check that out. Take it easy, everybody. Bye-bye. JULIE: Bye-bye.

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction  What Functional Language Should I Learn  Eric Steven King, On Writing  Youtube Channel: Tested   Charles Ionic Framework Links Purely Functional TV  Blog  Building Composable Abstractions 

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction  What Functional Language Should I Learn  Eric Steven King, On Writing  Youtube Channel: Tested   Charles Ionic Framework Links Purely Functional TV  Blog  Building Composable Abstractions 

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction  What Functional Language Should I Learn  Eric Steven King, On Writing  Youtube Channel: Tested   Charles Ionic Framework Links Purely Functional TV  Blog  Building Composable Abstractions 

In this episode I talk with Justin Woo. We talk his introduction to functional programming; the transition from ClojureScript to Elm to PureScript for side projects; the appeal of PureScript; evangelizing PureScript and more.

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.

Ramon and Passy work on the official Twitter for iOS and Twitter for Android apps respectively. After a rather long break, they're back and discuss the workflow that's used at Twitter to bring you those apps. Topics Ansible for server provisioning. Scaleway cloud hosting. PureScript. FFI Chapter in "PureScript by Example" by Phil Freeman. Workflow For Large-Scale Mobile Applications No, we won't link to Jira here. Or Basecamp. Or Pivotal Tracker. Sorry. Gerrit for code review. OWNERS approval plugin for Gerrit. Yes, this stuff is actually written in Prolog. Crashlytics Beta for dogfooding. Jenkins for CI. Picks Ramon: YakYak Open Source Google Hangouts desktop client. Passy + Ramon: Mr Robot Season 2 Ramon: No Man's Sky by Hello Games Passy: Episode 189 and Episode 225 of JavaScript Jabber with Phil Freeman and John De Goes. Passy: Dell XPS 13 9530 Developer Edition About Ramón Argüello on Twitter Pascal Hartig on Twitter Strictly Untyped on Twitter Music Outro jingle - Ramón Argüello

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

03:08 - John A. De Goes Introduction Twitter GitHub Blog SlamData 04:07 - PureScript JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman 04:58 - “Purely Functional” 09:18 - Weaknesses With Functional Programming Object-oriented Programming Procedural Programming 14:36 - Organizing a FP Codebase John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started Learning About the History of Functional Programming Hiring Junior Devs to do FP 28:20 - The Rise of Functional Programming in JavaScript-land 32:08 - Handling Existing Applications 36:03 - Complexity Argument 41:53 - Weighing Language Tradeoffs; Alt.js Picks Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee) React Rally (Jamison) Cleanup Algorithm (Jamison) PostgreSQL Exercises (Jamison) iPad Pro (Chuck) Smart Keyboard for iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) John A. De Goes: Halogen: Past, Present, and Future (John) slamdata (John)

03:08 - John A. De Goes Introduction Twitter GitHub Blog SlamData 04:07 - PureScript JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman 04:58 - “Purely Functional” 09:18 - Weaknesses With Functional Programming Object-oriented Programming Procedural Programming 14:36 - Organizing a FP Codebase John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started Learning About the History of Functional Programming Hiring Junior Devs to do FP 28:20 - The Rise of Functional Programming in JavaScript-land 32:08 - Handling Existing Applications 36:03 - Complexity Argument 41:53 - Weighing Language Tradeoffs; Alt.js Picks Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee) React Rally (Jamison) Cleanup Algorithm (Jamison) PostgreSQL Exercises (Jamison) iPad Pro (Chuck) Smart Keyboard for iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) John A. De Goes: Halogen: Past, Present, and Future (John) slamdata (John)

03:08 - John A. De Goes Introduction Twitter GitHub Blog SlamData 04:07 - PureScript JavaScript Jabber Episode #189: PureScript with John A. De Goes and Phil Freeman 04:58 - “Purely Functional” 09:18 - Weaknesses With Functional Programming Object-oriented Programming Procedural Programming 14:36 - Organizing a FP Codebase John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started Learning About the History of Functional Programming Hiring Junior Devs to do FP 28:20 - The Rise of Functional Programming in JavaScript-land 32:08 - Handling Existing Applications 36:03 - Complexity Argument 41:53 - Weighing Language Tradeoffs; Alt.js Picks Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee) React Rally (Jamison) Cleanup Algorithm (Jamison) PostgreSQL Exercises (Jamison) iPad Pro (Chuck) Smart Keyboard for iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) John A. De Goes: Halogen: Past, Present, and Future (John) slamdata (John)

In this episode I talk with John De Goes. We cover his introduction to functional programming, reasons for starting a functional programming conference, evolution of LambdaConf, what to look forward to at LambdaConf 2016, the choice to pick PureScript at SlamData, and more.

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)

Check out and sign up for Ruby Remote Conf! 02:09 - Jafar Husain Introduction Twitter GitHub Netflix TC39 02:42 - Falcor @falcorjs Netflix JavaScript Talks - Falcor 06:56 - MVC (Model View Controller) Separation of Concerns 17:41 - Performance REST Lazy Loading 34:23 - Angular 2 Asynchronous Binding Data Access Patterns Picks Land of Lisp: Learn to Program in Lisp, One Game at a Time! by Conrad Barski, M.D. (Lukas) Stevie Wonder: 1-2-3 Sesame Street (Lukas) Visual Studio Code (Ward) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Wool by Hugh Howey (Chuck) MediaWiki (Chuck) PureScript (Jafar)

Check out and sign up for Ruby Remote Conf! 02:09 - Jafar Husain Introduction Twitter GitHub Netflix TC39 02:42 - Falcor @falcorjs Netflix JavaScript Talks - Falcor 06:56 - MVC (Model View Controller) Separation of Concerns 17:41 - Performance REST Lazy Loading 34:23 - Angular 2 Asynchronous Binding Data Access Patterns Picks Land of Lisp: Learn to Program in Lisp, One Game at a Time! by Conrad Barski, M.D. (Lukas) Stevie Wonder: 1-2-3 Sesame Street (Lukas) Visual Studio Code (Ward) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Wool by Hugh Howey (Chuck) MediaWiki (Chuck) PureScript (Jafar)

Check out and sign up for Ruby Remote Conf! 02:09 - Jafar Husain Introduction Twitter GitHub Netflix TC39 02:42 - Falcor @falcorjs Netflix JavaScript Talks - Falcor 06:56 - MVC (Model View Controller) Separation of Concerns 17:41 - Performance REST Lazy Loading 34:23 - Angular 2 Asynchronous Binding Data Access Patterns Picks Land of Lisp: Learn to Program in Lisp, One Game at a Time! by Conrad Barski, M.D. (Lukas) Stevie Wonder: 1-2-3 Sesame Street (Lukas) Visual Studio Code (Ward) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Wool by Hugh Howey (Chuck) MediaWiki (Chuck) PureScript (Jafar)

We chat with Rob Ashton, freelance developer, speaker and recent discoverer of how to learn things properly, live on stage during Øredev 2014. Topics include learning, the plateaus of learning and how to actually do things right to keep evolving and learning. The problems of frameworks wanting to make X easy. Perhaps we should learn about programming in general instead of learning the next big framework in the hope that it will solve our problems without us needing to understand them? This recording exists as good as it is thanks to Stephen Chin of nighthacking.com for providing and masterfully wrangling all the necessary technology. Comments, thoughts or suggestions? Discuss this episode at Techworld! Links Rob Ahston Rob’s keynote from At the frontend Haskell Clojure Rob’s good use of the guitar Strumming Deliberate learning Refactoring to to functional - talk at Øredev by Hadi Hariri Datagrid Winforms ATS Erlang Prolog Recursion Fold Haskell generator functions Polymorphism gen_server MUD You are in a maze of twisty little passages, all alike Latency Macros in MUDs Wizards in MUDs Angular Angular 2.0 talk Haskell is lazy Web forms npm - the Node package manager React Om Clojurescript REPL Flux - Facebook’s architechture style used by them with React Ember Bash AWK SED Purescript Cloud Haskell Docker Titles I haven’t got an elevator pitch for myself at the moment I’ve become a real person living in the real world It has changed the way I approach learning I just build software every single day Tangible and listenable A transformative moment Fingerpicking and scales Competent throwing things together I wouldn’t say my day job betters me Why am I learning this crappy pointer stuff Deliberate learning Easy by virtue of travelling the hard way My day job is mostly Erlang with a hint of C Erlang is acutally incredibly boring Lisp with horrible syntax Things that mutate in the background The world becomes a happy place I’ve started writing a MUD in Haskell And then you die in the next scene A problem that noone has anymore It’s good for you imagination Factory providers and god knows what else Hate’s a very strong word The framework ain’t gonna help you Shortcutting problems I don’t do prescriptive Preferable to gouge my eyes out with a spoon That “wonderful” is sarcastic It was an abomination If there is such a thing as good C Transcoding and cloud nonsense That’s because you skipped the learning step Copying and pasting things off of the internet Shuffling piles of binary around the place