Podcasts about monads

In this episode we cover "Locked doors, headaches, and intellectual need" by Max Kreminski. This article outlines the concept of problem-solution ordering issues and how they are the reason no one understands monads. We soon realize these problem-solution ordering issues are everywhere, and figuring them out is the key to true teaching.Here's the article Joe mentioned that does a way better job of explaining monads than he did: Functors, Applicatives, and Monads in Pictures.We decided to cover this article based on a wonderful user comment by @cebamps (gently) calling us out for our flippant take on functional programmers. Thank you so much for writing in!

Fredrik talks to Pedro Abreu about the magical world of type theory. What is it, and why is it useful to know about and be inspired by? Pedro gives us some background on type theory, and then we talk about how type theory can provide new ways of reasoning about programs, and tools beyond tests to verify program correctness. This doesn’t mean that all languages should strive for the nirvana of dependent types, but knowing the tools are out there can come in handy even if the code you write is loosely typed. We wrap up with some further podcast tips, of course including Pedro’s own podcast Type theory forall. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Pedro Type theory Type theory forall - Pedro’s podcast Chalmers The meetup group through which Pedro and Fredrik met Purdue university Bertrand Russell The problem of self reference Types Set theory Kurt Gödel Halting problem Alan Turing Turing machine Alonzo Church Lambda calculus Rust Dependent types Formal methods Liquid types - Haskell extension SAT solver Property-based testing Quickcheck Curry-Howard isomorphism Support Kodsnack on Ko-fi! Functional programming Imperative programming Object-oriented programming Monads Monad transformers Lenses Interactive theorem provers Isabelle HOL Dafny Saul Crucible Symbolic execution CVC3, CVC5 solvers Pure functions C# Algebraic data types Pattern matching Scala Recursion Type theory forall episode 17: the first fantastic one with Conal Elliot. The discussion continues in episode 21 Denotational types Coq IRC Software foundations - about Coq and a lot more The church of logic podcast The Iowa type theory commute podcast Titles Type theory podcasts Very odd for some people Brazilian weather Relearning to appreciate The dawn of computer science Layers of sets Where types first come in Bundle values together The research about programming languages If you squint your eyes enough Nirvana of type systems Proofs all the way down Extra guarantees If your domain is infinite Formal guarantees The properties of my system What is the meaning of my program? Building better systems

Summary In this conversation, Jordan and Sophia discuss various topics including Sophia's background, her interest in functional programming and category theory, her experience with Kung Fu and philosophy, and her work at NuBank. They also touch on the challenges of teaching and learning, the importance of creating a supportive environment for growth, and the impact of different cultures on learning and programming. Keywords Sophia Velten, functional programming, category theory, Kung Fu, philosophy, NuBank, teaching, learning, growth, culture Takeaways Sophia's diverse background in programming, philosophy, and martial arts has influenced her approach to learning and problem-solving. She emphasizes the importance of creating a supportive environment for learning and growth, recognizing that different people have different ways of thinking and learning. Sophia's work at NuBank includes the development of libraries like Stateflow and Nodely, which aim to improve code quality and maintainability. She believes in the power of functional programming and the use of monads to separate pure code from side effects. Sophia's experiences with philosophy and Buddhism have shaped her perspective on life and learning, helping her to embrace the limitations of human knowledge and focus on personal growth. References https://github.com/nubank/state-flow https://github.com/nubank/nodely https://peter.gillardmoss.me.uk/blog/2023/10/10/on-forests-and-factories/ Sound Bites "Once you slip monads into things, it's controversial." "The atomic and a lot of our stack is not something that is familiar to many people." "Learning is growth. Growth is uncomfortable. Growth is hard."

Apoya a ELDT: paypal.me/LibroTobias Immanuel Kant es particularmente conocido por desplegar un sistema filosófico que revolucionó la teoría del conocimiento y la metafísica modernas, dando paso a una nueva forma de entender el mundo. Pero las inquietudes morales y políticas también estuvieron presentes en su pensamiento, siendo centrales en obras como la «Crítica de la razón práctica», publicada en 1788, o «La fundamentación de la metafísica de las costumbres», de 1785. Canciones: • “The Skeptic Song” de The Monads • “Kantian Ethics Song ” de Mrs Benson Revision Presentación, dirección, edición y montaje: Asier Menéndez Marín Diseño logo Podcast: albacanodesigns (Alba Cano) Escucha el episodio completo en la app de iVoox, o descubre todo el catálogo de iVoox Originals

Fredrik is joined by Emil Privér and Leandro Ostera for a discussion of the OCaml ecosystem, and making it Saas-ready by building Riot. First of all: OCaml. What is the thing with the language, and how you might get into it coming from other languages? The OCaml community is nice, interested in getting new people in, and pragmatic. And it has a nice mix of research and industry as well. Then, Leandro tells us about Riot - an experiment in bringing everything good about the Erlang and Elixir ecosystems into OCaml. The goal? Make OCaml saas-ready. Riot is not 1.0 just yet, but an impressive amount has been built in just five(!) months. Emil moves the discussion over to the mindset of shipping, and of finding and understanding good ideas in other places and picking them up rather than reinventing the wheel. Leandro highly recommends reading the code of other projects. Read and understand the code and solutions others have written, re-use good ideas and don’t reinvent the wheel more often than you really have to. Last, but by no means least, shoutouts to some of the great people building the OCaml community, and a bit about Emil’s project DBCaml. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Emil Leo Leo on Twitch Previous Kodsnack appearances by Emil Riot Sinatra Backbone.js Ember.js Angularjs React Erlang Tarides - where Leandro currently works OCaml Robin Milner - designer of ML Caml Javacaml F# Imperative programming Object-oriented programming Pure functions and side effects Monads The OCaml compiler Reason - the language built by Jordan Walke, the creator of React Standard ML React was prototyped in Standard ML Melange - OCaml compiler backend producing Javascript OCaml by example The OCaml Discord The Reason Discord Rescript Jane street High-frequency trading The Dune build system Erlang process trees Caramel - earlier experiment of Leandro’s Louis Pilfold Gleam Algebraic effects Continuations Pool - Emil’s project Gluon Bytestring Atacama - connection pool inspired by Thousand island Nomad - inspired by Bandit Trail - middleware inspired by Plug Sidewinder - Livewire-like Saas - software as a service DBCaml Johan Öbrink Ecto Mint tea - inspired by Bubble tea Autobahn|Testsuite - test suite for specification compliance Serde - Rust and OCaml serialization framework S-expressions TOML Dillon Mulroy Metame - community kindness pillar welltypedwitch Sabine maintains ocaml.org OCaml playground OCaml cookbook - in beta, sort of teej_dv ocaml.org Pool party Drizzle SQLX SQL Join types (left, inner, and so on) dbca.ml internet.bs The Caravan Essentials of compilation Reading rainbow Titles Few people can have a massive impact Impact has been an important thing for me It’s a language out there A very long lineage of thinking about programming languages Programs that never fail The functional version of Rust Melange is amazing This is not a toy project Yes, constraints! Wonders in community growth Arrow pointing toward growth Programs that don’t crash A very different schoold of reliability Invert the arrow Very easy on the whiteboard Multicore for free An entire stack from scratch Built for the builders A massive tree of things Make OCaml saas-ready Leo is a shipper Standing on the shoulders of many, many giants Learn from other people I exude OCaml these days Sitting down and building against the spec You just give it something Your own inner join We build everything in public The gospel of the dunes

Pinch me! The fabulous Diana Cooper is here to have a conversation about the state of the world as we know it, and the future of humanity as she was shown it with her new book, The Golden Future. Collectively, we are in the midst of a global awakening. Humanity is waking up to the higher truth. The truth in Who We Are. The truth in What We Are. We are Spirit. We are One. And we are better together. Diana and I talk about the collective consciousness rising in frequency as people individually start to recognize that which we are... Spirit. Love. One. A spark of the divine. The planet is in the midst of ascension, rising from third dimension to fifth dimension. The process might look chaotic. It might feel painful, scary and hopeless at times. But we must hold the vision of the golden future of us...of humanity. And in surrendering to what is in trust, the angels and many others are assisting us to in usher our planet into living in global peace and oneness. Join her as she along with many others connect with the intention to raise the frequency of the world on 22 October, 2023. When enough people merge with their Monads we can precipitate humanity and the planet into the Golden Future. Do please be part of this. WHEN ALL OUR MONADS MERGE TOGETHER IT WILL ILLUMINATE THE ENTIRE UNIVERSE. The Intergalactic Council has confirmed. This is the most important happening since the Cosmic Moment of 2012. IT IS A HISTORIC DAY Diana Cooper is a spiritual teacher, international speaker, author of 34 books translated into 28 languages and producer of many card decks. Diana's Website Diana's Instagram Diana's Facebook Diana's YouTube

We get nice and deep explaining the complexities of soul fragments and how they make understanding dieties and past lives so complicated. Ever heard of Monads, Sparks, and Personalities? Get your spiritual schooling on as we explain some spiritual knowledge 101 style. Also, a look into a vision Cristy had on crystal children and an explaination as to why spiritual workers charge money for their services.To follow Jada Lynn https://www.tiktok.com/@aphroditesinatlantis?is_from_webapp=1&sender_device=pcTo book a private session with Cristy cristynicole369.comTo follow her on socials https://www.facebook.com/cristynicole369https://www.instagram.com/coach_cristynicole/https://www.tiktok.com/@cristy.nicole?is_from_webapp=1&sender_device=pcTo follow Greg and get all the info on his first single Press Start follow https://linktr.ee/iam_mus1c

In this episode, Conor and Bryce chat with Ben Deane and Tristan Brindle about C++Now 2023!Link to Episode 130 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the GuestsBen Deane has been programming in C++ for this whole millennium. He spent just over 20 years in the games industry working for companies like EA and Blizzard; many of the games he worked on used to be fondly remembered but now he's accepted that they are probably mostly forgotten. After getting more interested in modern C++, in the teens he started giving internal company talks and then talks at various conferences, spreading ideas about types, algorithms and declarative and functional techniques.Tristan Brindle a freelance programmer and trainer based in London, mostly focussing on C++. He is a member of the UK national body (BSI) and ISO WG21. Occasionally I can be found at C++ conferences. He is also a director of C++ London Uni, a not-for-profit organisation offering free beginner programming classes in London and online. He has a few fun projects on GitHub that you can find out about here.Show NotesDate Recorded: 2023-05-16Date Released: 2023-05-19ADSP Episode 24: C++Now 2021 with Ben Deane & Tony Van EerdADSP Episode 29: From Papa John's to Google (Part 1)ADSP Episode 58: Otto & Eric Niebler! (Part 1)Conquering C++20 Ranges - Tristan Brindle - CppCon 2021libc++C++NowBen Deane Talk PlaylistC++Now 2018: Ben Deane “Easy to Use, Hard to Misuse: Declarative Style in C++”Sean Parent's C++ SeasoningDeclarative thinking, declarative practice - Kevlin Henney - Meeting C++ 2017CppCon 2016: Ben Deane “std::accumulate: Exploring an Algorithmic Empire”C++Now 2023: Calendrical C++: std::chrono, History, Mathematics and the Computus - Ben DeaneC++Now 2023: Speeding Date: Implementing Fast Calendar Algorithms - Cassio NeriLeap YearsC++Now 2023: Applicative: the Forgotten Functional Pattern - Ben DeaneC++Now 2019: Ben Deane “Identifying Monoids: Exploiting Compositional Structure in Code”C++Now 2023: What is Low Latency C++? (Part 1) - Timur DoumlerMonoids, Monads, and Applicative Functors: Repeated Software Patterns - David Sankel - CppCon 2020Intro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download: http://bit.ly/l-miss-you

What is the fundamental element of reality? In 1714 Leibniz published the Monadology and gave a very interesting answer to this question. There he argued that a non-physical part less basic substance called a Monad was indeed the fundamental element of reality. Tune in to learn more about Monads and see if you think Leibnitz was on to unlocking one of the oldest metaphysical quandaries. You can find a free copy of the Monadology here: https://www.plato-philosophy.org/wp-content/uploads/2016/07/The-Monadology-1714-by-Gottfried-Wilhelm-LEIBNIZ-1646-1716.pdf Image Attribution: By Christoph Bernhard Francke - Herzog Anton Ulrich-Museum, online, Public Domain, https://commons.wikimedia.org/w/index.php?curid=53159699 Send your questions, comments, and ideas for future episodes to eggtimerphilosophy@gmail.com

Functional programming, it seems you either love it or you hate it. But, like everything in software engineering, it is a trade-off. So for today, let's focus on the good, the bad, and the ugly parts of Functional programming.GuestsAlejandro Serrano, Software Engineer at 47 Degrees, author of "Practical Haskell", "The Book of Monads", and "FP Ideas for the Curious Kotliner"https://serranofp.com/https://twitter.com/trupill https://www.linkedin.com/in/alejandroserranomena/ Deepu K Sasidharan, JHipster co-lead, Java Champion, Staff Dev Advocate @ Okta, Java, JS, Rust, Cloud Native Advocate, Author, Speakerhttps://twitter.com/deepu105https://mastodon.social/@deepu105 https://deepu.tech/ https://www.linkedin.com/in/deepu05/ Podcast Host: Ties van de Venhttps://www.tiesvandeven.nl/https://twitter.com/ties_venhttps://www.linkedin.com/in/ties-van-de-ven-a24480a/Producer: Frank Delporte https://twitter.com/FrankDelporte https://foojay.social/@frankdelporte Linkshttps://foojay.io/today/7-functional-programming-techniques-in-java-a-primer/ (Deepu)https://foojay.io/today/the-problem-with-functional-programming/ (Ties)https://www.baeldung.com/java-functional-programming Content00'00 Intro00'17 Introduction of the guests07'40 What is functional programming (FP)?11'50 The same problems exist in FP and Object Oriented Programming13'50 Academic approach to programming17'54 Who of the guests is a FP purist?22'25 Understand the “Why”? Why use FP?28'11 The costs of FP30'57 When to learn FPhttps://www.baeldung.com/java-monads42'43 What is the future of FP?50'41 Outro

This interview was recorded at GOTO Amsterdam 2022 for GOTO Unscripted. gotopia.techRead the full transcription of this interview hereSander Hoogendoorn - CTO at iBood.comKevlin Henney - Consultant, Programmer, Keynote Speaker, Technologist, Trainer & WriterDESCRIPTIONIn most cases, there is more than one way to solve a problem. Based on our evolution, however, we are tempted to solve problems by adding features, code, and complexity.There is an alternative to that, though. Kevlin Henney and Sander Hoogendoorn discuss these attempts in this GOTO Unscripted episode recorded at GOTO Amsterdam 2022. A good starting point is to reevaluate the way in which we do things and try to eliminate the complexity that software developers are attracted to.RECOMMENDED BOOKSSander Hoogendoorn • This is AgileKevlin Henney & Trisha Gee • 97 Things Every Java Programmer Should KnowKevlin Henney • 97 Things Every Programmer Should KnowHenney & Monson-Haefel • 97 Things Every Software Architect Should KnowGerald M. Weinberg • Becoming a Technical LeaderLee, Wickens, Liu & Boyle • Designing for PeopleSam Newman • Monolith to MicroservicesRonnie Mitra & Irakli Nadareishvili • Microservices: Up and RunningTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily

James Wakefield joined Coop and Taylor to discuss his chapter in the recently released Dune and Philosophy: Minds, Monads, and Muad'Dib, titled The God Emperor and the Tyrant The Political Theology of Frank Herbert's Dune Saga. https://www.cardiff.ac.uk/people/view/457489-wakefield-james https://cardiff.academia.edu/JamesWakefield https://www.amazon.com/Dune-Philosophy-MuadDib-Blackwell-Culture/dp/1119841399 Support us on Patreon: https://www.patreon.com/muhh Twitter: @unconscioushh

Mental models are metaphors that help us understand complex problems we work on. They can be a simplified roadmap over an infinite area of complexity. How does one come up with mental models? How are they useful? Are they primarily a solo thing, or can they be used to communicate with the team? What happens when your model is inaccurate? Today, Joël is joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget, to discuss. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Eebs on Twitter (https://twitter.com/EebsKobeissi) You Need a Budget (https://www.youneedabudget.com/) Skill floors and skill ceilings (https://thoughtbot.com/blog/who-is-empowered-by-your-design) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget. EEBS: Hi, Joël. It's really good to be here. JOËL: And together, we're here to share a little bit about what we've learned along the way. So, Eebs, what's new in your world? EEBS: Oh, a whole lot. I'm a new dad, so I'm getting to experience all those things. But in the developer world, I've recently picked up programming on an ESP32, which controls LED lights. And so I'm having fun lighting up my office. JOËL: Is that like one of those little microboards, kind of like a Raspberry Pi? EEBS: Yeah, exactly. It's a little board that's compatible with the Arduino IDE. And I literally only played with it last weekend, so it's still very new to me. JOËL: Nice. Have you done any Arduino development or Raspberry Pi or anything like that before? EEBS: No, I have a Raspberry Pi that I run like a DNS server on, but I haven't done any actual programming. I did make an LED blink, which is pretty cool. JOËL: What kind of programming is required for a board like that? EEBS: From my understanding, it's either in Python or C. Those are, I think, the two languages that you can program on it. I definitely do not know C. And so I'm just going through a bunch of tutorials and reading some sample code. But I think if I ever end up trying to implement something more complex, I'll probably switch over to Python because that's a little more familiar. JOËL: So the coding feels fairly high level even though you're writing controller code for LEDs. EEBS: I hope so. I'd love to be able to take advantage of whatever abstractions I can. JOËL: Do you have any fun goals you're trying to do with this? Or is this just for the fun of trying a completely different environment than web development? EEBS: No, it's actually rooted in something visual. So I have these shelves behind me that are in my webcam when I'm in meetings or whatever. And so I want to be able to put a light strip across these shelves and have some sort of visual thing in the background. JOËL: Like LED mood ring? EEBS: Yeah, kind of. My eventual goal would be that as I'm talking, a little equalizer display pops up behind me. I thought that would be pretty neat. JOËL: That is amazing. That will give you all of the cred in the meetings. EEBS: Right? I thought that'd be pretty cool. What have you been thinking about recently, Joël? JOËL: I've been submitting to the RubyConf call for proposals which, as of the recording of this episode, has just closed this week. And like many people, I submitted on the last day. EEBS: [laughs] JOËL: And it was really fun trying to take some ideas that I'm excited about and then turn them into a proposal that is accessible to other people. EEBS: Nice. Do you want to share a little bit about what the talk is, or is it under wraps for now? JOËL: I don't know if anyone on the committee will listen to this before the review goes out. This might break the anonymity of the proposal. EEBS: Oh, right, right. JOËL: One thing I will share that's interesting is that there are topics that I'm excited about. It's like, oh, here are a bunch of cool things about something, some technical topic. But talks that are just ten cool things about X are not that great. And so I needed to find some sort of unifying idea that I could use to share that. And that generally is in the form of trying to find a story that I can tell. What unifies all of these things together? What tells a compelling story? Is there some metaphor I can lean into? EEBS: Nice. I think that's a really powerful way of communicating something deeper is through telling something that people can relate to. JOËL: One way that thinking about metaphors has been really impactful for me recently is the idea of mental models and how those can help us in development. I'm curious; we've thrown around the phrase a little bit you and I in past conversations; what does a mental model mean to you? EEBS: I tend to be a visual thinker. And from talking to others, I've heard similar statements. So for me, a mental model is how I think about a particular domain or how I think about code flow or structure. And for me, it's usually either as two-dimensional objects or occasionally three-dimensional objects that I have floating in my visual space. So, for example, if we had two classes that are collaborators in some way, I often think of them maybe as two rectangles that are side by side. And when they interact, there's some little amorphous blob from one of those rectangles that reaches out into the other one or passes a message from one to the other. And I sort of have this idea of how many connections are there between these two physical things. Or, if I'm thinking about code flow and the path of execution that code might take, sometimes I visualize it as maybe a tree or potentially loops if there are such cases. JOËL: So when you think of these concepts, just in general, you're seeing in your mind's eye squares and rectangles floating in the air. EEBS: Yeah, pretty often. Sometimes it takes those shapes, and as I build up a mental model of some code, I'm usually adding new shapes into that picture I have in my mind. I tend to view things sort of top-down. So like, the start of code or the start of execution is usually at the top or maybe the far left or far right. And as execution happens, I usually view that as moving in towards the middle and potentially going back out when a response is returned. If it's a web request, something like that, I view it as this sort of outside in. And there's a bunch of pieces in there that are all talking to each other. JOËL: That's really cool. So not only is there a geometric aspect to it, but there's a spatial aspect to it as well. EEBS: Yeah. And it's interesting, like, I haven't actually thought about it [laughs] in this level of detail before. But yeah, there certainly is a spatial aspect to it. And I have this idea in my mind of like things and domain objects kind of belong at the bottom, and they should have well-defined boundaries. But the pieces that are a little bit towards the outer edges may be a little more fuzzy and may have less definition around them. JOËL: That's really interesting because I also have this sort of in my mind's eye see these things when I'm thinking about concepts like that. But I've talked to other people, and some people don't even have much of a mind's eye at all. They don't tend to visualize things in their mind in that way. EEBS: Yeah, it's really interesting how different people approach this thinking about code. A lot of people write things down. And I write things down, too, and draw little arrows that don't really make any sense. But it helps me do something physically sometimes as well as just thinking about it. JOËL: Have you ever tried to convert these pictures you see in your mind and actually draw them on paper? EEBS: Occasionally. And for the most part, that usually takes the form of some kind of domain modeling, whether it's based on database tables or just domain objects. And sometimes I will try and draw them out and then specify the relationships between them like, oh, you know, this one model talks to this other model in this particular way. And I'll define a relationship between them, which helps me think about them and how they interact. JOËL: I've found that even though for some things I can see it very vividly in my mind's eye, I struggle to then concretely translate that onto paper or digital paper if you will. It's almost like trying to, say, translate an emotion into words and that even though I feel like I see a visual picture, I can't reproduce it by drawing necessarily. EEBS: It's interesting you brought up feeling because a lot of the times, I have this gut feeling about a mental model, like whether I think it is correct or not. And sometimes I have this uneasy feeling of, like, that doesn't feel right to me, but it's hard to articulate why. And I think sometimes that's when I have to pull out something physical, start making those relations, start connecting things. And that's when I might uncover, like, oh, this feels odd because I have a circle here or a cycle or something. Or I've sort of represented the truth of something in two different places. Do you have any techniques for getting it out of your head and into something physical that you could share with someone else, maybe it's text or a picture? JOËL: I think I do struggle with that conversion sometimes. Practice definitely helps. I think maybe there is a metaphor here between converting these, let's call them, pictures that I see in my mind's eye and then drawing diagrams with trying to take feelings and expressing them in words. In the same way that, maybe I might have some feelings, and then I want to journal how I feel, and I struggle to express that. But finding a way to express that gives me a certain amount of precision and a more concrete thing. In the same way, these things that flash in front of my mind's eye, if I can take the time to put them on paper, they're now more real. They're more concrete. I think you can probe the edges, the ways that it kind of falls apart more easily. EEBS: Yeah, that makes a lot of sense. There's a lot of value in writing that down and going through those details in a methodical way because oftentimes, you'll catch inconsistencies, or you'll find better ways to describe it. And being able to share your mental model with someone else is often...well, it can be really tricky. And I think that's why it's important to go through and maybe find a common medium that you can share because I can't see into your brain. You can't see into mine. But if we can share our mental models, then hopefully, we have a better chance of agreeing on the solution or finding inconsistencies. JOËL: Exactly. I think, in many ways, there are almost multiple layers of mental models and that you might have an abstraction or a metaphor for a concept that you're working with separate from the diagram. And then the diagram is yet another metaphor, but now we're going geometric to represent a broader idea. EEBS: Yeah. Are there any other ways that you take that picture from your mind's eye besides written documents or conversations? Do you use any diagramming tools that specifically help with that? Or is it just kind of free-form? JOËL: I do a mix. I am a big fan of draw.io, which allows you to just free-hand or pull shapes together, things like that. There are some more structured tools that I will use. I'll use Mermaid.js. EEBS: Yeah, I've been using that a lot too. JOËL: Yeah, that's great. I've been digging into more structured diagrams recently, particularly the idea of graphs, directed graphs. And those have interesting properties. EEBS: Can you share a little more detail about what you mean? JOËL: So a graph in the computer science sense is a bunch of nodes. They are typically represented as circles and then edges which are the connections between them. A directed graph is now there's an arrow pointing in a particular direction. A really interesting property that you can have with directed graphs is whether or not they include cycles. So can you only by following the arrows effectively create a loop? Or will the arrows always lead you to some kind of terminal node? EEBS: Gotcha. Is that a directed acyclic graph? JOËL: If there are no cycles, yes, it is a directed acyclic graph or DAG, as you'll often see it abbreviated. EEBS: [laughs] How do you relate that graph to code? And what benefits do you get from expressing it that way? JOËL: So this shows up in a lot of places. And I'd even say that thinking of certain aspects of my code as a graph and a potentially directed acyclic graph is itself a mental model or a metaphor that helps bring clarity to the way I think about things. So, for example, code, you know, you invoke some main function at some point to call the code, and then that's going to call out some other functions, which call out some other functions, and so on. You may have heard that referred to as a call graph. But that is a graph of calls. There might be cycles in there for co-recursive functions and things like that. But that is one way you can then sift through and analyze how control flow or how logic flows through your application is through a function graph. You mentioned earlier the idea of objects and how they're connected to each other. That's an object graph. EEBS: Right. Recently, I had to work through a state transition problem where a customer has some billing, and they can go through many different states, whether it's active, or canceled, or past due, those sorts of things. And so actually, I reached for Mermaid.js and built a graph of, okay, they start here in this empty state. And then they subscribe, which then they become active. They might cancel their subscription, which moves them to a different state. And by listing out all the states and the transitions between them, it helped me to understand what methods I might need to define on which objects in order to allow those transitions to happen and what checks I might need to make before allowing those transitions depending on the state of the system. JOËL: I'm hearing the keywords states and transitions. And that's making me think of finite-state machines. Are you drawing a finite-state machine graph or something a bit more free-handed? EEBS: It's a bit more of free-handed. I don't think I've actually drawn out a state machine since college but just representing the different states as different boxes and the transitions that are possible from those states. I mean, I guess that kind of is a state machine in some way. So graphs are great visual approaches. Are there any non-visual approaches that you take? JOËL: That's a great question because not all mental models have to be visual. I think the power of a mental model exists in a metaphor. And one that's kind of broad but that I've applied to a lot of different areas is the general idea of something being parallel or in series. I think I first came across this concept talking about electric circuits. And are we talking about two little light bulbs that are in parallel, and if the electricity to one is cut, the other one still lights up? Or are they chained together in series? EEBS: Yeah, like my LEDs. JOËL: Exactly, going back to Arduino, but it can also be applied to a bunch of other things. We can talk about code being in parallel or in series. We can talk about work being in parallel or in series. Interestingly, I took that mental model as a sort of quick shortcut when I was digging into some functional programming ideas. Monads and applicatives are the fancy terms here. EEBS: Oh boy, I'm ready. JOËL: In general, and there's a hefty asterisk here, I think of monads as being serial, so you're chaining something; one thing happens, then another. So you can think of, for example, chaining promises in JavaScript, promise one, then promise two, as opposed to applicatives which are parallel. So you might think of maybe zipping two lists or two arrays in Ruby. The two arrays, there are no dependencies between the two of them. They get processed side by side as you're traversing both of them together. EEBS: Interesting. I've heard the term monad a lot, but I haven't heard the term applicative. Are there any other details you can share about them and what makes them different or how they might be seen in our code? JOËL: I think that the key difference is that distinction in how they're processed. Applicatives are a way of combining two independent, let's call them data sources, and then you find a way to combine them together. So it could be two independent arrays, and you're zipping through them. It might be two independent HTTP requests, and they can both fire in parallel. But then you want to combine their outputs. So you say wait until both are successful and then combine their output. EEBS: Oh, okay, gotcha. JOËL: It could even be nullable values. So you say do this thing if both values are present. But you're not...the value of one or the fact that one is null or not is not dependent on whether the other one is null or not. They're independently null or not as opposed to something...Monads are, again, a different way of combining. You might call them data sources or operations. But in this case, there is a clear dependency one, and then its output influences the next one. You might say check the value is null or present or not. And then, if it is present, take that value and then put it as the input of my next operation. And then, if it is null or not, do another thing. See, now you have a sort of chain. EEBS: Where do you see these chains happening in code? Or is it everywhere? JOËL: Once you know that pattern which, again, could be thought of as another mental model, you start seeing it everywhere. So promises in JavaScript chaining together that's effectively monads. Don't @ me, all the functional programming people. EEBS: [laughs] JOËL: I know that's not quite true. Anything dealing with multiple operations that could succeed or fail depending on, again, whether you're treating them as dependent or independent, that's probably going to look very similar to either monad or applicative. EEBS: So the first thing that actually comes to mind here is things like background jobs. Using Sidekiq or Resque or other job processors, you can have a queue of jobs that need to be executed, and they might need to run in serial, or potentially you have multiple workers pulling from a single queue, and thus the work is happening in parallel. Is that a reasonable analogy? JOËL: I think it's good for the serial versus parallel, but it's not necessarily a good analogy for understanding monads and applicatives. EEBS: Gotcha. JOËL: So with two workers, you can process a queue in parallel, and a bunch of things happen. EEBS: But there's not necessarily anything that is bringing those two workers together to produce a single output. JOËL: Yes. And there's no dependency between the tasks in the queue. EEBS: Right, right, gotcha. JOËL: So if you have a task that says execute this task and then only if this task succeeds, then do the second task, now you've created a dependency. And you couldn't process that in parallel because if task one, which has to be executed first, is executed by worker one, task two should not get processed unless task one is successful. You can't just say, oh, I've got another worker free. I haven't processed task two because it's waiting to know does task one succeed. EEBS: Right. So an example in code would be a user creates a new order. And when they create a new order, we send them a confirmation email. That would be an example of that happening in serial or a monad-like thing. [chuckle] JOËL: Yes, I found that thinking of things as serial or parallel is a good shortcut for thinking about monads and applicatives. I don't know that the reverse is necessarily true. They don't necessarily transfer one-to-one with each other. And maybe that's a danger of mental models, right? You find a mental model that describes a situation, and then you try to reverse it, and then you make false assumptions about the world. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: Another mental model that is not necessarily visual that I like actually comes from the video game community, and that's thinking of skill ceilings and skill floors. So in, I think, particularly the MOBA Community, that's a Multiplayer Online Battle Arena, they'll talk about characters as having a high skill floor or a low skill ceiling. And generally, what that means, and again, the meaning varies a little bit by community, is that a character with a low-skill floor is an easily accessible character. They might not have a lot of skill shots, like, you press a button, and things happen around your character. You don't need to aim, things like that. A high skill ceiling means that there's a lot of room for you to grow, and as you get more skilled, you can get significantly better with that character. EEBS: Gotcha. So the opportunity is greater with a higher skill ceiling. JOËL: Correct. And depending on how the character is set up, you might have a very narrow range that could be in the low range where it has a low skill floor and a low skill ceiling, which means that the character is easy to learn. But once you've learned it, there's not really a lot you can do with it. It's a fairly basic character. So getting better at the game is not necessarily going to make you that much more impactful. And then you could have one that's the opposite that is high both skill floor and skill ceiling where a character is very hard to learn. But once you learn it, that's kind of all there is to it. And then you might have one that has a large range somewhere; maybe it's easy to learn, but it's hard to master, or there's a lot of room for growth. And so, taking this framework for analyzing characters and video games, I think we can apply that to technology in general. This could be language design. This could be just API design. And you might say, well, I want this to be very accessible. People can jump in very easily. You might say I want this to be very powerful and have a lot of high-end features that make your power users very happy and very productive. EEBS: That's interesting. When you first were talking about it, I was actually less thinking about it from a user's perspective of what maybe they could do in the application but potentially from the standpoint of a developer writing the system itself. One of the pieces I always come back to in software development is that change is inevitable. And so, making something easy to change often pays great benefits down the road. And so I wonder how that fits into this idea of a low skill ceiling or a high skill ceiling in terms of perhaps flexibility or being decoupled such that you can take one idea and easily extend it or easily get more from it than you originally set out to build. JOËL: There's often a trade-off. So you make something easy to change. It's highly decoupled. But you maybe introduce more indirection to the system. So while it's easier to change one single piece, it's harder to understand the system as a whole. EEBS: Yeah, that's true. And sometimes, you bake in assumptions that you make about the future, which turn out not to be true. JOËL: [laughs] Yes, that is definitely something I'm guilty of. EEBS: I think we all are. JOËL: One thing that I find interesting is as you evolve the design of an architecture pattern, a system, a whole language, you might want to move one of those if I think of them like two independent sliders on a one-dimensional scale. So maybe you want to move the upper boundary a little bit and say I want a higher skill ceiling for this, but they don't actually move completely independently. So introducing some advanced features might inadvertently also raise the skill floor. And conversely, making the language super accessible so that it has a low-skill floor, you might have to decide I will not introduce certain features. EEBS: One thing I wanted to ask you about is, do you view different languages as having different skill floors and ceilings? And, you know, I love Ruby. I know you love Element. I've played with Element. It's been a great learning tool for me. How do you view those two languages in terms of skill ceilings and skill floors in terms of, I guess, what you can do with them? JOËL: That's a great question. And I think you can definitely apply that to languages. Admittedly, I think you could probably start a lot of flame wars with that. EEBS: [chuckles] Let's not do that. JOËL: I wrote an article a while back where I applied that mental model to look at the F# programming language. And there was a debate in that community about certain features to add and whether they would allow advanced programming but potentially at the cost of accessibility to newer members of the community and how to balance those. And so I thought, hey, let's throw this video game metaphor at the problem and talk about it through that lens. EEBS: That's really cool. Did you draw any conclusions, or was it as a way to start a conversation? JOËL: It is a way to start a conversation. I don't think there is a single correct or best distribution of your skill, ceiling, and floor. It has to match the goals you set out for your project. Just like in games, people love to rank which characters are best and not. And sometimes you can show that, in general, this character is better. But oftentimes, in a balanced game, you can talk about this character being easier to get started with or this character working very well if you're a pro. But the fact that you have a higher or lower skill ceiling or floor doesn't necessarily make the character better or worse. EEBS: So, this conversation about differing mental models, I think I hadn't realized that there can be so many different types of mental models. And some things that I do in my thinking I haven't classified as a mental model. But now that you bring it up, I think one that I think about fairly often is this idea of two objects that are collaborators and reaching into the internals of one of those objects from the other object. So A and B are two separate things. And if A reaches into B's bucket and messes with the state of B, I view that as sort of a bad practice. You're not really adhering to maybe the public API that that object is exposing. You're kind of reaching in and going around behind its back and changing some stuff that it may not expect. JOËL: Would you refer to that maybe as tight coupling? EEBS: Yeah, it's definitely tight coupling. It's not just tightly coupled; it's almost worse than that. It's almost like going behind somebody's back and making a change without them knowing. And so when I see that in code or when I write code that does that, I have this really intense desire to separate that and to say, no, no, you can't go in and update this record directly in the database. You have to send it a message and say, "Hey, I would like you to be aware of something," and then it goes and changes its own internal state as a response to that. And so I have this very vivid sort of mental feeling of it being wrong, of it being like, I'm being sneaky, or I'm not being gracious to the person I'm interacting with as though I were one of these objects. JOËL: That's fascinating. You've practically anthropomorphized these objects. EEBS: I do. I view them as little people. JOËL: You describe this interaction as going behind someone's back. That is the thing that I, a person, do to someone else. It's not a function making a direct call. And yet, it's such a strong...we use a social mental model to talk about objects and interactions. EEBS: Yeah, I almost want them to be friends. And I think that applies to real-life relationships, right? If you have a nice dialogue back and forth, there's an understanding. There's commonality that you can find. But if I were to go do something behind your back without chatting with you about it first, you might not be so happy with me. JOËL: I'd feel betrayed. EEBS: Right. JOËL: I feel like there's probably a really fun conference talk to be done about that. We often use that metaphor; I think when talking about objects sort of subconsciously but making it explicit and just being, hey, let's talk about these objects as if they were people. Why don't we want to do this? Because this one here is betraying the other object there. This one here is being impolite. EEBS: We could have two people get on stage and talk to each other. And I might then go and reach in your pocket and pull out some change without you knowing, and you might be upset with me. JOËL: That would be great. Get a little skit going up on stage. Or even if you're artistically inclined, you could probably draw some really fun little characters to illustrate this. EEBS: That would be really cool. I, unfortunately, don't have the artistic talent to do that. JOËL: Well, free conference talk idea to all listeners of the podcast. I expect to see this for RailsConf 2023, maybe. EEBS: I'll be looking for it. So I've shared a mental model that I didn't really know was a mental model. Are there other mental models that you want to share that I may not be thinking of? JOËL: Here's one that I've just come to realize recently that I'm actually quite excited about: when you think about the word refactoring, how would you describe that idea? EEBS: Well, refactoring to me is changing the implementation without changing the behavior. JOËL: Yes, I think that is the classical definition. You should be able to change the implementation of a method, and the tests without changing are still green after you've done that. EEBS: I guess, mentally, I think about that as perhaps drawing a box around some of the objects that are floating in my mind's eye, rearranging how they exist within that box, and then the box dissolves. And the tests still pass, but the structure of the objects or the code has changed in my mind. JOËL: I love that you immediately went to a visual approach there. And I think I have something similar, but I'm coming at it from a slightly more domain modeling perspective. So thinking maybe less from an individual method approach but looking at maybe a larger system, what you're trying to do is use code to describe some version of reality. So it might be a business process that you have. It might be trying to describe some aspect of your customer's life that you're trying to automate for them. Oftentimes, this thing you're trying to describe in code terms is going to be a simplification because life has a ton of edge cases, and many of them we don't care about. So if we go with a visual metaphor here, you're trying to draw some kind of shape using only straight lines to approximate some weird curve. And so, let's say you draw something with only four lines. It's really simple, how you have a diamond. That's the shape you're trying to create. And then you're going to fill it in with little other shapes that approximate a diamond. And those are your different models and functions and all the other components that we use to build software. At some point, your understanding of the underlying reality might change. Maybe you need more precision, or maybe the actual feature requirements have changed. The thing you're trying to approximate with your code is not a diamond. Maybe you've added a few more sides to it. It's a pentagon. So we've gone from four sides to five. And the little components, and modules, and things that you have there approximate that diamond work. They still mostly approximate your pentagon, but it's really clunky because the initial design was to approximate something else. They were really good for fitting in really tightly and being very loosely coupled to each other when we were trying to do a diamond, but then they don't work as well in the pentagon. EEBS: So maybe some of the internal shapes need to change or adjust to fill the space that the pentagon has now created. JOËL: To fill the space or maybe even just to fill it in a way that's less clunky. And so the idea here in this metaphor is that the reality we're targeting in software is always changing. And so the underlying reality changes, and so we're changing that shape that we're creating all the time. But also, we're getting more precision as we decide; oh, we care about this edge case now. We didn't in version one, and so as part of that, we're constantly having to take the modules that maybe were very well designed initially but then restructure them to fit the new requirements because now there's a fourth object coming in, and it's kind of clunky with our current configuration. EEBS: That's interesting. One of the first things that jumps to mind is that maybe there are better ways or worse ways to do that refactoring to fit that new shape. Do you think there's any truth to that in the sense that you might initially design a system that perfectly fits that diamond or very closely fits that diamond but then as it changes to a pentagon, do you need to simply add a new piece to fill in that empty space? Or do you need to restructure everything within the diamond now to fit the shape of the pentagon? JOËL: Oftentimes, you do need to restructure. And I think there's this wonderful little phrase from; I believe it's Kent Beck that says, "Make the change easy, and then make the easy change." EEBS: Yep. JOËL: And so, to me, that makes the change easy is that initial restructuring that you need to do of those first shapes so that you can finally bring in the new one. EEBS: Oh, that's a cool visual. I immediately can imagine the pieces in the pentagon moving around to make space for a new piece that you need to now bring in. And that movement of all those pieces can be really difficult. Have you ever played that game where it's a square, and you're trying to get a ship out of a port, but there's a whole bunch of other ships, and you can only move them left and right and up and down? And you can do that. And that's what I'm picturing right now is moving shapes within that pentagon to then make space for either a new shape or to allow a shape to escape that is no longer relevant. JOËL: I played a version of that that had cars, cars, and trucks. EEBS: Gotcha. Yeah, I think I played that too. JOËL: That would also be a fun conference talk, right? Like, start with that game as your initial metaphor. And then you use that as a way to talk about refactoring. EEBS: That would be really cool. JOËL: I would watch that talk. To anybody listening who wants to give that talk, I want to see you at RailsConf 2023. EEBS: [laughs] Are we just a talk factory now? [laughter] JOËL: I love talk ideas. Maybe this should become a segment. Just have Eebs come in for five minutes once a month and give us a talk idea. It could even be fun to see a talk idea that multiple people implemented differently. EEBS: That would be really cool, actually. I always get nervous about giving talks or being on podcasts like this one. I would love to be the person that gets to sit there and throw out random ideas and have other people fulfill my dreams. JOËL: Well, thank you so much, Eebs, for joining us to talk about mental models. And to all of our listeners, I'd love to hear about what mental models you find are helpful, and so please share them with us. On Twitter, you can reach us at @_bikeshed. EEBS: Thanks for having me, JOËL. This has been super fun. JOËL: And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sandra und Daniel reden über Monaden, Publizieren auf allerlei Art und Frontend

It's not every day that you learn a new approach to error handling for Ruby. Today Abiodun Olowode shares her insights with railway oriented programming (ROP), a functional programming technique that allows sequential execution of functions, not necessarily synchronous. The key concept is that each function can only accept and return Container of either Success or Failure. They also dive into the topic of dry monads, the gems that helps you achieve railway oriented programming in that it helps bind your methods together and give you a success or failure result. In this Episode… What is railway oriented programming (ROP) Examples of ROP and dry monads Limitations of dry monads How to test your configurations Dry schema implications What is the developer culture like in Nigeria, Africa? Links Railway Oriented Programming In Rails Using Dry-Monads - Honeybadger Developer Blog (https://www.honeybadger.io/blog/railway-programming-dry-monads/) Picks Abiodun- Bridgerton (https://www.netflix.com/title/80232398) Charles- Scythe: Invaders from Afar (https://boardgamegeek.com/boardgame/199727/scythe-invaders-afar) Charles- Hover.com (https://www.hover.com/) Charles- Podio.com (https://podio.com/) Luke- A new bootable USB solution Luke- Front end load library (https://pqina.nl/filepond/) Special Guest: Abiodun Olowode .

It's not every day that you learn a new approach to error handling for Ruby. Today Abiodun Olowode shares her insights with railway oriented programming (ROP), a functional programming technique that allows sequential execution of functions, not necessarily synchronous. The key concept is that each function can only accept and return Container of either Success or Failure. They also dive into the topic of dry monads, the gems that helps you achieve railway oriented programming in that it helps bind your methods together and give you a success or failure result.In this Episode… What is railway oriented programming (ROP) Examples of ROP and dry monads Limitations of dry monads  How to test your configurations Dry schema implications What is the developer culture like in Nigeria, Africa? LinksRailway Oriented Programming In Rails Using Dry-Monads - Honeybadger Developer BlogPicks Abiodun- Bridgerton Charles- Scythe: Invaders from Afar  Charles- Hover.com Charles- Podio.com Luke- A new bootable USB solution Luke- Front end load library Special Guest: Abiodun Olowode .Sponsored By: Coaching | Top End Devs: Do you want to level up your career? or go freelance? or start a podcast or youtube channel? Let Charles Max Wood Help You Achieve Your Dreams Top End Devs: Learn to Become a Top 5% Developer. Join our community of ambitious and engaged programmers to learn how.

An important change coming to the R-spatial ecosystem, enhancing function error reporting with chaining, and traveling down the monad rabbit hole. Episode Links This week's curator: Tony ElHabr (@TonyElHabr (https://twitter.com/TonyElHabr)) R-spatial evolution: retirement of rgdal, rgeos and maptools (https://r-spatial.org//r/2022/04/12/evolution.html) Error chaining (https://thisisnic.github.io/2022/04/09/error-chaining/) Why you should(n't) care about Monads if you're an R programmer (https://www.brodrigues.co/blog/2022-04-11-monads/) Entire issue available at rweekly.org/2022-W16 (https://rweekly.org/2022-W16.html) Supplement Resources Roger Bivand's announcement of the rgdal, rgeos, and maptools packages retirement (https://stat.ethz.ch/pipermail/r-sig-geo/2021-September/028760.html) Geocomputation with R (https://geocompr.robinlovelace.net) Progress in the R ecosystem for representing and handling spatial data (https://link.springer.com/article/10.1007/s10109-020-00336-0) Rweekly Highlights episode 72 (https://rweekly.fireside.fm/72) Bruno Rodregues' monads YouTube video (https://www.youtube.com/watch?v=Hlypj6-n51c) "Function Factories" Chapter in Advanced R (https://adv-r.hadley.nz/function-factories.html)

The Elixir Outlaws now have a Patreon (https://www.patreon.com/user?u=5332239). If you're enjoying the show then please consider throwing a few bucks our way to help us pay for the costs for the show. Elixir Outlaws, 01/19/2021 On today's episode of the Elixir Outlaws, Sean Cribbs and Amos will talk about WASM (Web assembly) to implement some core parts of the app and discuss the server-side too. Rusts for loop syntax is sugar for iterators, says Sean. So, you can also sort of do method chaining type thing in rust. There is an interesting proposal on the Elixir form for loops. Episode Highlights FOR loops are not loops, they are a special form in the compiler, basically a macro with special privileges that generates some code, says Sean. As per Sean, if you have a lead, then you have for loop variable, and you have to return a two-two pole that has the accumulator as the second, or if you don't, then it is just the accumulator that becomes quite confusing. Amos says that when one uses MapReduce and has FOR loop and you want to step through something and maybe at the same time get an account and a sum, and you want to adjust the current values, then we are getting three things out in adjustment and then two other data points. It is hard to step away from an imperative mindset when you have done it forever and adding imperative things back into the language is going to make it even harder for people to step outside of that imperative mindset, says Amos. People use Monads to write things that look more imperative because it is easier for us to think that way sometimes, and it's going to create less maintainable code. OCaml is very much like in the same syntactical flavor as Haskell. But it doesn't have that whole lazy evaluation thing that gets so confusing at times, and it also has the much simpler type of system. Sean had tried hard to encourage his coworkers to use things like in the lists module or use list comprehensions or use fold wherever they could. But some people liked making software recursive functions that had a bunch of arguments to them. In MapReduce there is a trailing option you can put on for loops. It is like reducing given initial value of the accumulator and then you match the accumulator coming in. Using ENUM reduce, there are some tactical forms that represent something, and special form will generate, but they are not things in themselves. The things that are browser based we can't rewrite completely in Rust. There is always going to be JavaScript at some level. Sean has seen attempts where people want to have JavaScript running the same code on the front end as in the back end. In graphic production, there are many things about memory allocators, but these are all sorts of things that we might have to think about with rust when we are trying to implement. 3 Key Points With MapReduce in the ENUM module, you can do something on each element of the collection, but you are also collecting something about the entire collection as you flow through, says Sean. The flipside of list comprehension is that you can only do so many things in the right side of the comprehension. It may be explicit what you were returning from expression because the entire expression is inside the list brackets. The biggest thing that Amos have ever had to deal with when working on stuff on the front end or on edge computing is if you don't control the resource at the endpoint, it may be the slowest thing ever, and it may not work that well. Tweetable Quotes “I am not against pipes, and you can write non-imperative code with pipes, but it looks imperative.” – Amos “In FOR loop, FOR is an expression that returns a value. You can choose to ignore that value that's returned, but it returns a value, usually a list.” – Sean “You can have only one let, which is the other thing that's a little bit surprising. It works in if statements.” – Sean “Being able to have code on the back end, you control the hardware and the performance.” – Amos “The book Kill it with fire I wish I had picked up a year ago because the author worked for US digital service, updating mainframe applications, and there's a lot of sage advice in that book.” - Sean Resources Mentioned: Podcast Editing Elixir Outlaws: Website

A new track by DJ Habett from the album "Don't trust the DJ" (2021-12-04). Tags: Electro, Grow, Heal, Attic, Horizontal, Memories, Afar, Terminal, Mutation CC(by)

In this episode we have talk with Alejandro Serrano Mena, he works on 47 degrees and is a published author of two books about Haskell: The Book of Monads and Practical Haskell. We talk about many interesting features behind functional programming such as adts, pattern matching, impredicativity, monads, effects, hacking the ghc and how all this comes together to grab industry attention to adopt functional programming features over the past decade. Links Our new twitter @ttforall Alejandro's twitter Book of Monads Practical Haskell The Haskell Interlude Tweag's youtube channel on the GHC

In this episode we have talk with Alejandro Serrano Mena, he works on 47 degrees and is a published author of two books about Haskell: The Book of Monads and Practical Haskell. We talk about many interesting features behind functional programming such as adts, pattern matching, impredicativity, monads, effects, hacking the ghc and how all this comes together to grab industry attention to adopt functional programming features over the past decade. Links Our new twitter @ttforall Alejandro's twitter Book of Monads Practical Haskell The Haskell Interlude Tweag's youtube channel on the GHC

In this episode we have talk with Alejandro Serrano Mena, he works on 47 degrees and is a published author of two books about Haskell: The Book of Monads and Practical Haskell. We talk about many interesting features behind functional programming such as adts, pattern matching, impredicativity, monads, effects, hacking the ghc and how all this comes together to grab industry attention to adopt functional programming features over the past decade. Links Our new twitter @ttforall Alejandro's twitter Book of Monads Practical Haskell The Haskell Interlude Tweag's youtube channel on the GHC

Apologies for the delay, we've had some technical issues this week! We continue discussing the dynamics of monads, dyads, and triads in relation to trauma. Lance uses this example to dive into how the Dimension Approach works and what some of the key aspects of the healing work are. Thank you for listening! Please send any questions or comments to dimensionapproachmedia@gmail.com

We start by discussing containers for experience which leads to tantrums. Tantrums takes us to developmental psychology, and that brings up monads and dyads. It's a fascinating dive into relationships and some interesting theories. Thank you for listening! Please send any questions or comments to dimensionapproachmedia@gmail.com.

FEE, FOO, FUD, and FUM (Fear, Uncertainty, and Monads) - Scala Giant, Dick Wall, joins Bruce and James to talk about life, work, and Functional Programming. Discuss this episode: https://discord.gg/nPa76qF

Audio source: https://www.svelteradio.com/episodes/svelte-language-tools-with-simon-holthausen (55 mins in)My blogpost: Errors are Not Exceptionsswyx: [00:00:00] A while ago, I started learning Go and found that there was an interesting difference between how Go handles errors and exceptions compared to JavaScript. So I wrote a blog post called errors versus exceptions. And that blogpost really stuck in my mind so much so that in a recent episode of Svelte Radio i pulled it out again as my unpopular opinion so here it is.All right. Other unpopular opinions. I've got a quick one, I've been learning goal recently for my new job and I realized that. Other languages handle exceptions and errors differently than JavaScript. And I did not know that there was any other way to do this because my only prior exposure was Python and JavaScript and they treat them the same, the exact same way, but in go, or let's say in rust, you don't really throw unless you really like shit is hitting the fan and the error the program needs to end right now.Whereas in JavaScript is pretty normal to throw. Whatever area you want. And then you would just expect someone you document that someone above should catch you. You expect someone to catch you somewhere. And then the program is going to recover and continue. From an error. And so I I realized this when I, yeah.I was just like, exploring like, what is, what's the difference between errors and exceptions like that? I don't know if you guys have ever thought about it. Antony: [00:01:12] I have thought about it because in Java where I originally came from, it's two very different concepts. So it and an error, sorry.An exception is something quite normal. It's an exception to the flow of the program or the circumstance you're in. And you can even do exception, different programming, which I used to do quite a lot, where you just have. So Java has very good exception catching it. Doesn't have like JavaScript.We have to inspect what kind of code is or read some texts out of the message. It has explicit types around what you're throwing. So you can make a catch date with multiple catches and just say this type, do this, this type, do this. So an error in Jarvis thing that if you throw an error in Java, your program equates that's the end, right?And error is critical. It's your system is broken and you always never used them. Yeah. When you're programming regularly, you never really used it. You shouldn't use them, especially web apps, but for an exception, that exception is quite a normal thing. And it literally means the truest term. It's an exception to.The flow you expect to be happening. swyx: [00:02:11] Yeah. So that, that was what it took me a long while to actually get there because I've never used Java. And then th the other thing that was confusing was go actually names them the opposite way around. So which ones are errors and then areas are Antony: [00:02:22] that's complex.swyx: [00:02:24] So it really, really screwed me up. But anyway the unpopular opinion is you should not use. Throw in JavaScript, unless you can really, really avoid it. You should use, you should return an error or you should return it in some sort of error objects. I see Simon and give me a thumbs up. Yeah, definitely.That Antony: [00:02:38] is a hard wiring rework of my brain. If I was to do that, to be honest, swyx: [00:02:43] this is so normal to throw, but we should not be randomly throwing like that. It's not, it's an abusive thrill. Simon Holthausen: [00:02:48] There, there are concepts in, for example, a functional programming with this either. So you either return the normal thing or something that exception, so to speak, and then you are forced to handle that all the way up the chain.But I think that's also why it hasn't gotten so popular because if you have to explicitly handle it every time, which is generally a good thing, I think. Many people are just lazy and say, okay, I'm just going to throw a, try, catch somewhere, very up the chain and just deal with it there instead of having to pass around this either all the way up.But I think it would make for a much more robust code. More Antony: [00:03:31] predictable quotas. If you're programming, if yeah. I if you're writing a language, like you said, um, If you make it too different to everything else, that's out there, you split the camp into two types of people as those who will adopt it and change their program habits, which should be few.There are people who will just ignore it completely because it's so different to what they used to. And then there'll be the fanatics who absolutely just love it. The fact does everything differently. Again, be a small counter centers. Describe the. The Elm language quite well, possibly I've not looked at Allen swyx: [00:04:00] quite possibly either or maybe yeah.Monads yeah, and then for me, the final realization was that anytime you throw within the anything async, and the moment you have, you, you call promise and you forget to catch that error just goes out the window. It's never handled that doesn't exist and goes to the top. I actually got mad at JavaScript. I was like, wow this is the reason we have shitty programs in Java scope because we don't have really good discipline around error handling. Anyway, that's my unpopular opinion. You should, we should stop. Antony: [00:04:34] All right.

En este segundo episodio de la segunda temporada conversamos sobre Haskell, Monads, Functors. ¿Cómo y por qué aprender Haskell? ¿Qué puedo hacer con Haskell? Y para conversar sobre este lenguaje de programación me acompaña Alejandro Serrano, Haskeller e Ingeniero en 47degree, también autor de "Book of Mondas" y "Practical Haskell".Encuentra a Alejandro en TwitterCurso: Haskell Fundamentals (2-Day Course)Propuesta para TC39: VariantsLibros:Practical HaskellBook of MonadsRecomendadosLearn you a Haskell for Great GoodProgramming HaskellProfessor Frisby's Mostly Adequate Guide to Functional ProgrammingCharla: Why Isn't Functional Programming the Norm by Richard FeldmanLenguajesPrologErlangClojureElmRescriptOCamlElixirLispMu-haskell https://github.com/higherkindness/mu-haskell https://higherkindness.io/mu-haskell/Únete al newsletter Micro-Bytes. micro cursos de desarrollo web directamente en tu correoApoya mi trabajo suscribiéndote en buymeacoffe.com/matiasfhaMusic CreditsOpening & Closing: Slow Burn by Michael BriguglioClydesdale Funk by Cast Of CharactersFoot Work by Heads of PeopleBig Wave by Ian KeloskySupport the show (https://www.buymeacoffee.com/matiasfha)Auth0 Auth0 es una plataforma de autenticación y autorización lista para usar en tu app!Cloudinary Distribuye tus experiencias digitales de forma rápida y sencilla.

Neste episódio vamos falar sobre a segunda parte de Programação Funcional, onde Lambdas abordam Functors e Monads. Confira a primeira parte do episódio aqui. Feed do podcast: www.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: www.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos: www.lambda3.com.br/feed/podcast-nao-tecnico Lambda3 · #220 - Programação Funcional Parte 2 - Functors e Monads Pauta: Recursividade Currying Teoria das categorias Monoides Funtores Mônadas Railway-Oriented Programming Links Citados: RebuildCast Railway Oriented Programming Curso Gratis de Teoria das Categorias Participantes: André Valenti - @awvalenti Higor Rozan - @higorrozan Lucas Teles - @lucasteles42 Edição: Compasso Coolab Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 - creativecommons.org/licenses/by/3.0

Long-time Java author & expert, Cedric Beust, joins us to revisit some of the topics from our Kotlin episodes. We talk more deeply about checked exceptions, null safety, the builder pattern, build systems, and of-course Monads. Discuss this episode: https://discord.gg/nPa76qF

What are the reasons to adopt or migrate to a new technology? What prevents you from doing so? We explore that question and the differences between green-field and brown-field. Then we finally dive deep into Monads trying to conquer the Curse of the Monad. Discuss this episode: https://discord.gg/nPa76qF

Audrey Tang joins me to talk about COVID-19, her career path, digital minister's job, forking the government, Sci-Fi and so on. Transcript of this episode is available at rebuild.fm/271 Show Notes Coronavirus: How map hacks and buttocks helped Taiwan fight Covid-19 New Zealand is lifting almost all its coronavirus restrictions, after no active Covid-19 cases reported mask.pdis Exposure Notifications: Helping fight COVID-19 - Google WHO can help? Taiwan Audrey's new avatar Fix language selector label for zh-TW (体 -> 體) by audreyt · tokyo-metropolitan-gov/covid19 零時政府 g0v.tw CC0 - Creative Commons RadicalxChange What Happens Next? COVID-19 Futures, Explained With Playable Simulations perl6/Pugs.hs: Raku User's Golfing System in Haskell Scratch Computational thinking The Three-Body Problem: Liu, Cixin, Liu, Ken Culture Series by Iain M. Banks 三体Ⅱ　黒暗森林（上） | 劉 慈欣 Stories of Your Life and Others: Ted Chiang 息吹 | テッド チャン Nokia 8110 4G mobile Moana | Disney Movies Dos Monos - Civil Rap Song ft. Audrey Tang 唐鳳 Japan's Dos Monos Features Taiwan's Digital Minister Audrey Tang in 'Civil Rap Song' 鳳たんです! - 鳳 The Tao of IETF

Philosophy Podcast Spotify / The Best Philosophy Podcast On Spotify THIS PODCAST UPLOADS PHILOSOPHY LECTURES AND TEXTS WE STUMBLE UPON. WE TRY TO MAKE PHILOSOPHY AVAILABLE AS A PODCAST ON SPOTIFY, AND MAKE IT ALL DOWNLOADABLE FOR FREE. WE TRY TO BECOME THE BEST PHILOSOPHY PODCAST ON SPOTIFY WITH THE MOST PHILOSOPHY EPISODES EVER. BUY A BOOK BELOW TO KEEP US ON AIR. ------------------------------- IMPORTANT! AMAZON DELETED THE LAST INEXPENSIVE BINDING. IT WAS TOO CHEAP! HERE IS ANOTHER VERSION FOR STUDENTS WITH HOBBES, LOCKE, ROUSSEAU AND THE US CONST. IN ONE BOOK: ||| MACHIAVELLI https://www.lulu.com/en/us/shop/niccolo-machiavelli-and-john-locke-and-thomas-hobbes-and-peter-kanzler/the-leviathan-1651-the-two-treatises-of-government-1689-and-the-constitution-of-pennsylvania-1776/paperback/product-69m6we.html XXX https://www.bookfinder.com/search/?author=peter%2Bkanzler&title=pennsylvania%2Bconstitution%2Bleviathan&lang=en&isbn=9781716844508&new_used=N&destination=us¤cy=USD&mode=basic&st=sr&ac=qr || ROUSSEAU https://www.lulu.com/en/us/shop/jean-jacques-rousseau-and-thomas-hobbes-and-john-locke-and-peter-kanzler/the-leviathan-1651-the-two-treatises-of-government-1689-the-social-contract-1762-the-constitution-of-pennsylvania-1776/paperback/product-782nvr.html XXX https://www.bookfinder.com/search/?author=peter%2Bkanzler&title=pennsylvania%2Bconstitution%2Bleviathan&lang=en&isbn=9781716893407&new_used=N&destination=us¤cy=USD&mode=basic&st=sr&ac=qr | Thank You Dearly For ANY Support! And God Bless You.

Glad to host a remote meetup with our trainer Scott Wlaschin, author of the book "Domain Modeling Made Functional".Join us online to understand why F# and Domain-Driven Design is a great union... no prior Functional Programming experience needed!

Glad to host a remote meetup with our trainer Scott Wlaschin, author of the book "Domain Modeling Made Functional".Join us online to understand why F# and Domain-Driven Design is a great union... no prior Functional Programming experience needed!

Glad to host a remote meetup with our trainer Scott Wlaschin, author of the book "Domain Modeling Made Functional".Join us online to understand why F# and Domain-Driven Design is a great union... no prior Functional Programming experience needed!

Bruno Ribeiro asked a great question about the practical uses of monads. Are they useful? Why are they used so much in Haskell? In this episode, we briefly go over the history of monads in Haskell and how they allow you to do imperative programming in a pure functional language.

Jonathan Lee Martin is an instructor and developer. He got his start in teaching at Big Nerd Ranch doing 1-2 week trainings for mid to senior developers, and then transitioned to 16 week courses for career switchers. He also worked for Digital Crafts for a year, and then wanted to focus on building out his own personal teaching brand. One of his first steps toward building his own brand was to publish his book, Functional Design Patterns for Express.js.The inspiration for Jonathan’s book came from his experience teaching career switchers. He wanted to experiment in the classroom with teaching functional programming in a way that would be very approachable and applicable and dispel some of the magic around backend programming, and that became the template for the book.  Jonathan loves the minimalist nature of Express.js and talks about its many uses. He believes that it knowing design patterns can take you pretty far in programming, and this view is related to his background in Rails. When he was working in Rails taming huge middleware stacks, he discovered that applying design patterns made builds take less time. He talks about other situations where knowing design patterns has helped. Express.js leans towards object oriented style over functional programming, and so it takes to these patterns well. Express.js has its shortcomings, and that’s where Jonathan’s favorite library Koa comes into play.  The conversation switches back to Jonathan’s book, which is a good way to start learning these higher level concepts. He purposely made it appealing to mid and senior level programmers, but at the same time it does not require a lot of background knowledge. Jonathan talks about his teaching methods that give people a proper appreciation for the tool. Jonathan talks more about why he likes to use Express.js and chose to use it for his book. He cautions that his book is not a book of monads, but rather about being influenced by the idea of composition over inheritance. He talks about the role of middleware in programming.  The panel asks about Jonathan’s toolchain and approach to writing books, and he explains how his books are set up to show code. They discuss the different forms required when publishing a book such as epub, MOBI, and PDF. Jonathan found it difficult to distribute his book through Amazon, so he talks about how he built his own server. Charles notes that your method of distributing your book will depend on your goal. If you want to make the most money possible, make your own site. If you want to get it into as many hands as possible, get it on Amazon. Many of the JavaScript Jabber panelists have had experience publishing books, and Jonathan shares that you can reach out to a publisher after you’ve self-published a book and they can get it distributed. Jonathan believes that If he had gone straight to a publisher, he would have gotten overwhelmed and given up on the book, but the step by step process of self-publishing kept things manageable. The panelists discuss difficulties encountered when publishing and editing books, especially with Markdown. Jonathan compares the perks of self-editing to traditional editing. Though he does not plan to opensource his entire editing pipeline, he may make some parts available. The show concludes with the panelists discussing the clout that comes with being a published author.  Panelists Charles Max Wood Christopher Buecheler  J.C. Hyatt With special guest: Jonathan Lee Martin Sponsors Adventures in Blockchain Sentry use the code “devchat” for 2 months free on Sentry’s small plan The Freelancers’ Show Links Big Nerd Ranch Digital Crafts JSJ 070: Book Club JavaScript Allonge with Reginald Braithwaite JavaScript Allonge by Reginald Braithwaite Functional Design Patterns for Express JS by Jonathan Lee Martin Node.js Express.js Koa Minjs  Sinatra Http.createserver Monads Middleware  Markdown Pandoc Diff-match-path library Epub MOBI LaTeX  Stripe Checkout Fstoppers Softcover Bookseller API  Follow DevChatTV on Facebook and Twitter Picks Christopher Buecheler: Cluisbrace.com newsletter J.C. Hyatt: Corsair wireless charging mouse pad Charles Max Wood: Magnetic whiteboard baskets Mrs. Piggle-Wiggle books Jonathan Lee Martin: Eric Elliot JS YellowScale Follow Jonathan and find his book at jonathanleemartin.com

Jonathan Lee Martin is an instructor and developer. He got his start in teaching at Big Nerd Ranch doing 1-2 week trainings for mid to senior developers, and then transitioned to 16 week courses for career switchers. He also worked for Digital Crafts for a year, and then wanted to focus on building out his own personal teaching brand. One of his first steps toward building his own brand was to publish his book, Functional Design Patterns for Express.js.The inspiration for Jonathan’s book came from his experience teaching career switchers. He wanted to experiment in the classroom with teaching functional programming in a way that would be very approachable and applicable and dispel some of the magic around backend programming, and that became the template for the book.  Jonathan loves the minimalist nature of Express.js and talks about its many uses. He believes that it knowing design patterns can take you pretty far in programming, and this view is related to his background in Rails. When he was working in Rails taming huge middleware stacks, he discovered that applying design patterns made builds take less time. He talks about other situations where knowing design patterns has helped. Express.js leans towards object oriented style over functional programming, and so it takes to these patterns well. Express.js has its shortcomings, and that’s where Jonathan’s favorite library Koa comes into play.  The conversation switches back to Jonathan’s book, which is a good way to start learning these higher level concepts. He purposely made it appealing to mid and senior level programmers, but at the same time it does not require a lot of background knowledge. Jonathan talks about his teaching methods that give people a proper appreciation for the tool. Jonathan talks more about why he likes to use Express.js and chose to use it for his book. He cautions that his book is not a book of monads, but rather about being influenced by the idea of composition over inheritance. He talks about the role of middleware in programming.  The panel asks about Jonathan’s toolchain and approach to writing books, and he explains how his books are set up to show code. They discuss the different forms required when publishing a book such as epub, MOBI, and PDF. Jonathan found it difficult to distribute his book through Amazon, so he talks about how he built his own server. Charles notes that your method of distributing your book will depend on your goal. If you want to make the most money possible, make your own site. If you want to get it into as many hands as possible, get it on Amazon. Many of the JavaScript Jabber panelists have had experience publishing books, and Jonathan shares that you can reach out to a publisher after you’ve self-published a book and they can get it distributed. Jonathan believes that If he had gone straight to a publisher, he would have gotten overwhelmed and given up on the book, but the step by step process of self-publishing kept things manageable. The panelists discuss difficulties encountered when publishing and editing books, especially with Markdown. Jonathan compares the perks of self-editing to traditional editing. Though he does not plan to opensource his entire editing pipeline, he may make some parts available. The show concludes with the panelists discussing the clout that comes with being a published author.  Panelists Charles Max Wood Christopher Buecheler  J.C. Hyatt With special guest: Jonathan Lee Martin Sponsors Adventures in Blockchain Sentry use the code “devchat” for 2 months free on Sentry’s small plan The Freelancers’ Show Links Big Nerd Ranch Digital Crafts JSJ 070: Book Club JavaScript Allonge with Reginald Braithwaite JavaScript Allonge by Reginald Braithwaite Functional Design Patterns for Express JS by Jonathan Lee Martin Node.js Express.js Koa Minjs  Sinatra Http.createserver Monads Middleware  Markdown Pandoc Diff-match-path library Epub MOBI LaTeX  Stripe Checkout Fstoppers Softcover Bookseller API  Follow DevChatTV on Facebook and Twitter Picks Christopher Buecheler: Cluisbrace.com newsletter J.C. Hyatt: Corsair wireless charging mouse pad Charles Max Wood: Magnetic whiteboard baskets Mrs. Piggle-Wiggle books Jonathan Lee Martin: Eric Elliot JS YellowScale Follow Jonathan and find his book at jonathanleemartin.com

Jonathan Lee Martin is an instructor and developer. He got his start in teaching at Big Nerd Ranch doing 1-2 week trainings for mid to senior developers, and then transitioned to 16 week courses for career switchers. He also worked for Digital Crafts for a year, and then wanted to focus on building out his own personal teaching brand. One of his first steps toward building his own brand was to publish his book, Functional Design Patterns for Express.js.The inspiration for Jonathan’s book came from his experience teaching career switchers. He wanted to experiment in the classroom with teaching functional programming in a way that would be very approachable and applicable and dispel some of the magic around backend programming, and that became the template for the book.  Jonathan loves the minimalist nature of Express.js and talks about its many uses. He believes that it knowing design patterns can take you pretty far in programming, and this view is related to his background in Rails. When he was working in Rails taming huge middleware stacks, he discovered that applying design patterns made builds take less time. He talks about other situations where knowing design patterns has helped. Express.js leans towards object oriented style over functional programming, and so it takes to these patterns well. Express.js has its shortcomings, and that’s where Jonathan’s favorite library Koa comes into play.  The conversation switches back to Jonathan’s book, which is a good way to start learning these higher level concepts. He purposely made it appealing to mid and senior level programmers, but at the same time it does not require a lot of background knowledge. Jonathan talks about his teaching methods that give people a proper appreciation for the tool. Jonathan talks more about why he likes to use Express.js and chose to use it for his book. He cautions that his book is not a book of monads, but rather about being influenced by the idea of composition over inheritance. He talks about the role of middleware in programming.  The panel asks about Jonathan’s toolchain and approach to writing books, and he explains how his books are set up to show code. They discuss the different forms required when publishing a book such as epub, MOBI, and PDF. Jonathan found it difficult to distribute his book through Amazon, so he talks about how he built his own server. Charles notes that your method of distributing your book will depend on your goal. If you want to make the most money possible, make your own site. If you want to get it into as many hands as possible, get it on Amazon. Many of the JavaScript Jabber panelists have had experience publishing books, and Jonathan shares that you can reach out to a publisher after you’ve self-published a book and they can get it distributed. Jonathan believes that If he had gone straight to a publisher, he would have gotten overwhelmed and given up on the book, but the step by step process of self-publishing kept things manageable. The panelists discuss difficulties encountered when publishing and editing books, especially with Markdown. Jonathan compares the perks of self-editing to traditional editing. Though he does not plan to opensource his entire editing pipeline, he may make some parts available. The show concludes with the panelists discussing the clout that comes with being a published author.  Panelists Charles Max Wood Christopher Buecheler  J.C. Hyatt With special guest: Jonathan Lee Martin Sponsors Adventures in Blockchain Sentry use the code “devchat” for 2 months free on Sentry’s small plan The Freelancers’ Show Links Big Nerd Ranch Digital Crafts JSJ 070: Book Club JavaScript Allonge with Reginald Braithwaite JavaScript Allonge by Reginald Braithwaite Functional Design Patterns for Express JS by Jonathan Lee Martin Node.js Express.js Koa Minjs  Sinatra Http.createserver Monads Middleware  Markdown Pandoc Diff-match-path library Epub MOBI LaTeX  Stripe Checkout Fstoppers Softcover Bookseller API  Follow DevChatTV on Facebook and Twitter Picks Christopher Buecheler: Cluisbrace.com newsletter J.C. Hyatt: Corsair wireless charging mouse pad Charles Max Wood: Magnetic whiteboard baskets Mrs. Piggle-Wiggle books Jonathan Lee Martin: Eric Elliot JS YellowScale Follow Jonathan and find his book at jonathanleemartin.com

Monads are real, y’all. They are all around us. In this metaphor-free episode, I’ll share two real-world monads you interact with all the time. No burritos or space suits, I promise! Plus, we’ll see why monads are useful in Haskell.

Cody Goodman and Taylor Fausak walk through inventing monads from scratch in JavaScript.

This week Danny and Mike confront the fearful menace of ... THE MONADS! Flee in stark unreasoning fear as Leibniz directs his monad army to isolate us from all we hold dear! Shiver in bone chilling terror as you are forced to join the monad legions with only coincidence for a friend. Giggle in solipsitic madness as they appear to be coming for you. YOU'RE NEXT!

Everyone talks about monads but monoids are where it’s at. Monoids are simple and make distributed computation a breeze. In this episode, we learn the two properties that make an operation a monoid, and how to use it do distributed computation.

In our thrilling hundred and fifty-fourth episode Fox and Conrad continue their journey through the Galaxy’s Greatest Comic with Progs 487-490 of 2000AD, covering September and October of 1986. This episode Judge Dredd deals with crime in Atlantis, The Wheeldebeasts attack in Metalzoic, Nemesis meets the Monads, and Strontium Dog’s path of RAGE reaches its … Continue reading Space Spinner 2000 ep 154

We talk with Brooklyn Zelenka from SPADE Co. about their current and past Elixir projects and how they are deployed. Brooklyn Zelenka - SPADE Co. (https://spade.builders/) Find Brooklyn elsewhere online: https://twitter.com/expede https://github.com/expede 1:08 - Brooklyn’s Background Brooklyn's background and experience with Elixir is deep. Huge open source contributor. Got started in Elixir just after Phoenix got to 1.0. 1:53 - Worked on several Elixir projects in production. 2:43 - Why she got into Elixir. - Real Time - More performant than Rails. - Great documentation - Industrial-grade 4:38 - When you wouldn't use Elixir. Easy to get stakeholder buy-in. Just point to WhatsApp. Elixir is made for 2019 CLI tools Repl-driven development TDD tools built in by default All the best practices we have today are built in. 7:14 - Where has Brooklyn hosted her apps? Heroku for POC's. AWS for production. Dockerized because "kubernetes is the new hotness" 9:40 - Do you do any clustering? Load balanced above. AWS load balancing is very standard. They're well understood and have a nice developer experience. 10:29 Are you able to get any zero downtime deploys? Zero downtime deploys. Awesome but impractical. Rolling deploys are easier and usually more appropriate. Some requirements make it valuable. Erlang error states. Exceptional. Allows you to build for the happy path. Don't worry about error handling all the time. Witchcraft and dark magic. Monads. Poke around the standard library. 12:50 - How does Elixir compare to Rails in terms of response times, and other aspects? 15:32 - What libraries do you use and what have you built? 22:41 - Any cool features of OTP you are using? 25:36 - One tip to developers new to Elixir Build up a peer-to-peer cli chat from scratch in one GenServer. Find her at @expede everywhere on the internet. Learn more about how SmartLogic uses Phoenix and Elixir. (https://smr.tl/2Hyslu8) Special Guest: Brooklyn Zelenka.

Andrew takes a deep dive into Leibniz's theory of "monads" to set up a series of Bonus Features playfully called "Monads."Episode Link for Sharinghttps://shows.pippa.io/reductio/monad1Leibniz's Monadologyhttps://www.earlymoderntexts.com/assets/pdfs/leibniz1714b.pdfInverted Spectrum Mediahttp://www.invertedspectrummedia.com See acast.com/privacy for privacy and opt-out information.

Mike breaks down the drama around nullable reference types in C# 8.0, and we debate what it means for the future of the language. Plus a fresh reminder of Apple's absolute App Store authority, and the state of Mike's relationship with the rust compiler.

Windowless MonadsGottfried Leibniz was a German philosopher who was a contemporary of Isaac Newton. He theorized the existence of Monads. Monads are an object of theory; they are supposed to be particles somewhat similar to our modern concept of the atom (with some significant differences). The TheoryThese particles are the underlying universal substrate. They are self-contained and indestructible. They each contain within themselves the essence of the entire universe, much like a kind of divine genetic code. Nevertheless, they also are distinct from one another, each having different attributes, resulting in the vast variety that we can see in nature.What he suggests is that the universe is a self-contained thing and that what we experience as a sequence of space and time, is really a coherent whole. He described monads as "windowless;" meaning, not being open to outside forces in any way. They do not take in or emit from themselves anything from or into anything outside of themselves. In this sense, they are similar to the modern atomic idea, in that we now theorize that atoms interact with other atoms, but under normal circumstances, atoms do not change in their fundamental nature.Leibniz's theory portrays a deterministic view of nature that, in some ways, anticipated Einstein's Theory of Relativity, in that it suggests that the universe is structured in a non-linear way. What I Find Provocative About this IdeaIn absolute terms, modern science has largely invalidated the Theory of Monads. Nevertheless, I find certain aspects of this idea interesting. For one thing, his idea is really quite fractal. This idea that the further you go down into the micro, the more the macro reveals itself is a very spiritual idea, and I think there is something to that. For example, atoms resemble solar systems and galaxies in terms of their basic geometric structure. That's interesting. The idea that each particle has a kind of genetic code that reflects the universe as a whole - that's interesting, too. Some Notes on "Windowless Monads"This piece uses an octatonic palate to portray monadic "windowlessness." The octatonic scale is "windowless," in the sense that it has a completely repetitive structure; whole-tone - half-tone, whole-tone - half-tone, all the way up the entire octave. Unlike tonal scales, which have seven scale degrees, the "octatonic" scale has eight. The seven scale degrees in tonal music give it a kind of built-in tension that seeks resolution. The octatonic scale seeks no resolution because it does not require it. It is naturally self-exploratory and does not need to come to any rest. In this way, it is "self-contained," in the same way that monads are theorized to be.However, I also wanted to portray my "windowless monads" as causing ephemera of time-bound existence. I show this by having the piece transition in and out of tonal sections. True to the monadic theory, the piece ends in a self-contained way - by returning to the original octatonic riff.Copyright, Philip John Cornell, 2018, some rights reserved. You may download this content freely. If you share it, it must be prominently attributed to "PJ Cornell," and if shared online, a link to the original content must be provided in a prominent location. This audio and video content may not be used for commercial purposes or modified in any way without permission from the copyright owner. Follow me on Soundcloud: https://soundcloud.com/pj-cornellFollow me on iTunes: (Asterisk Piano Podcast)Follow me on Steemit: https://steemit.com/@pjcomposerJoin the conversation on my site: http://pjcornell.com

Windowless MonadsGottfried Leibniz was a German philosopher who was a contemporary of Isaac Newton. He theorized the existence of Monads. Monads are an object of theory; they are supposed to be particles somewhat similar to our modern concept of the atom (with some significant differences). The TheoryThese particles are the underlying universal substrate. They are self-contained and indestructible. They each contain within themselves the essence of the entire universe, much like a kind of divine genetic code. Nevertheless, they also are distinct from one another, each having different attributes, resulting in the vast variety that we can see in nature.What he suggests is that the universe is a self-contained thing and that what we experience as a sequence of space and time, is really a coherent whole. He described monads as "windowless;" meaning, not being open to outside forces in any way. They do not take in or emit from themselves anything from or into anything outside of themselves. In this sense, they are similar to the modern atomic idea, in that we now theorize that atoms interact with other atoms, but under normal circumstances, atoms do not change in their fundamental nature.Leibniz's theory portrays a deterministic view of nature that, in some ways, anticipated Einstein's Theory of Relativity, in that it suggests that the universe is structured in a non-linear way. What I Find Provocative About this IdeaIn absolute terms, modern science has largely invalidated the Theory of Monads. Nevertheless, I find certain aspects of this idea interesting. For one thing, his idea is really quite fractal. This idea that the further you go down into the micro, the more the macro reveals itself is a very spiritual idea, and I think there is something to that. For example, atoms resemble solar systems and galaxies in terms of their basic geometric structure. That's interesting. The idea that each particle has a kind of genetic code that reflects the universe as a whole - that's interesting, too. Some Notes on "Windowless Monads"This piece uses an octatonic palate to portray monadic "windowlessness." The octatonic scale is "windowless," in the sense that it has a completely repetitive structure; whole-tone - half-tone, whole-tone - half-tone, all the way up the entire octave. Unlike tonal scales, which have seven scale degrees, the "octatonic" scale has eight. The seven scale degrees in tonal music give it a kind of built-in tension that seeks resolution. The octatonic scale seeks no resolution because it does not require it. It is naturally self-exploratory and does not need to come to any rest. In this way, it is "self-contained," in the same way that monads are theorized to be.However, I also wanted to portray my "windowless monads" as causing ephemera of time-bound existence. I show this by having the piece transition in and out of tonal sections. True to the monadic theory, the piece ends in a self-contained way - by returning to the original octatonic riff.Copyright, Philip John Cornell, 2018, some rights reserved. You may download this content freely. If you share it, it must be prominently attributed to "PJ Cornell," and if shared online, a link to the original content must be provided in a prominent location. This audio and video content may not be used for commercial purposes or modified in any way without permission from the copyright owner. Follow me on Soundcloud: https://soundcloud.com/pj-cornellFollow me on iTunes: (Asterisk Piano Podcast)Follow me on Steemit: https://steemit.com/@pjcomposerJoin the conversation on my site: http://pjcornell.com

Chris Toomey joins Derek to talk about their shared experience in Elm and their excitement about GraphQL. Chris on Twitter The Reader Monad — Part 1 Kind (type theory) Monads are like burritos Scala.js GraphQL | A query language for your API Tell Me When it Closes RailsConf 2017: In Relentless Pursuit of REST by Derek Prior Jobs at thoughtbot graphiql

Isabel Hardman finds out how urban wild flowers are saving our bugs and bees with Nick Packham from Buglife's Urban Buzz project, introduces the latest challenge, which is to find wild flowers growing on the pavement, and hears about the joy of monads (and what they are).

Isabel Hardman finds out how urban wild flowers are saving our bugs and bees with Nick Packham from Buglife's Urban Buzz project, introduces the latest challenge, which is to find wild flowers growing on the pavement, and hears about the joy of monads (and what they are).

Taylor and Joe are here to celebrate our fiftieth episode! The discussion begins with monads. In the second half: the philosophy of sport. Support Theory Talk: https://www.patreon.com/theorytalk Follow Theory Talk on Twitter: https://twitter.com/theory_talk

Monads, the promised land of functional programming. Or at least with all the hype they'd better be! Come join the cast as we demystify this overhyped structure that has become an indispensable part of many functional programmer's toolkits. Episode 18 patrons: Pluton Tim Buckley Huge shout out to Marcus Nielsen Show Notes: bind :: m a -> (a -> m b) -> m b Example of do syntax vs using bind aka >>=: main = do foo = (foo -> doOtherMonadyThing foo >>= (foo2 -> pure (whatever foo foo2)) ) Extracting a value from a Maybe extract :: Just Int -> Int extract foo = case foo of Just num -> num Nothing -> 0 Railroad oriented programming talk by Scott Wlaschin fsharpforfunandprofit.com/rop/ FP Chat Slack Community: https://fpchat-invite.herokuapp.com

Joy Clark talks with Sofia Vaughn-Jones (née Cole) about Scala. Sofia introduces the language and describes its features. They then discuss what kinds of programs can be written with Scala and the tooling and frameworks that are available. They attempt to define what a monad is and how it can be used. To wrap up, Sofia mentions some great resources for getting started with Scala.

AiA 147: Codelyzer and Static Analysis Tools for Angular with Minko Gechev The week on Adventures in Angular features panelists Alyssa Nicoll, Shi Resnick, Lukas Ruebbelk, and Charles Max Wood. The special guest this week is Minko Gechev who is here to discuss Codelyzer. Minko is currently working on a start up. Angular JavaScript is the programming language that excites him the most. How do you work in a start up and still have free time? He tries to find an overlap between the work he's doing in the startup and work he does in his spare time. This is why he had previous work that was completely Angular (Angular Seed). This startup is more complicated because the overlap isn't as much. What is Codelyzer?       Last year, he worked on the Angular Style Guide. He thought it was a good idea to have an automated way to verify a given project that follows the Angular Style Guide. He built on top of that and built Angular and provided similar style checks on top of templates, Angular CSS Styles inside of the components, and the Angular expressions inside of the templates. Codelyzer is a tool for static code analysis for Angular applications. How is it used?                                               It can be used as a set of rules on top of tslint. You install it with mpm. Then tslint performs static analysis and verifies whether the source code follows some style guidelines that our team has agreed upon. When Codelyzer is used, we can also analyze the templates on Angular applications. After that, you can confirm it follows these rules by running tslint on top of the entire project. How many of the default tslint rules do you agree with? Minko states that that is a lot of tslint and Angular rules that align and that he agrees with most of them. He does admit there are some he finds annoying, such as specific semi colon rules. Overall, he believes that if the team has agreed upon the rule, it is following in order to avoid arguing. What do you recommend as the best way to add Codelyzer to a project that started without it? He thinks you should add one rule at a time. All the wordings will be fixed one by one, eventually fixing the entire project. He has also started working on style analysis on top of the application, which is performance analysis. He doesn’t know what data the application will process. But he still considers that a given component will have performance if it has a huge -- in the template. So static analysis we can find such templates and eventually warn the users about eventual performance issues that are possible. How hard is it to add or change in Codelyzer? It might be slightly harder compared to tslint because there are more things that can be statically verified. In Tslint there's a visitor pattern. There is a classical design from the Ganga; it is used for the reversal of syntax 3 of a Typescript code. So when you implement the visitor pattern, you visit a specific construct, verify whether the name follows some guidelines. It is pretty much the same thing in Codelyzer but you can also implement the same visitor pattern for visiting the template of the component. Currently, the project has more than 20 contributors. It looks complicated but not if you spend 30 to 40 minutes looking at the code. What was the motivation behind going deep into Angular? The style was easy for static (automated) verification. This way saved a lot of time from code reviews. Code reviews still have to be performed, but at least can skip the verification from style guides because they can be automatically done. He likes compilers, it is the front end of a compiler: analyzing Syntax 3 part of a compiler itself interesting algorithms. There is another rule from Codelyzer being worked on that isn't completely stable yet. It is to find out which styles are actually used inside of the template. Codelyzer can find out some of the styles that are no longer applied to some of the styles within the template. This is not ready yet but it will be ready in a couple of configurations. Is the idea of searching through of finding either redundant or non-used style, is this something Codelyzer's doing for the very first time (no one has ever done it) or are there tools that this would replace? For Angular, there is no other tool like that. JavaScript or HTML may be close. The Browser can do that. If I want to write a rule do I take the abstract syntax and tell it what to look for? How does that work? You can’t learn it by heart, so I usually copy and paste the existing code and then modify it. It is a standard typescript rule so you need to provide an abstract rule; you'll need to provide the visitor. If the rule is super complicated, you need four visitors. Are you relying on tslint to break things down into tokens and the abstract syntax and then doing the work from there? Yeah. I did some extensions of tslint. Just extending tslint because it would have been too much work to create something from scratch. He is relying on tslint’s error reporting. So in order to set this up on a CI machine, it needs to be able to run node and install some mpm packages? Yes. Run node, install tslint, install Codelyzer and have this rule directory with the Codelyzer rules inside tslint. Is there a visual proof for knowing what the rule does? There is documentation on codelyzer.com/rules. Picks: Shi: Reflect API Driving on the right side of the road Minko Gechev Alyssa: Apple Airpods:https://www.apple.com/airpods Crutches Lukas: iPhone 7+ portrait mode: https://techcrunch.com/2016/09/21/hands-on-with-the-iphone-7-plus-crazy-new-portrait-mode/ Vulfpeck-1612: https://www.youtube.com/watch?v=jRHQPG1xd9o Charles: Angular Dev Summit www.angulardevsummit.com Minko: Pixel: https://madeby.google.com/phone/ Angular IO: https://angular.io/ Philip Wadler’s Monads for Functional Programming: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf  

AiA 147: Codelyzer and Static Analysis Tools for Angular with Minko Gechev The week on Adventures in Angular features panelists Alyssa Nicoll, Shi Resnick, Lukas Ruebbelk, and Charles Max Wood. The special guest this week is Minko Gechev who is here to discuss Codelyzer. Minko is currently working on a start up. Angular JavaScript is the programming language that excites him the most. How do you work in a start up and still have free time? He tries to find an overlap between the work he's doing in the startup and work he does in his spare time. This is why he had previous work that was completely Angular (Angular Seed). This startup is more complicated because the overlap isn't as much. What is Codelyzer?       Last year, he worked on the Angular Style Guide. He thought it was a good idea to have an automated way to verify a given project that follows the Angular Style Guide. He built on top of that and built Angular and provided similar style checks on top of templates, Angular CSS Styles inside of the components, and the Angular expressions inside of the templates. Codelyzer is a tool for static code analysis for Angular applications. How is it used?                                               It can be used as a set of rules on top of tslint. You install it with mpm. Then tslint performs static analysis and verifies whether the source code follows some style guidelines that our team has agreed upon. When Codelyzer is used, we can also analyze the templates on Angular applications. After that, you can confirm it follows these rules by running tslint on top of the entire project. How many of the default tslint rules do you agree with? Minko states that that is a lot of tslint and Angular rules that align and that he agrees with most of them. He does admit there are some he finds annoying, such as specific semi colon rules. Overall, he believes that if the team has agreed upon the rule, it is following in order to avoid arguing. What do you recommend as the best way to add Codelyzer to a project that started without it? He thinks you should add one rule at a time. All the wordings will be fixed one by one, eventually fixing the entire project. He has also started working on style analysis on top of the application, which is performance analysis. He doesn’t know what data the application will process. But he still considers that a given component will have performance if it has a huge -- in the template. So static analysis we can find such templates and eventually warn the users about eventual performance issues that are possible. How hard is it to add or change in Codelyzer? It might be slightly harder compared to tslint because there are more things that can be statically verified. In Tslint there's a visitor pattern. There is a classical design from the Ganga; it is used for the reversal of syntax 3 of a Typescript code. So when you implement the visitor pattern, you visit a specific construct, verify whether the name follows some guidelines. It is pretty much the same thing in Codelyzer but you can also implement the same visitor pattern for visiting the template of the component. Currently, the project has more than 20 contributors. It looks complicated but not if you spend 30 to 40 minutes looking at the code. What was the motivation behind going deep into Angular? The style was easy for static (automated) verification. This way saved a lot of time from code reviews. Code reviews still have to be performed, but at least can skip the verification from style guides because they can be automatically done. He likes compilers, it is the front end of a compiler: analyzing Syntax 3 part of a compiler itself interesting algorithms. There is another rule from Codelyzer being worked on that isn't completely stable yet. It is to find out which styles are actually used inside of the template. Codelyzer can find out some of the styles that are no longer applied to some of the styles within the template. This is not ready yet but it will be ready in a couple of configurations. Is the idea of searching through of finding either redundant or non-used style, is this something Codelyzer's doing for the very first time (no one has ever done it) or are there tools that this would replace? For Angular, there is no other tool like that. JavaScript or HTML may be close. The Browser can do that. If I want to write a rule do I take the abstract syntax and tell it what to look for? How does that work? You can’t learn it by heart, so I usually copy and paste the existing code and then modify it. It is a standard typescript rule so you need to provide an abstract rule; you'll need to provide the visitor. If the rule is super complicated, you need four visitors. Are you relying on tslint to break things down into tokens and the abstract syntax and then doing the work from there? Yeah. I did some extensions of tslint. Just extending tslint because it would have been too much work to create something from scratch. He is relying on tslint’s error reporting. So in order to set this up on a CI machine, it needs to be able to run node and install some mpm packages? Yes. Run node, install tslint, install Codelyzer and have this rule directory with the Codelyzer rules inside tslint. Is there a visual proof for knowing what the rule does? There is documentation on codelyzer.com/rules. Picks: Shi: Reflect API Driving on the right side of the road Minko Gechev Alyssa: Apple Airpods:https://www.apple.com/airpods Crutches Lukas: iPhone 7+ portrait mode: https://techcrunch.com/2016/09/21/hands-on-with-the-iphone-7-plus-crazy-new-portrait-mode/ Vulfpeck-1612: https://www.youtube.com/watch?v=jRHQPG1xd9o Charles: Angular Dev Summit www.angulardevsummit.com Minko: Pixel: https://madeby.google.com/phone/ Angular IO: https://angular.io/ Philip Wadler’s Monads for Functional Programming: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf  

AiA 147: Codelyzer and Static Analysis Tools for Angular with Minko Gechev The week on Adventures in Angular features panelists Alyssa Nicoll, Shi Resnick, Lukas Ruebbelk, and Charles Max Wood. The special guest this week is Minko Gechev who is here to discuss Codelyzer. Minko is currently working on a start up. Angular JavaScript is the programming language that excites him the most. How do you work in a start up and still have free time? He tries to find an overlap between the work he's doing in the startup and work he does in his spare time. This is why he had previous work that was completely Angular (Angular Seed). This startup is more complicated because the overlap isn't as much. What is Codelyzer?       Last year, he worked on the Angular Style Guide. He thought it was a good idea to have an automated way to verify a given project that follows the Angular Style Guide. He built on top of that and built Angular and provided similar style checks on top of templates, Angular CSS Styles inside of the components, and the Angular expressions inside of the templates. Codelyzer is a tool for static code analysis for Angular applications. How is it used?                                               It can be used as a set of rules on top of tslint. You install it with mpm. Then tslint performs static analysis and verifies whether the source code follows some style guidelines that our team has agreed upon. When Codelyzer is used, we can also analyze the templates on Angular applications. After that, you can confirm it follows these rules by running tslint on top of the entire project. How many of the default tslint rules do you agree with? Minko states that that is a lot of tslint and Angular rules that align and that he agrees with most of them. He does admit there are some he finds annoying, such as specific semi colon rules. Overall, he believes that if the team has agreed upon the rule, it is following in order to avoid arguing. What do you recommend as the best way to add Codelyzer to a project that started without it? He thinks you should add one rule at a time. All the wordings will be fixed one by one, eventually fixing the entire project. He has also started working on style analysis on top of the application, which is performance analysis. He doesn’t know what data the application will process. But he still considers that a given component will have performance if it has a huge -- in the template. So static analysis we can find such templates and eventually warn the users about eventual performance issues that are possible. How hard is it to add or change in Codelyzer? It might be slightly harder compared to tslint because there are more things that can be statically verified. In Tslint there's a visitor pattern. There is a classical design from the Ganga; it is used for the reversal of syntax 3 of a Typescript code. So when you implement the visitor pattern, you visit a specific construct, verify whether the name follows some guidelines. It is pretty much the same thing in Codelyzer but you can also implement the same visitor pattern for visiting the template of the component. Currently, the project has more than 20 contributors. It looks complicated but not if you spend 30 to 40 minutes looking at the code. What was the motivation behind going deep into Angular? The style was easy for static (automated) verification. This way saved a lot of time from code reviews. Code reviews still have to be performed, but at least can skip the verification from style guides because they can be automatically done. He likes compilers, it is the front end of a compiler: analyzing Syntax 3 part of a compiler itself interesting algorithms. There is another rule from Codelyzer being worked on that isn't completely stable yet. It is to find out which styles are actually used inside of the template. Codelyzer can find out some of the styles that are no longer applied to some of the styles within the template. This is not ready yet but it will be ready in a couple of configurations. Is the idea of searching through of finding either redundant or non-used style, is this something Codelyzer's doing for the very first time (no one has ever done it) or are there tools that this would replace? For Angular, there is no other tool like that. JavaScript or HTML may be close. The Browser can do that. If I want to write a rule do I take the abstract syntax and tell it what to look for? How does that work? You can’t learn it by heart, so I usually copy and paste the existing code and then modify it. It is a standard typescript rule so you need to provide an abstract rule; you'll need to provide the visitor. If the rule is super complicated, you need four visitors. Are you relying on tslint to break things down into tokens and the abstract syntax and then doing the work from there? Yeah. I did some extensions of tslint. Just extending tslint because it would have been too much work to create something from scratch. He is relying on tslint’s error reporting. So in order to set this up on a CI machine, it needs to be able to run node and install some mpm packages? Yes. Run node, install tslint, install Codelyzer and have this rule directory with the Codelyzer rules inside tslint. Is there a visual proof for knowing what the rule does? There is documentation on codelyzer.com/rules. Picks: Shi: Reflect API Driving on the right side of the road Minko Gechev Alyssa: Apple Airpods:https://www.apple.com/airpods Crutches Lukas: iPhone 7+ portrait mode: https://techcrunch.com/2016/09/21/hands-on-with-the-iphone-7-plus-crazy-new-portrait-mode/ Vulfpeck-1612: https://www.youtube.com/watch?v=jRHQPG1xd9o Charles: Angular Dev Summit www.angulardevsummit.com Minko: Pixel: https://madeby.google.com/phone/ Angular IO: https://angular.io/ Philip Wadler’s Monads for Functional Programming: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf  

Новости: Goodbye to Activator Багтрекер scala переехал на гитхаб (и release notes) 3 релиза 2.11.11, 2.12.2, 2.13.0-M1 Scala Native 0.2.0 Syntactic sugar for monad composition (or: “async/await” generalized) Hands-on Scala-Native - Ncurse Bandwidth Monitor Темы: Итоги очередного Scala митап в Москве: видео 1 видео 2 слайды Дениса Михайлова про Event Sourcing cлайды Григория Помадчина пример notebook Полезняшки: Scala abstractions and tooling around the Java Debugger Interface. Free as in Monads by Daniel Spiewak Голоса выпуска: Алексей Фомкин, Евгений Токарев

Новости: Strymonas TypeScript-Scala-Compiler Lagom - scala API scalafmt SBT plugin is looking for a new maintainer Lift Framework 3.0.0 Akka 2.4.14 Блоги: Monads in the category theory Akkapaint Видео: Is scala code slow? Темы: Базы данных и библиотеки Twitter stack JNI Полезняшки: scalaj-http FutureOr pushka - 2.12 Ведущие: Алексей Фомкин, Вадим Челышов, Алексей Романчук, Евгений Токарев, Григорий Помадчин

In this episode I talk with Bartosz Milewski. We talk his introduction to category theory, teaching category theory, comparison of Monads and other composition patterns in functional programming to composition patterns in object oriented programming, and finish with some philosophical thoughts on category theory.

The Pythagoreans were a cult of Greek mathematicians that believed that all things were composed of large enough integers. Their leader, Pythagoras, is best known for the proof that the square of the hypotenuse of a right triangle is equal to the sum of the squares of the two sides. Unfortunately, this theorem leads to the conclusion that some numbers cannot be expressed as the ratio of large enough integers, and so proof destroyed their beliefs. Monads are an extremely useful category of type. Whereas Applicatives let us build pipelines of single values, Monads support forking within that pipeline. They provide a "bind" method that joins a function returning another Monad to the end of the pipeline, and then flattens out the result. We can use this to build queries, to eliminate null reference exceptions, and even to execute asynchronous code without nested callbacks. Event Sourcing, popularized by Greg Young, is the practice of storing the events that have occurred in a system, instead of the current state of the system. The benefits are auditability, replayability, and reconciliation. Mathematically speaking, an event sourced system looks like a left fold operation. Starting with the initial state of the system, we apply a function that computes the next state of the system after an event has occurred. This left fold operation computes the current state from the sequence of events.

Connor and Dan discuss the philosophy of monads.

02:02 - Ray Hightower Introduction Twitter GitHub Blog WisdomGroup ChicagoRuby WindyCityRails WindyCityThings 03:22 - Parallella Raspberry Pi 05:39 - Web Developers and The Hardware World 12:38 - Does a hardware background inform software? 18:42 - Learning and Playing Verilog 22:22 - Concurrency and Parallelism The Most Energy Efficient Supercomputer on the Planet by Ray Hightower at Madison+ Ruby 2015 github.com/parallella/parallella-examples 32:48 - Getting Started with Parallella Parallella Quick Start Guide (with gotchas) COIK = Clear Only If Known parallella.org/forums 41:02 - Use Cases 42:38 - IoT (Internet of Things) HealthKit HomeKit WatchKit Picks Refactoring Ruby with Monads (Coraline) Ruby Rogues Episode #120: Book Club: Understanding Computation with Tom Stuart (Chuck) Learning to play the piano (Jessica) Mogo Portable Seat (Chuck) Rob Pike: Concurrency Is Not Parallelism (Ray) Designing and Building Parallel Programs by Ian Foster (Ray)

02:02 - Ray Hightower Introduction Twitter GitHub Blog WisdomGroup ChicagoRuby WindyCityRails WindyCityThings 03:22 - Parallella Raspberry Pi 05:39 - Web Developers and The Hardware World 12:38 - Does a hardware background inform software? 18:42 - Learning and Playing Verilog 22:22 - Concurrency and Parallelism The Most Energy Efficient Supercomputer on the Planet by Ray Hightower at Madison+ Ruby 2015 github.com/parallella/parallella-examples 32:48 - Getting Started with Parallella Parallella Quick Start Guide (with gotchas) COIK = Clear Only If Known parallella.org/forums 41:02 - Use Cases 42:38 - IoT (Internet of Things) HealthKit HomeKit WatchKit Picks Refactoring Ruby with Monads (Coraline) Ruby Rogues Episode #120: Book Club: Understanding Computation with Tom Stuart (Chuck) Learning to play the piano (Jessica) Mogo Portable Seat (Chuck) Rob Pike: Concurrency Is Not Parallelism (Ray) Designing and Building Parallel Programs by Ian Foster (Ray)

02:02 - Ray Hightower Introduction Twitter GitHub Blog WisdomGroup ChicagoRuby WindyCityRails WindyCityThings 03:22 - Parallella Raspberry Pi 05:39 - Web Developers and The Hardware World 12:38 - Does a hardware background inform software? 18:42 - Learning and Playing Verilog 22:22 - Concurrency and Parallelism The Most Energy Efficient Supercomputer on the Planet by Ray Hightower at Madison+ Ruby 2015 github.com/parallella/parallella-examples 32:48 - Getting Started with Parallella Parallella Quick Start Guide (with gotchas) COIK = Clear Only If Known parallella.org/forums 41:02 - Use Cases 42:38 - IoT (Internet of Things) HealthKit HomeKit WatchKit Picks Refactoring Ruby with Monads (Coraline) Ruby Rogues Episode #120: Book Club: Understanding Computation with Tom Stuart (Chuck) Learning to play the piano (Jessica) Mogo Portable Seat (Chuck) Rob Pike: Concurrency Is Not Parallelism (Ray) Designing and Building Parallel Programs by Ian Foster (Ray)

This week we had a topic planned and everything. Y'all had been asking for it and we were finally gonna do it! MVVM in practice. No bullshit. But then a heinous crime was committed that broke the monadic laws that keep our society civil and just. Tune in to hear Swift's public defender (played by Mark Adams) attempt to justify a new implementation of flatMap to Judge Dredd (played by Golden Fontenot). New implementation of flatMap() in Swift 2.0 Antitypical/Result

Monads are the talk of the town right now, everyone is saying something about them and much of it makes little sense, especially when you try and combine the messages from all of the sources. This talk will take a different tack. We will have a quick definition of a few terms and concepts, but that will be quick and to the point. Instead I will concentrate on the mechanics of Monads, why you would want to use them at all, how you can use them to solve real problems in different situations, and what we can ask for from our languages and tools to make them even more useful and easy to adopt. Along the way we will look at many examples in Java 8, and how syntactic constructs ease their use in languages like Scala and Haskell.

On this episode of the podcast, we begin our discussion of Gottfried Leibniz. First, we find out what important invention created a riff between Leibniz and Isaac Newton. Next, we learn about Leibniz’s theory of Monads (which are basically the atoms of the spirit world), and how they are programmed to ensure that we are living in the best of all possible worlds. Finally, we learn about Leibniz’s distinction between “necessary truths” and “truths of fact,” and how knowing the difference can save you a lot of time and confusion. All this and more on the latest episode of Philosophize This! Support the show on Patreon! www.philosophizethis.org for additional content. Thank you for wanting to know more today than you did yesterday. :)

Monads are the talk of the town, and everyone's doing them. In the virtual monad gold-rush, however, have we lost sight of some of the other useful tips, tricks and patterns that have got us to where we are. In this session I will examine a number of useful code snippets and ideas that I have used successfully on many projects, sometimes alongside monads, to great effect. There may be some useful corner cases you have overlooked, or perhaps just would like a refresher in some of the things you may have discovered but then forgotten. This talk is suitable for Scala beginners but (I hope) will be of use to more experienced Scala developers as well, even if only as a gentle reminder about some of the tricks used, or perhaps in the effective combinations of some of them that have proven useful over time. To view the video visit www.parleys.com. To get started building Reactive Apps visit www. typesafe.com/activator.

Most of us have an experience of functional programming that is isolated to small libraries or specific immutable data structures. But can we design our entire application architecture in a purely functional way? Can we do "aspect-oriented" programming with cross-cutting concerns that are compositional and checked by the type system? Yes we can, and in this talk we will look at a conceptually simple recipe for making that happen. We will see that the best things in Scala are Free. Video Available on www.parleys.com.