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.