Search
Ancient City Ruby 2019
(UN)Learning Elixir: A self-effacing guide to making fewer mistakes than I did when I started with Elixir
Edit
#elixir
#functional-programming
#ruby
#mentorship
#learning-strategies
#community
#erlang
Summarized using AI

(UN)Learning Elixir: A self-effacing guide to making fewer mistakes than I did when I started with Elixir

Randall Thomas • December 11, 2019 • Earth

In the talk titled "(UN)Learning Elixir" presented at the Ancient City Ruby 2019 conference by Randall Thomas, the speaker shares insights on transitioning from Ruby to Elixir, focusing on common pitfalls and offering practical advice to make the learning process more effective. Randall humorously admits to being self-deprecating, often emphasizing that he is not skilled in self-promotion. The main theme is about aiding those new to Elixir by reflecting on his own experiences and mistakes.

Key points discussed include:

- Audience Interaction: Randall engages the audience by asking about their background in programming languages, highlighting the prevalence of Ruby developers.

- Functional Programming Challenges: The discussion addresses the stereotypes surrounding functional programming, encouraging attendees to revisit misconceptions that exist and emphasizing the struggles many face when learning a functional language.
- Learning Approach: He introduces the Feynman Technique, which advocates teaching what you learn to reinforce understanding. This method is geared towards building a solid foundational knowledge in Elixir.

- Heuristics and Cognitive Biases: The speaker explains how cognitive biases can negatively impact programming practices, emphasizing the importance of recognizing these biases when learning new languages.

- Foundational Knowledge: Randall stresses the importance of mastering the basics in Elixir before tackling advanced frameworks like Phoenix. He suggests learning Erlang or another functional language to deepen one’s understanding of functional programming concepts.
- Programming Practices: Practical programming strategies in Elixir, such as maintaining small functions, utilizing the pipe operator, and defining type specifications, were discussed. Randall illustrated how embracing pattern matching could lead to cleaner and more reliable code.

- Community Engagement: He encourages learners to engage with the Elixir community, sharing experiences and insights to foster growth and understanding within functional programming.

In summary, Randall Thomas urges developers to take their time learning Elixir and encourages adopting a new mindset toward programming challenges. The emphasis is on being patient, understanding the language deeply, and utilizing resources effectively to become proficient in functional programming. He concludes with an open invitation for continued discussion and engagement with the Elixir community, underlining that the journey towards understanding Elixir and functional programming is worthwhile and rewarding.

(UN)Learning Elixir: A self-effacing guide to making fewer mistakes than I did when I started with Elixir
Randall Thomas • December 11, 2019 • Earth

Ancient City Ruby 2019

00:00:19.410 So, this was actually the original title of my talk. Is anybody here offended by adult language? Because unfortunately, I swear a lot. Hopefully, this isn’t a major violation of the terms of the conference. But there’s definitely going to be some sailor speech going on here.
00:00:37.020 Let’s see, how many people here have actually heard of Elixir? Holy—okay! That's not what I was expecting.
00:00:43.230 Like, everybody here has heard of Elixir. How many people here are Ruby developers? There's very much an overlap. Any JavaScript people? Okay, COBOL—that's a trick question. Okay, Paul, nobody’s asking you. That’s alright. This is a little bit different.
00:01:07.860 We wanted to actually talk about how many people here had their first programming language as Ruby or React. Does anybody here have a functional language as their first language? Like Lisp or Scheme? Yeah, Racket or something like that? Scala? Wow!
00:01:23.790 Now, how many people moved on to something else after Ruby? Python, C, C++—anyone? Okay. And for the final question, does anybody know who this is? You can actually answer this; this is interactive. The whole point is to be engaged, so scream it out.
00:01:36.840 ChatGPT, right? This guy basically invented most of modern physics. It was super important. He had a technique by which he would teach things, and it goes like this: first, you study it; second, you immediately teach it to somebody else. Now, think about this—let’s say we’re going to do open-heart surgery. I just learned it yesterday, and now I’m going to immediately teach it to you. Does that sound like a great idea?
00:02:18.510 So, you go back and identify what you don’t know, and then you fill in the gaps. There’s a whole sort of logic to this. If you think about it, has anybody here ever asked a knowledgeable friend to teach them the basics? It sucks, right? The whole point of the Feynman technique is that as a beginner, or as an intermediate beginner, you’re actually the best person to onboard new beginners.
00:02:41.880 I’ve been doing Elixir development pretty much full-time for just over a year, which is just enough that I think I know where I’m going. This means I know just enough to be dangerous, right? So this is exactly the time where I should be helping anybody else who wants to do Elixir development by sharing how to do it better than I did.
00:03:05.410 Where we’re going today: I’m going to tell you where I wasted a lot of time. How many people here have actually tried out Elixir? How many people write Elixir? Oh wow, about a third of the room actually writes Elixir daily. How many people write Elixir but aren’t at Heroku? Okay, that’s alright.
00:03:29.920 We’re going to talk about how functional languages kind of get a bad rap. We’re also going to discuss what problems we are really trying to solve when we adopt a functional language. I’m sure everybody has that snooty friend who tells you, 'Why aren’t you writing this in Lisp?' or 'You could do this in Haskell.' The whole 'Haskell moment' that everybody seems to have with functional programming and the 'Why didn’t you tell me this?' moment.
00:03:50.709 We’re going to give you some tools to make sure you don’t panic. And I will introduce things which I like to call 'How I Learned to Love the Lambdas.' How many people here know somebody who writes—or is really good at—functional programming? Like the guy who writes your Emacs code or writes Lisp macros for fun? Okay, how about this: how many people have ever used something written by T. Pope in Vim script?
00:04:20.859 All of you. If you use Vim, you've used his code. So, T. Pope has a heritage. He worked for Thunderbolt for a while and also at Hashrocket. I’ll tell you—brilliant dude—but I could not read or follow any of his code because the style in which it was written was just too advanced for me.
00:04:39.880 This is how I always imagined a functional programmer writing code—like the high-speed spy stuff of the programming world. So, I got into it to learn some basics. After learning a little bit about category theory, I tried to write my first program.
00:05:02.170 I asked some of my friends for a little help, and then I ended up where almost everybody trying to learn a functional programming language ends up. So when I thought of myself as more of a Daniel Craig, you know, a postmodern James Bond guy, this was closer to who I ended up being. The question is: why is that?
00:05:19.630 How many people here have actually tried to learn Lisp, Scheme, Racket, Haskell, or something like that and then just gave up? Okay, how many people just gave up without even bothering to try? That's most of us, right? How many people here use Vim? Almost everybody. How many people looked at Emacs and then, when they said you could configure it using Lisp, decided to use Vim instead? Don’t lie!
00:05:51.909 So, what gives? Programmers are productivity-focused; you guys are lazy—straight up! I've never seen people who will spend more time writing a bash script to do something they'll only do once with the idea that if I ever have to do it again, six hours on a bash script will pay off. More importantly, there's a lot of history we deal with in computer science and programming languages. Most were either side projects or got popular—Visual Basic is still one of the most popular languages on the planet. Seriously, don't tell me it was well thought out and designed.
00:06:21.219 You guys might not have experienced Visual Basic, but you have seen Excel macros. So, the thing is, we actually have this notion that the languages we use were designed with perfect knowledge, when in reality, it’s often just a cruel twist of fate that has caused them to be popular.
00:06:57.350 Let’s do a little experiment first. Before we do this, let’s talk for a second. One thing we have to do when learning a new language is build a new mental model for that language. Here’s an example for you. Suppose you have randomly sampled a word of three or more letters from an English text—what’s more likely: A) the word starts with an R like 'rope,' or B) the third letter is R. How many people say A? How many people say B? How many people don't know, and think it’s a trick question?
00:07:25.289 The answer is B! This example matters because it illustrates heuristics. Heuristics are how we get our brains to skip some heavy lifting while making decisions. When you write in a programming language, you’re actually using a bunch of shortcuts, hacks, and heuristics. This is one of the reasons we have things like idiomatic JavaScript and design patterns.
00:08:01.790 Not all heuristics are great. The reason many aren’t great is that they’re based on cognitive biases. Does anybody here ever heard of cognitive bias? Things like the availability heuristic—that one's a classic. The point is that when it comes to programming languages, those heuristics can lead to a lot of misunderstandings.
00:08:43.880 The way you think about your work is influenced by the tools and languages you pick. If you’ve been writing software for over ten years, your thinking about problem-solving becomes embedded in certain assumptions. This brings us to how to build a new mental model, which is really hard because it involves forgetting what you already know.
00:09:02.050 I hate feeling like a newbie; I love being able to dive into a codebase where I know the language well and be productive. I really dislike the feeling I get with functional programming when I'm literally looking at the name of a method every three minutes trying to figure out what the arrows mean.
00:09:32.000 So, we have to forget what we know. The second thing is: garbage in, garbage out. There’s a lot of bad FP advice out there. People tell you to rewrite your website in Brainfuck or something equally nonsensical. You need to be careful about what you take in and whether it will work for you because we cannot assume everyone learns in the same way.
00:10:02.290 How many people here have an academic background in either computer science, programming, or engineering? About a third. How many people have no background whatsoever and came to this from something completely non-technical? One of the issues you’re going to run into is that almost all functional programming texts seem pretty much written by one PhD as a love letter to another PhD.
00:10:38.040 You have to learn how you learn and skip over stuff that doesn’t work for you. It’s okay if you don’t want to read a book on category theory—you can still learn Haskell! Getting back to the basics is crucial. Programmers often seem to jump off buildings before they can walk. We need to master the basics first because, in functional programming, unlike other procedural languages, you can’t just get by with half knowledge.
00:11:00.880 So, here's my suggestion for you: if you ever want to do functional programming, take your time. Learning something new is a function of time. Has anybody here tried to learn another language? There's a concept in language learning called spaced repetition systems.
00:11:28.000 An SRS is software that gives you a flash card on increasing spans of time because remembering something is a function of how often you forget it, not how often you remember it. The more you forget something, the more effective that spaced repetition becomes, enabling the retention of new information.
00:12:07.800 So, as you're building new structures in your brain to grasp functional programming, it’s going to take time. You’re trying to train your brain to have a different set of heuristics, which can be challenging. This is similar to using Vim—if you ever used an editor without Vim bindings, you likely wanted to throw that editor out the window!
00:12:28.800 So, how do we become the elite in functional programming? The first part is understanding affordances and abstractions in programming languages. Affordances indicate what should be done with something, while abstractions are critical for building software. Every programming language is a collection of abstractions, some better than others.
00:12:52.790 In functional programming, recognizing those affordances and abstractions becomes essential. The more powerful the abstraction, the greater the potential for errors if you don't understand it. For instance, when working with an ORM like ActiveRecord, developers often overlook the underlying complexities, leading to problems like N+1 queries.
00:13:17.360 If you don’t grasp the abstractions and affordances of your language, it doesn't mean you should write code—just because you can doesn’t mean you should do it. Now, after all this, how do you learn Elixir effectively? Since I see everyone here is familiar with Elixir, I’ll skip the praises and get straight to the best practices.
00:13:47.290 First off, when learning Elixir, don’t dive into Phoenix right away. I know this may seem counterintuitive, but it’s crucial to understand the language first before you jump into using its frameworks. Learning Elixir first ensures you grasp the foundational elements before tackling frameworks like Phoenix, which can be complex.
00:14:05.300 Next, consider learning Erlang. While it might sound surprising, picking up Erlang will definitely make you a much better Elixir developer. There are many valuable insights and patterns found in the Erlang ecosystem that benefit your understanding of Elixir.
00:14:53.130 Moreover, learning another functional language, such as Racket or Closure, can also deepen your understanding of Elixir. A language like Haskell will allow you to notice patterns in the functional programming paradigm and develop a better grasp of these concepts.
00:15:23.200 As you learn, think differently about your programming challenges. Approach your code and problems with a fresh perspective. Learning Elixir means adapting your thought process to problem-solving in functional programming, moving away from traditional procedural paradigms.
00:15:47.020 Understanding synapses in Elixir is crucial; they can seem similar to Ruby, but functions take center stage. You'll need to refine your approach to employing pattern matching and grasping how dependency injection works in this context.
00:16:05.590 In Elixir, functions are first-class citizens. Keep your functions small and manageable to boost your productivity. Just remember—the smaller the function, the easier it will be for you to debug and reason about.
00:16:25.210 Also, use the pipe operator wisely. It allows for creating semantically meaningful code that flows logically from left to right, making it easier to understand the progression of transformations on your data.
00:16:45.590 Lastly, make sure to define type specs. While Elixir is a dynamically typed language, utilize type specs and the tool Dialyzer for static type analysis. This practice enhances code clarity and maintainability by specifying what functions expect.
00:17:10.800 Pattern matching is fundamental in Elixir’s function dispatching system. It allows you to eliminate many classes of runtime errors by ensuring that only valid data is processed.
00:18:06.890 As programmers, we do a lot of boilerplate checking, but using guards and pattern matching allows you to write cleaner and more reliable code. By being explicit about a function’s input requirements, you eliminate errors and enforce correct data types.
00:19:07.220 In summary, learning Elixir and functional programming comes down to practicing, building new patterns, and utilizing existing abstractions effectively. Don’t shy away from leveraging resources and recommended tools in your practice to help make the transition smoother.
00:20:07.420 Make sure to engage with the community of Elixir developers. Learning from their experiences can help you avoid pitfalls and develop a better comprehension of functional language programming.
00:20:25.900 Overall, embrace the curiosity of understanding programming languages and share your findings to help foster a richer programming community. Future code comprehension and functional programming insight will take practice, but it's definitely worth the investment.
00:21:00.000 Thank you all for your attention and participation! If you have any questions or want to keep discussing Elixir, feel free to reach out. I look forward to engaging with you further.
Randall Thomas
@DevDevvy
Explore all talks recorded at Ancient City Ruby 2019
+5