Podcast appearances and mentions of scott wlaschin

This time we talk with Scott Wlaschin, author of a book and a workshop titled Functional Programming Made Functional.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home. Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss the origins of Scott's book, why DDD and Functional Programming work well together, what type of exercises we'll be doing in the workshop, how opening a blog can be a great asset, Scott's first approach to DDD and much more.Who: Scott Wlaschin is a developer, architect, and author. He is the author of the popular F# website fsharpforfunandprofit.com, and the book Domain Modeling Made Functional, published by Pragmatic Bookshelf.Workshop link: https://bit.ly/Scott_Wlaschin_DDD_FSharp_Podcast#DomainDrivenDesign #FunctionalProgramming #FSharp #DomainModeling #Software #SoftwareDevelopment #ProgrammingLanguages #DDDesign #EventStorming

This time we talk with Scott Wlaschin, author of a book and a workshop titled Functional Programming Made Functional.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home. Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss the origins of Scott's book, why DDD and Functional Programming work well together, what type of exercises we'll be doing in the workshop, how opening a blog can be a great asset, Scott's first approach to DDD and much more.Who: Scott Wlaschin is a developer, architect, and author. He is the author of the popular F# website fsharpforfunandprofit.com, and the book Domain Modeling Made Functional, published by Pragmatic Bookshelf.Workshop link: https://bit.ly/Scott_Wlaschin_DDD_FSharp_Podcast#DomainDrivenDesign #FunctionalProgramming #FSharp #DomainModeling #Software #SoftwareDevelopment #ProgrammingLanguages #DDDesign #EventStorming

Richard talks with Scott Wlaschin, author of the book Domain Modeling Made Functional and the website F# for Fun and Profit, about using F# in production and the minimal essence of functional programming.

Scott Wlaschin is an expert on F#, author of the popular F# site fsharpforfunandprofit.com, and a board member of the F# Software Foundation. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world.   Topics of Discussion: [2:40] Scott talks about how he got into F#, and the nonlinear path his career has taken. [4:00] Scott walks us through the history of F#. [6:52] What types of applications should developers be looking at F# for? [10:55] What was Scott's inspiration behind writing Domain Modeling Made Functional? [12:20] Domain-driven design has nothing to do with a particular language. It's a process. [17:32] As an industry, whether it be literature or art, there's so much to be gained by observing and reading prior works of others. [19:55] How does functional thinking impact architecture? [20:51] In functional programming, you want everything to be deterministic. [28:34] What are some of the examples of transcription scripts? [31:10] In functional programming, the main thing is the function and not the object.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's YouTube Jeffrey Palermo's Twitter — Follow to stay informed about future events! F# Software Foundation Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: [3:00] “I started learning functional programming because I sort of felt like I really knew everything there was to know about databases and all that stuff. I thought I wanted something different.” — Scott [8:52] “It really depends on how you like to program. If you like to program in a functional style, and you want to be on .NET, then F# is perfect.” — Scott [12:00] “Don't focus on the technology, focus on what you are actually trying to build.” — Scott [17:32] “As an industry, whether it be literature or art, there's so much to be gained by observing and reading prior works of others.” — Jeffrey   Scott:  Website | Twitter

“It is good to improve your processes to make them faster and more efficient. But sometimes what's even more important is doing the right thing in the first place." Scott Wlaschin is the author of “Domain Modeling Made Functional” and the popular F# site fsharpforfunandprofit.com. In this episode, Scott began by sharing his view of the need for developers today to become more polyglot developers and learn multiple programming languages. Scott then shared about functional programming (FP) fundamentals and how FP differs with object-oriented programming, as well as cases when one is better suited than the other. Scott then explained how we can use FP when implementing Domain-Driven Design (DDD), including how to model some of the DDD tactical designs and transaction boundary. He also shared why F# is his favorite and go-to programming language. Towards the end, Scott touched on important advice about effectiveness vs efficiency, and what leaders need to be aware of regarding doing the right thing. Listen out for: Career Journey - [00:06:16] Polyglot Developer - [00:11:01] Functional Programming - [00:14:59] Case for OOP - [00:19:56] DDD and FP - [00:21:02] Modeling Tactical Design in FP - [00:24:10] Modeling Transaction - [00:28:49] F# - [00:32:22] Effective Instead of Efficient - [00:34:43] Advice on Valuing Effectiveness - [00:38:31] 3 Tech Lead Wisdom - [00:40:30] _____ Scott Wlaschin's Bio Scott Wlaschin is a developer, architect and author. He is the writer behind the popular F# site fsharpforfunandprofit.com, and the book ‘Domain Modeling Made Functional' published by Pragmatic Bookshelf. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world. Follow Scott: Twitter – @ScottWlaschin LinkedIn – https://www.linkedin.com/in/scottwlaschin F# for Fun and Profit – https://fsharpforfunandprofit.com/ Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/79.

In this group episode I was joined by Scott Wlaschin, Isaac Abraham, and Ian Russell - to talk all about F#! This is .NET's functional programming language, and we discussed functional programming, and the benefits of using a functional programming language like F#, whilst also comparing it to other languages like C#.For a full list of show links, see the website here(there were too many links to include here!)

In this episode of Elixir Mix, we’re joined by Lau Tornskau, creator of the tzdata library and prolific Elixir open-source contributor, to talk about how to ensure “correctness” of time-related data in Elixir and how Elixir’s standard library has grown to include native support for handling time zones. Sponsors Audible.com Groxio.io | Career Rocket Fuel For Curious Coders CacheFly Panel Alex Koutmos Mika Kalathil Bruce Tate Lars Wikman Sophie DeBenedetto Guest Lau Taarnskov Links www.creativedeletion.com http://twitter.com/laut https://github.com/lau Picks Alex Koutmos: Dynamically Configure Your Plugs at Run-time An IoT Birdhouse with Elixir Nerves & Phoenix LiveView Components Bruce Tate: Why Things Fail, a series on failure with Brian Troutwine and Bruce Tate The Problem with Time & Timezones – Computerphile Sophie DeBenedetto: You might not need the Calendar or Timex libraries Lau Taarnskov: We’re hiring – TheRealReal Domain Modeling Made Functional by Scott Wlaschin Follow us on Twitter: @elixir_mix

In this episode of Elixir Mix, we’re joined by Lau Tornskau, creator of the tzdata library and prolific Elixir open-source contributor, to talk about how to ensure “correctness” of time-related data in Elixir and how Elixir’s standard library has grown to include native support for handling time zones. Sponsors Audible.com Groxio.io | Career Rocket Fuel For Curious Coders CacheFly Panel Alex Koutmos Mika Kalathil Bruce Tate Lars Wikman Sophie DeBenedetto Guest Lau Taarnskov Links www.creativedeletion.com http://twitter.com/laut https://github.com/lau Picks Alex Koutmos: Dynamically Configure Your Plugs at Run-time An IoT Birdhouse with Elixir Nerves & Phoenix LiveView Components Bruce Tate: Why Things Fail, a series on failure with Brian Troutwine and Bruce Tate The Problem with Time & Timezones – Computerphile Sophie DeBenedetto: You might not need the Calendar or Timex libraries Lau Taarnskov: We’re hiring – TheRealReal Domain Modeling Made Functional by Scott Wlaschin Follow us on Twitter: @elixir_mix

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!

Уже совсем скоро очередной DotNext, а мы только-только разобрали все материалы с предыдущего. Представляем Вам набор интервью с самыми именитыми спикерами DotNext 2019 (MSK). P.S.: Данный выпуск на английском языке. Если у Вас есть желание помочь нам с сурдопереводом, пишите нам в VK, Telegram или Twitter. Мы часто экспериментируем и нам очень важно Ваше мнение. … Continue reading "#32 выпуск подкаста DotNet&More: Raffaele Rialdi, Jon Galloway, Christophe Nasarre-Soulier, Pavel Yosifovich, Scott Wlaschin и не только"

Уже совсем скоро очередной DotNext, а мы только-только разобрали все материалы с предыдущего. Представляем Вам набор интервью с самыми именитыми спикерами DotNext 2019 (MSK). P.S.: Данный выпуск на английском языке. Если у Вас есть желание помочь нам с сурдопереводом, пишите нам в VK, Telegram или Twitter. Мы часто экспериментируем и нам очень важно Ваше мнение. Поделитесь им с нами в опросе: https://forms.gle/PpZUR5oKpeW7ibRW9 Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы. Ссылка для скачивания: https://dotnetmore.ru/wp-content/uploads/2020/05/DotNetAndMore-32-StarSpeakers.mp3 Shownotes: - [0:01:25] Raffaele Rialdi: C#8 vs F# vs C++ - [1:01:04] Jon Galloway: Судьба WCF и Open Source - [1:21:07] Christophe Nasarre-Soulier: Performance, Metrics, Debbuging - [2:01:49] Pavel Yosifovich: Windows Intenals, WPF, Machine Learning и не только - [2:40:31] Scott Wlaschin: F# Ссылки: - https://2019.dotnext-moscow.ru/# : DotNext Moscow 2019 Слушайте и скачивайте нас на сайте: https://dotnetmore.ru/podcast/32-dotnext3/ Не забывайте оставлять комментарии: https://vk.com/dotnetmore?w=wall-175299940_233

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

In this weeks episode we are lucky to have Scott Wlaschin back on the show to discuss his most recent talk ‘Four Languages from Forty Years Ago’. We start off by talking about why the 1970’s was such an influential decade for language design. This leads us on to highlight what a programming language fundamentally is, and explain the many different paradigms that are present. From here, we explain the issue with throwing out the design phase completely when building software, and the interesting points made in Richard Gabriel’s ‘Worse is Better’ essay. Finally, we try to make sense of why all popular programming languages today follow a very similar style, and what is with all the curly braces?!

In this weeks episode we are lucky to have Scott Wlaschin back on the show to discuss design within software. We start off by highlighting leaky abstractions, adopted tool-chains and transpiling languages into JavaScript. From here we move on to talk about what makes ‘good code’, and how evaluating this is heavily reliant on the requirements and context you are in. Finally, we discuss how OO and FP software architectures differ, advantages of being explicit over implicit and information-hiding at API boundaries.

In this weeks episode we are lucky to have Scott Wlaschin back on the show. We start of discussion by highlighting his most recent talk on composition and some useful analogies to Lego, Brio and Unix. From here we move on to investigate function and type composition, the difference between a paradigm shift compared to simply a syntax one and the advantages of an opinionated language. This leads us on to mention how within application design pushing the side-effects to the edge and keeping the core domain pure is beneficial. Finally, we touch upon testing in functional languages, experiences whilst consulting and Rich Hickey’s ‘Effective Programs’ talk.

In this weeks episode we chat to Scott Wlaschin about his new book ‘Domain Modeling Made Functional’. We start off the show discussing how the book came to be, the process of writing a book and melding the worlds of Domain Modeling/Functional Programing. This leads us on to highlight what Domain Driven Design is, the importance of communication and the difference between the solution/problem space to garner a shared model. Finally, we touch upon some of the common patterns that come out of modeling domains such as - how Entities and Value Objects provide identity, maintaing invariants using Aggregates, and communication between modals via Anti-Corruption Layers.

Ready to try on F#? While at NDC Oslo, Carl and Richard chatted with Scott Wlaschin about what C# developers need to know to get started with F#. Scott talks a bit about his own history with development which ties in with the evolution of functional programming which in a way lost out to object-oriented programming back in the 1980s. Not that the two approaches are mutually exclusive, and Scott discusses how objects and functions live happily together in F#. It's a different way of thinking, but can be a very productive way to build applications - check it out!Support this podcast at — https://redcircle.com/net-rocks/donations

Ready to try on F#? While at NDC Oslo, Carl and Richard chatted with Scott Wlaschin about what C# developers need to know to get started with F#. Scott talks a bit about his own history with development which ties in with the evolution of functional programming which in a way lost out to object-oriented programming back in the 1980s. Not that the two approaches are mutually exclusive, and Scott discusses how objects and functions live happily together in F#. It's a different way of thinking, but can be a very productive way to build applications - check it out!Support this podcast at — https://redcircle.com/net-rocks/donations

In this episode I talk with Scott Wlaschin. We talk on the topic of his upcoming book Domain Modeling Made Functional, and using F# (and ML family type system languages) with Domain Driven Design.

In this weeks show we follow on from our previous episode’s discussion with Scott Wlaschin. We delve into separating out the client from the behaviour and state, initially highlighting the Batch Command approach. From here, we move on to discuss the Actor Modal, Event Sourcing and Functional Reactive Programming solutions. Finally we touch upon handling the behavioural dependencies, followed by creating an Interpreter and Capability-based implementations.

In this weeks episode we are lucky to be joined by Scott Wlaschin again, to discuss his recent ‘Thirteen ways of looking at a turtle’ talk. We start off discussion highlighting the value of solving a known problem in many different ways and the inspiration behind the talk. This leads us on to chat about the Object-oriented and Abstract Mutable/Immutable Data Model solutions, mentioning each ones merits as a way to solve the problem. We then move on to highlight the State, Either and Async Monad solutions, and how they aid in function composition of different ‘shapes’. Finally, we mention how good code should be boring, the balance of the abstract vs. concrete and transparency in code.

In this weeks episode we are joined by Jimmy Burrell and Scott Wlaschin to discuss all things functional. We start off the show highlighting how Scott got into programming, the reasons why he is a big fan of Smalltalk, what he means by ‘Enterprise OO’ and being a Humanistic programmer. From here we discuss how he got into FP, how the paradigm came to being, what FP is to Scott and why you should consider it. Finally, we mention the differences between types in FP over langauges such as C, the railway track metaphor he uses to help explain FP concepts and architectural patterns that are more or less suited to FP.

In this episode I talk with Scott Wlaschin. We talk his introduction to functional programming and F#, making the ideas accessible without needing a math background, functional programming being similar to object oriented programming taken to the extreme, and much, much more

Denne episoden av Bekk Open Podcast handler som det funksjonelle paradigmet. Vi har besøk av Jonas Follesø og Tomas Jansson som kommer og snakker om funksjonell programmering sammen med oss. Vi er innom hva, hvorfor og hvordan, og ikke minst hvordan det funksjonelle opptrer både i gui- og i backend-programmering. CQRS, stream-processing, React og Event Sourcing er teknologier som blir nevnt.Noen lenker:Tomas sin blogg serie om CQRS og event sourcing: http://open.bekk.no/polyglot-heaven-a-response-to-the-bekk-radarPure functional applications: http://blog.2mas.xyz/your-application-should-be-a-pure-function/En tutorial om event sourcing og CQRS som Tomas har satt sammen: https://github.com/mastoj/LibAASWhy use F# av Scott Wlaschin: http://fsharpforfunandprofit.com/why-use-fsharp/Low risk ways to use F# at work, også av Scott Wlaschin: http://fsharpforfunandprofit.com/series/low-risk-ways-to-use-fsharp-at-work.htmlDoes the language you use make a difference av Simon T. Cousins (ref. 300000 rader —> 30000 rader): http://simontylercousins.net/does-the-language-you-use-make-a-difference-revisited/Utforskende programmering med F# Type Providers http://www.open.bekk.no/#!utforskende-programmering-med-fsharp-type-providersEasier UI Reasoning with Unidirectional Dataflow and Immutable Data - https://open.bekk.no/easier-reasoning-with-unidirectional-dataflow-and-immutable-dataBlogpost om Flux og CQRS: http://jaysoo.ca/2015/02/06/what-the-flux/Reux: http://redux.js.org/Second Machine Age: http://secondmachineage.com.NET Rocks: http://www.dotnetrocks.comBartJS: http://bartjs.io/Mustafas Gemüse Kebap ;) http://www.mustafas.de/

Guest: Scott Wlaschin @ScottWlaschin Full show notes are at https://developeronfire.com/podcast/episode-031-scott-wlaschin-learn-from-diverse-sources

This episode features an interview with Scott Wlaschin. Scott has over 20 years experience in software development, design and architecture, covering all aspects of business software. He is the creator of the popular F# web site, fsharpforfunandprofit.com, and has done many F# presentations at conferences and user-groups around the world. Follow Scott on twitter: @ScottWlaschin This interview was recorded on the 18th of May 2015 at the Infi offices in Utrecht. Interview by @freekl and @daan_van_berkel Links for this podcast: Scott's blog is fsharpforfunandprofit.com Presentation: Functional Design Patterns. From the BuildStuff conference 2014. Uncle bob wrote this blogpost about it Presentation: From NDC 2014 'Domain Modelling with the F# type system'. The F# Foundation is on fsharp.org Presentation: Here's where Dean Wrampler talks about Anemic domain models Book: The Design of Everyday Things, Don Norman. (Revised and Expanded Edition, 2013) Book: Design for the Real World: Human Ecology and Social Change, Victor Papanek, 2005 Book: The Little Schemer, Felleisen and Bibby, 1995 (4th edition)   This podcast is in English - Deze podcast is in het Engels