Podcast appearances and mentions of eric normand

On today's episode, I sit down with Eric Normand to discuss how to select good customers, the importance of sales and marketing to a freelancer, the importance of imagination, industry, and optimism, the purpose of consulting, how I structure my consulting services, other ideas for consulting structures, domain modeling, tech debt vs dull knives as a metaphor, how product design influences domain modeling, how having a theory of your product impacts domain modeling, the abundance of bad advice for new consultants, and the pros and cons of masterminds.Eric Normand.meEric Normand's NewsletterEric Normand's Clojure GuidesEric Normand's Clojure Video CoursesThe Eric Normand PodcastMillion Dollar Consulting by Alan Weiss99 Bottles of OOP by Sandi MetzEric Normand on LinkedInEric Normand on Twitter

Fredrik is joined by Eric Normand for a discussion of debugging your ideas through domain modeling, using Eric's concept of lenses to find more good questions to ask. Eric is writing a book about domain modeling and has developed the concept of lenses - ways to look at various aspects of your domain, model, and code in order to better consider various solutions and questions. Why? Because design is needed, but is easily lost in the modern urge to be fast and agile. There's a lot you can and need do on the way to a working system. Eric pushes for design which is an integral part, perferably right in the code, rather than a separate one which can become outdated and separated without anyone noticing. Just spend a little more time on it. Tricks for seeing your domain with fresher eyes. Change is not always maximal and unpredictable! But thinking it is can lead to a lot of indirection and abstraction where a single if-statement could have sufficed for years. Refactoring as a way of finding the seams in your model. What is the code actually supposed to do? How does it actually fit with the domain? Recorded during Øredev 2023, where Eric gave two presentations about the topics discussed: Better software design with domain modeling and Stratified design and functional architecture. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Eric Eric's Øredev 2023 presentations: Better software design with domain modeling *Stratified design and functional architecture Eric has his own podcast Grokking simplicity - Eric's book on functional programming Domain modeling Waterfall UML Clojure REPL - Red-evaluate-print loop Kodsnack 294 - the episode where Dan Lebrero gave Fredrik a feel for REPL-driven development Domain modeling lenses Drawing on the right side of the brain The “keynote yesterday” - Na'Tosha Bard about code outliving you (see also episode 558) Then a miracle occurs Titles I'm really on to something Anti-design trend In a waterfall world On the way to code Experimentation in code Not about moving your hand I don't want rules Yes, that's the right question! Take five minutes Spending more time on it Code lets me play with ideas I'm happy working on a whiteboard Debug your ideas Server babysitters

Fredrik is joined by Eric Normand for a discussion of debugging your ideas through domain modeling, using Eric’s concept of lenses to find more good questions to ask. Eric is writing a book about domain modeling and has developed the concept of lenses - ways to look at various aspects of your domain, model, and code in order to better consider various solutions and questions. Why? Because design is needed, but is easily lost in the modern urge to be fast and agile. There’s a lot you can and need do on the way to a working system. Eric pushes for design which is an integral part, perferably right in the code, rather than a separate one which can become outdated and separated without anyone noticing. Just spend a little more time on it. Tricks for seeing your domain with fresher eyes. Change is not always maximal and unpredictable! But thinking it is can lead to a lot of indirection and abstraction where a single if-statement could have sufficed for years. Refactoring as a way of finding the seams in your model. What is the code actually supposed to do? How does it actually fit with the domain? Recorded during Øredev 2023, where Eric gave two presentations about the topics discussed: Better software design with domain modeling and Stratified design and functional architecture. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @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 Eric Eric’s Øredev 2023 presentations: Better software design with domain modeling *Stratified design and functional architecture Eric has his own podcast Grokking simplicity - Eric’s book on functional programming Domain modeling Waterfall UML Clojure REPL - Red-evaluate-print loop Kodsnack 294 - the episode where Dan Lebrero gave Fredrik a feel for REPL-driven development Domain modeling lenses Drawing on the right side of the brain The “keynote yesterday” - Na’Tosha Bard about code outliving you (see also episode 558) Then a miracle occurs Titles I’m really on to something Anti-design trend In a waterfall world On the way to code Experimentation in code Not about moving your hand I don’t want rules Yes, that’s the right question! Take five minutes Spending more time on it Code lets me play with ideas I’m happy working on a whiteboard Debug your ideas Server babysitters

Robby has a chat with software engineer, trainer, and author of the book Grokking Simplicity, Eric Normand (he/him/his). As Eric reflects on his experience, the first thought he has of well-maintained software is that it's like a unicorn (Something you can't find in real life), but on a more serious note, he emphasizes that smaller code bases are easier to maintain and that the maintainability of a code base is also highly dependent on the team of engineers that are working on it.Robby and Eric will dive into the pros and cons of microservices in small organizations, why teams need to ensure they know where they're going with the future of their codebase, Eric's book - Grokking Simplicity, the differences within a functional programming language, higher-order functions, Eric's journey toward authoring a technical book, and the value of engineers being able to get comfortable moving code around in a project without needing to ask for permission first. Tune in and enjoy!Book Recommendations:Book Recommendation: The Timeless Way of Building by Christopher W. Alexander>Helpful Links:Grokking Simplicity By Eric Normand, ManningEric's WebsiteEric on LinkedInEric on TwitterSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Richard talks to Eric Normand about his experiences using both Haskell and Clojure in production, and his perspectives on comparing and contrasting the approaches of the two languages. Eric hosts a podcast (https://ericnormand.me/podcast) and you can use code podsoftunsc22 at checkout to get a discount on his book Grokking Simplicity: https://www.manning.com/books/grokking-simplicity

Episode Notes It was a great pleasure to speak again with our friend @ericnormand about Alan Kay, Lisp, Mr Wizard, Logo and much more! Enjoy! Mr Wizard TV TV series The Logo programming language Alan Kay The TCP/IP stack Paul Graham Essays The 50th anniversary of Lisp conference The Little Schemer book by Dan Friedman Frequencies clojure function Grokking Simplicity book

JS Party listeners and panelists celebrate our favorite moments from the past 100 episodes! You'll hear from over 20 of your favorite voices across 14 episodes. We also share some behind-the-scenes and read/hear from listeners! Here's to the last 200 episodes, and the next 200 as well.

JS Party listeners and panelists celebrate our favorite moments from the past 100 episodes! You'll hear from over 20 of your favorite voices across 14 episodes. We also share some behind-the-scenes and read/hear from listeners! Here's to the last 200 episodes, and the next 200 as well.

YASSS, MY MAN! This is one for the history books, my friends. I got to chat with one of my favorite clojureverse role models of all time: Eric Normand!! We hear about his new book titled "Grokking Simplicity" published by Manning (discount codes below!!). We hear a little about his life and personal history in regards to how he got into creating instructional content (peace core? COOL!) He shares his thoughts illustrating key concepts that will help you to be a wise architect while planning out and developing a software project. Questions regarding asynchronous logic, mutable data (don't be scared my peeps) We discuss how to uncover the "universal truths" in your code base so you can write better code. We get to the bottom of the meaning of "domain driven development" and how to compares it to a more data oriented approach. Personally, I credit his instructional work with the basis of my entry into the clojureverse, and I know I'm not the only one. ENJOY! Places to find Normy: https://purelyfunctional.tv/ https://twitter.com/ericnormand/ https://lispcast.com/ His new book: https://www.manning.com/books/grokking-simplicity Special Offer from Manning Publishers!! Here is a permanent 35% discount code (good for all our products in all formats) for your listeners: podlambduhhs21 You can refer to this link: http://mng.bz/drjN It will last for two months. Here is a link to the book we recommend "Data Oriented Programming" by Yehonathan Sharvit https://www.manning.com/books/data-oriented-programming

durée : 00:12:47 - Les bonnes ondes de France Bleu La Rochelle

In this conversation about software engineering, Lucas Dohmen talks with Eric Normand. Eric first explains the origins of his book, Grokking Simplicity. He explains how to think in calculations, actions, and data. Lucas asks him about real-life situations dealing with concurrency and how he would solve them thinking functionally. Then they dive deep into their conversation about immutability, type systems, and learning from other communities.

Sascha Wolf joins the mix to talk about how to test behaviors in your Phoenix apps by using tools like Mox and Knigge. Panel Adi Iyenger Allen Wyma Charles Max Wood Eric Bolikowski Guest Sascha Wolf Sponsors Dev Influencers Accelerator Links Twitter: Sascha Wolf ( @wolf4earth ) Picks Adi- Testing Elixir by Andrea Leopardi and Jeffrey Matthias Adi- GitHub | gleam-lang/gleam Allen- The Pragmatic Studio Charles- Flying High with Flutter Charles- Premium | Devchat.tv Charles- Ruby Rogues | Devchat.tv Charles- Back Market Eric- Grokking Simplicity by Eric Normand Sascha- Humans vs Computers

Sascha Wolf joins the mix to talk about how to test behaviors in your Phoenix apps by using tools like Mox and Knigge. Panel Adi Iyenger Allen Wyma Charles Max Wood Eric Bolikowski Guest Sascha Wolf Sponsors Dev Influencers Accelerator Links Twitter: Sascha Wolf ( @wolf4earth ) Picks Adi- Testing Elixir by Andrea Leopardi and Jeffrey Matthias Adi- GitHub | gleam-lang/gleam Allen- The Pragmatic Studio Charles- Flying High with Flutter Charles- Premium | Devchat.tv Charles- Ruby Rogues | Devchat.tv Charles- Back Market Eric- Grokking Simplicity by Eric Normand Sascha- Humans vs Computers

Common Lisp was written in the 80s as a kind of an amalgam of the existing Lisps at the time. To make sure the Common Lisp would stay relevant, it was made backward compatible so that existing legacy systems could run on it. One thing in common to these big old systems like Lisp is a lot more mutation, and the cool thing about this legacy is that it has a baked experience – it learns and it has learned. Today we talk to Eric Normand, an experienced functional programmer, trainer, speaker, and consultant on all things functional programming. He started writing Lisp in 2000 and is now a Clojure expert, producing the most comprehensive suite of Clojure training material at purelyfunctional.tv. He also consults with companies to use functional programming to better serve business objectives.  We talk about problems in legacy code basis utilizing functional programming, the abstract nature of programs, the wisdom of Lisp, and more.  When you’re done listening to the episode, make sure to check out Eric’s Clojure training and his podcast, as well as connect with him on LinkedIn. Mentioned in this episode: Eric Normand on LinkedIn: linkedin.com/in/eric-normand-61a70366/ Eric Normand’s podcast: Lispcast.com Eric Normand’s websites: https://lispcast.com and https://purelyfunctional.tv  Eric Normand’s Clojure training: Purelyfunctional.tv Eric Normand’s book Grokking Simplicity: https://www.manning.com/books/grokking-simplicity?utm_source=lispcast&utm_medium=affiliate&utm_campaign=book_normand_grokking_8_20_19&a_aid=lispcast&a_bid=72596968Use discount code TSSIMPLICITY for 50% off.

Save 35% on any of Manning's titleshttps://www.manning.com/books/grokking-simplicityhttps://lispcast.com/Onion Architecturehttps://lispcast.com/podcastpurelyfunctional.tvHaskellClojureStratified DesignDomain Driven DesignCall Graph DiagramLeave us a reviewLast but not least, if you haven't rated or reviewed the show yet and you'd like to do us a huge favor, you can do so by clicking here!Show Notes ArchiveIf you're looking for a link we've mentioned in the past, head on over to the Does Not Compute site! We've even included a search tool for you to use to find episodes that touch on specific topics.Join Us On Twitch & Discord!Join dnccast each Thursday at 6 pm Pacific for the live recordings of each episode! We also have a community Discord server! It's an all-inclusive community that loves to talk tech, music, and games. Join us!

Eric Normand (long-time FP advocate and author of Grokking Simplicity) joins Jerod and KBall for a deep conversation about Functional Programming in JavaScript. Eric teaches us what FP is all about, details the functional side of JS, and reviews the good/bad/ugly of React. Oh, and join us in the #jsparty channel of our community slack where we’re giving away three FREE e-book copies of Eric’s new book!

Eric Normand (long-time FP advocate and author of Grokking Simplicity) joins Jerod and KBall for a deep conversation about Functional Programming in JavaScript. Eric teaches us what FP is all about, details the functional side of JS, and reviews the good/bad/ugly of React. Oh, and join us in the #jsparty channel of our community slack where we’re giving away three FREE e-book copies of Eric’s new book!

Check out Eric's book in MEAP - https://www.manning.com/books/grokking-simplicity

In this episode I talk with Eric Normand. We talk his podcast "Thoughts on Functional Programming"; his in progress book "Grokking Simplicity"; Actions, Calculations, and Data; trying to bury mutation and side-effects; Property-Based testing; and more.

In this episode Matt and Mike sit down with Eric Normand to discuss his new book Grokking Simplicity. Throughout the episode they discuss early access book releases, blogging & writing tips, and cover a tonne of ground on functional programming including how to get started and how to apply the paradigm to a problem. Show Notes: https://htmlallthethings.com/Podcast/5d9e35fe6a070d0011eb657f You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub  Reddit | Discord

Eric Normand talks about his new course on REPL driven development, and teaching Clojure. PurelyFunctional.tv REPL driven development in Clojure On the podcast I forgot to mention this excellent guide on using the REPL on clojure.org Lispcast Thoughts on Functional Programming apropos Clojure Youtube channel

Some functions have identities, which are values that tell you where to start calculating. In this episode, we look at what identities are, some examples of them, and how you can use them in your own code. Transcript Eric Normand: Is a function’s identity? By the end of this episode, you’ll know what an identity is and how to use them in your code. My name is Eric Normand. I help people thrive with functional programming. This is an important topic because many common operations, operations we use every day, have identities. You might not know that term, but you’ve definitely used them. It’s a fundamental idea from algebra, and it tells us where to start an operation. Basically, it’s the value you start with. When you’re counting, you’re going to start at zero. You don’t start at one. Before you start counting, you’re at zero, then the first thing you count down when it gets to one. Counting is just adding one each time. Zero is the identity value of addition. Multiplication also has an identity value, it’s one. If you multiply one times anything, you get that number. Same thing with adding zero. If you add zero to anything, you get the number back. That’s what an identity means. There’s other identities all around. If you’re adding letters to the end of a string, you’re going to start with an empty string. If you’re adding elements to an array, you’re going to start with an empty array. The same property holds, if you stake a string and you concatenate on an empty string to the end, you get the same string out. The same thing if you take an empty array and you concatenate them, you’re going to get the original array out. You can look at all sorts of operations and try to find if they have an identity. The ones that have an identity tend to be the more algebra feeling ones. I’m talking about hash map merge. If you merge two hash maps, basically copying the keys and values from one into the other, the identity is the empty map. Another property of the identity is it has to work in both sides. With addition, you can say, 10 plus 0 or 0 plus 10. The identity works in both positions. Same with hash map merge. If I have an empty hash map and I merge on a non-empty hash map, I get that non-empty hash map out. If I reverse the direction, and I start with a non-empty hash map and I merge in an empty hash map, I get the non-empty hash map out. Another way to look at identities is that they are the empty value. That’s the empty array, the empty hash map, zero empty string. Whatever kinds of data structures you’re looking at, there’s going to be some empty version of it. It’s important to remember that the identity is a property of the operation. It’s not a property of the data type. I said data types have their empty version of the data type, but the identity is a property of the function, the operation on it. That’s why it’s not part of the data type. That’s why with addition, you have a different identity from multiplication. It’s about the property. Additions identity is zero, and multiplications identity is one. It’s not a property of numbers or integers or anything like that. What’s cool about this is when you’re coding, making new functions, you can make an identity value. You could either start with an existing data structure that already has an identity and reuse that, or you can make a value that represents this place to start. When I say, “Start,” that’s what you would initialize your variables to start at. Just like you usually initialize a number to zero or you initialize an array to an empty array, you would initialize your new type that you’re making to this identity value. The reason you might want

All right, this is my attempt at writing a book. If you haven’t joined me before, my name is Eric Normand. I’m writing a book called “A Theory of Functional Programming.” The industry needs a good definition of functional programming. No one has provided that yet, and so I’m trying to provide it.

In this episode I talk with Eric Normand. We catch up with what he has been up to since last episode, talk re-frame in ClojureScript, his newsletter, Clojure SYNC, online community discussions, and more.

Eric Normand joined the show to talk about Functional Programming. We talked about FP vs OOP vs Imperative, why FP is popular again, the advantages and disadvantages of Functional Programming, and teaching Functional Programming concepts.

Eric Normand joined the show to talk about Functional Programming. We talked about FP vs OOP vs Imperative, why FP is popular again, the advantages and disadvantages of Functional Programming, and teaching Functional Programming concepts.

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

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

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

Eric Normand joins us to discuss functional programming, and how it relates to JavaScript programming and it's benefits to programming in general.

Eric Normand joins us to discuss functional programming, and how it relates to JavaScript programming and it's benefits to programming in general.

Eric Normand wants everyone to know that they, too, can get a job as a functional programmer. While functional programming might feel intimidating, in this show Eric shares with Scott a number of practical techniques and ways to think about functional programming that might just help you with a change of career.

Guest: Eric Normand @ericnormand Full show notes are at https://developeronfire.com/podcast/episode-236-eric-normand-real-world-examples

Eric imparts his smooth, smooth tones and worldly wisdom to the Defn podcast crew. See the full show notes over at https://defn.audio

Total Request LiveBroad CityHannibal BuressProject Homeless ConnectTenderloinFree vs Monad Transformers - Chris Pennerfreefreerrecursion-schemesoperationalFunctional Programming with Overloading and Higher-Order Polymorphism - Mark P. JonesreduxHaskell Sucks! - Paul BoneSubscriptionsCommandsBuilding composable abstractions - Eric Normand

Functional Geekery Episode 41 - Eric Normand

Ben and Eric Normand of LispCast and PurelyFunctional.tv talk about the pros and cons of Haskell and Clojure, empathize on some of the pain points of running an educational coding platform, and hypothesize on how the next great programming "killer demo" will present itself. Upcase: 50% Off Your First Month For Giant Robots Listeners! LispCast- With welcome message for Giant Robots listeners PurelyFunctional.tv Nil Punning Original LispCast Kickstarter Ruby on Rails 15 Minute Blog Demo Eric on Twitter

02:20 - Eric Normand Introduction Twitter GitHub Democracy Works LispCast Clojure Gazette PurelyFunctional.tv 03:31 -    Old vs Young Programmers Robert C. Martin: My Lawn “Uncle Bob” Martin Speaks at Yale SOM   05:38 - Teaching Fundamentals Kathy Sierra 11:02 - Teaching Backgrounds 12:13 - Why is so hard to be a good teacher? 15:54 - Teacher Feedback 19:46 - Asking Questions 25:56 - Community Education 28:20 - Order of Operation 29:36 - Recognizing Students Understanding of Fundamentals NPR Planet Money: When Women Stopped Coding 31:25 - Should there be prerequisites? 34:30 - How to Assess Where People Are 35:43 - Teaching the Teacher 39:10 - Bootcamps 45:52 - After Bootcamps Mentoring 52:11 - Skill vs Knowledge O'Reilly's Head First Series   More From Eric How to avoid "Makes sense if you already understand it." Making True/False Questions Easy Tap Into Your Social Brain Use Task Analysis to Break a Skill Into Steps Picks Inoreader (Avdi) Windows 10 (Avdi) Sandi Metz's Courses (Avdi) Avdi Grimm: I have a newsletter. You could subscribe, maybe. (Avdi) Ian Steadman: Sex isn’t chromosomes: the story of a century of misconceptions about X & Y (Coraline) Parable of the Sower by Octavia E. Butler (Coraline) Wunderlist (Jessica) The Partially Examined Life (Jessica) Together Tech (Chuck) Being Intentional (Chuck) Highrise (Chuck) Eventual Millionaire with Rory Vaden (Chuck) Ruby Rogues (Eric) Yoshiki Ohshima's Youtube Channel (Eric) Mindstorms: Children, Computers, And Powerful Ideas by Seymour A. Papert (Eric)

02:20 - Eric Normand Introduction Twitter GitHub Democracy Works LispCast Clojure Gazette PurelyFunctional.tv 03:31 -    Old vs Young Programmers Robert C. Martin: My Lawn “Uncle Bob” Martin Speaks at Yale SOM   05:38 - Teaching Fundamentals Kathy Sierra 11:02 - Teaching Backgrounds 12:13 - Why is so hard to be a good teacher? 15:54 - Teacher Feedback 19:46 - Asking Questions 25:56 - Community Education 28:20 - Order of Operation 29:36 - Recognizing Students Understanding of Fundamentals NPR Planet Money: When Women Stopped Coding 31:25 - Should there be prerequisites? 34:30 - How to Assess Where People Are 35:43 - Teaching the Teacher 39:10 - Bootcamps 45:52 - After Bootcamps Mentoring 52:11 - Skill vs Knowledge O'Reilly's Head First Series   More From Eric How to avoid "Makes sense if you already understand it." Making True/False Questions Easy Tap Into Your Social Brain Use Task Analysis to Break a Skill Into Steps Picks Inoreader (Avdi) Windows 10 (Avdi) Sandi Metz's Courses (Avdi) Avdi Grimm: I have a newsletter. You could subscribe, maybe. (Avdi) Ian Steadman: Sex isn’t chromosomes: the story of a century of misconceptions about X & Y (Coraline) Parable of the Sower by Octavia E. Butler (Coraline) Wunderlist (Jessica) The Partially Examined Life (Jessica) Together Tech (Chuck) Being Intentional (Chuck) Highrise (Chuck) Eventual Millionaire with Rory Vaden (Chuck) Ruby Rogues (Eric) Yoshiki Ohshima's Youtube Channel (Eric) Mindstorms: Children, Computers, And Powerful Ideas by Seymour A. Papert (Eric)

02:20 - Eric Normand Introduction Twitter GitHub Democracy Works LispCast Clojure Gazette PurelyFunctional.tv 03:31 -    Old vs Young Programmers Robert C. Martin: My Lawn “Uncle Bob” Martin Speaks at Yale SOM   05:38 - Teaching Fundamentals Kathy Sierra 11:02 - Teaching Backgrounds 12:13 - Why is so hard to be a good teacher? 15:54 - Teacher Feedback 19:46 - Asking Questions 25:56 - Community Education 28:20 - Order of Operation 29:36 - Recognizing Students Understanding of Fundamentals NPR Planet Money: When Women Stopped Coding 31:25 - Should there be prerequisites? 34:30 - How to Assess Where People Are 35:43 - Teaching the Teacher 39:10 - Bootcamps 45:52 - After Bootcamps Mentoring 52:11 - Skill vs Knowledge O'Reilly's Head First Series   More From Eric How to avoid "Makes sense if you already understand it." Making True/False Questions Easy Tap Into Your Social Brain Use Task Analysis to Break a Skill Into Steps Picks Inoreader (Avdi) Windows 10 (Avdi) Sandi Metz's Courses (Avdi) Avdi Grimm: I have a newsletter. You could subscribe, maybe. (Avdi) Ian Steadman: Sex isn’t chromosomes: the story of a century of misconceptions about X & Y (Coraline) Parable of the Sower by Octavia E. Butler (Coraline) Wunderlist (Jessica) The Partially Examined Life (Jessica) Together Tech (Chuck) Being Intentional (Chuck) Highrise (Chuck) Eventual Millionaire with Rory Vaden (Chuck) Ruby Rogues (Eric) Yoshiki Ohshima's Youtube Channel (Eric) Mindstorms: Children, Computers, And Powerful Ideas by Seymour A. Papert (Eric)

Functional Geekery Episode 18 - Eric Normand