So, I’ve read the ElixirSchool lessons, Programming Elixir 1.6 and Elixir in Action’s Elixir basics part. Meaning that I’m about to start learning OTP.
But the thing is that I just don’t feel confident with Elixir. I don’t know why, but it kind of feels like I don’t know anything at all. And the worst part is that I can’t understand most of the code I see.
Just reading the same things in books or websites like ElixirSchool just doesn’t help.
Should I read the same basics for the millionth time, or start building little projects/learn OTP? Some people said that I will eventually get better by building things, but I just don’t know if that’s true, if you know what I mean.
The Beam Radio folks talked about this exact situation at the end of the most recent episode: Grok It. The whole episode is worth a listen, but there is a moment toward the end where @lawik says something like “at some point you have to stop reading and start building.”
Start building. Write it, learn from it, rewrite it, ad infinitum.
When I started learning my first functional programming language F# I felt the same at one point. Then later everything started making sense. Nowadays I prefer creating pure functions in other languages when possible. I feel that learning functional programming language made me a better programmer.
Most hardest thing for me to learn was that in fully immutable languages like Elixir you can’t mutate anything and you don’t have global variables. in Elixir you can only store data to other prosesses and data stores. So sometimes you need to flow data through function(s) that “change” it by returning new copy of data with changes applied. Good example I think is how Plug.Conn is used.
Me too. Getting used to not mutating things was very hard, but now I get really angry when other programming languages have functions that canutate their arguments, I feel like I can’t trust other people’s code, ever, and it is much higher cognitive burden, overall.
It’s true. Literally the only way to improve any skill is by practicing it. Reading is a mere supplement.
Yep. Again, it’s just how learning works. You do something more-or-less poorly, then improve.
The source of feedback needed for the improvement can be tricky if you’re learning on your own. You can get some help on slack and forums. But you can also generate your own feedback by comparing your own code with published things.
It sounds to me like you might have read too ahead of your hands-on experience. I think we all this at some point. One thing you could try is going back to something you’ve read, skimming a chapter or section which contains a decent chunk of code, then putting the book down and writing that code yourself. You can then go back to the original to compare or solve problems if you’re getting nowhere.
The problems in Advent of Code aren’t specific to Elixir, but they’re good practice for general problem solving and for learning the Enum and Stream APIs.
As the animator Chuck Jones supposedly said (the sourcing is sketchy):
Every artist has thousands of bad drawings in them and the only way to get rid of them is to draw them out
Like others, I’m a big proponent of doing. And what you’re going through is normal. It’s important to have a plan though.
Books and courses are good to have an outline of what is available. But doing/building/executing something is where the actual learning happens. Otherwise, you might just forget what you learnt in a few weeks. Why spend the time learning it in the first place if you don’t have a plan to retain the knowledge?
Be prepared to be bad and don’t worry about it. It’s part of the process. I felt embarrassed at how long it took me to grok Enum.reduce. When you’re doing something you never done before, it’s ok to feel those feelings, just keep moving forward.
Years of practice later, you may think your earlier decisions and work was awful. When I was in my 30’s, I thought I was an idiot in my 20’s. And now I’m in my 40’s, I think I was an idiot in my 30’s. I think the stuff I built last year isn’t as good as the stuff I built this year. Learning has that effect.
Pick a project you actually want to do. If you aren’t truly interested in it, what’s the point? Mastery of the tools will come naturally on the way.
Thank you everyone for the answers. I practised for a few hours today, and I already feel a bit more confident! Still have to practice a lot, but better than nothing.
I’d recommend a different approach to the books and tutorials mentioned above.
Elixir reads really well when it clicks, and because everything is functional and just data transformations it’s possible to start at one end of a program and follow the thread all the way through. Phoenix is regularly credited as being one big function.
Also, there’s a wonderful library of open source tools for Elixir and the vast majority are very well written. Steer clear of anything that implements macros as that really won’t help as they throw most people!
Spend time just reading and trying to understand and adsorb. Don’t get caught up in understanding everything well enough you could write it, just enough you could explain the broad strokes to another developer.
Find public datasets and make small projects that process their data, e.g. a list of orders and customers, you can do various reports like highest grossing goods, goods with most amount of sales, customers that buy the most goods etc.
A lot of these data aggregating tasks involve parallelism where Elixir shines greatly. It could be a very good exercise in Elixir’s strong sides. I mean OK, part of the things can be done with pure SQL but that’s not the point here.
I’m by no means an Elixir guru but I’ve been working in it regularly for about six months now, coming from full time Ruby work. Here’s what I’ve noted.
There’s definitely a gap. It takes some time to shed certain OOP paradigms and habits (presuming you have them) and you won’t immediately most likely. It’s fine. One of the the things I have learned about functional programming is that refactoring tends to be a lot easier. You don’t pay for mistakes in the same way you do when creating class hierarchies and such. (I’m starting to believe inheritance in general is a bug rather than a feature, lol.) In a sense what I have enjoyed a lot about Elixir (and probably more functional programming than Elixir specifically) is I don’t really need to be afraid of “bad” code because the refactoring is so much easier.
Chris McCord said something in one of the early talks I watched like, “It’s just modules and functions and… that’s all it is.” He was referring to waiting for the magic moment when he learned the big secret. Also, if you listen to him talk about how LiveView evolved and his work followed by José’s refactors… just make stuff that works. Refine after that. If you focus on writing “perfect” Elixir or “doing the right thing” too much early on, it’s a quagmire.
Lemme echo something: stay away from macros to start. If you’re working with something like Ecto just accept it and don’t try too hard to understand the AST or macros. It’s not that it’s black magic or anything, but you’ve got to wrap your head around immutable data structures and functional programming first. (Ecto made a ton more sense when actually learned how to write macros. It was like, “Ah-ha! There’s the magic.” But I was able to make good use of it without getting too caught up in those details initially.)
Get to know ExUnit. The best way for me was actually not so much guides or books but just looking at tests in other libraries. Testing felt really tedious in Elixir at first because I simply didn’t know ExUnit well at all and setting up dependencies in more complex projects was a pain at first because I didn’t know what tools were available.
Depending on your experience in other languages, another warning: once you really get pattern matching, it’s a tool that’s sorely missed when returning to language without it.
As people have mentioned, functional programming definitely requires some brain re-wiring. I actually went the other way, learning FP first and later having to understand OO. It was rough and I understand what you’re up against.
Reading code with a view to understanding “a program” - or more likely a single path through a larger one - gives you a 30,000ft view of the problem and how it’s being solved. You get a sense of how to solve the problem and what the idiomatic way of thinking in the language is.
Syntax is relatively simple to pick up once you already understand the “how” and the “why”.
EDIT: to illustrate, I’ve done enough work with GenServers that they are now the natural way I solve a problem, regardless of the language. I understand what a GenServer solution would look like and translate that mental model to whatever language I’m using. It’s my native tongue so to speak.
Despite that I would probably have to look up the boilerplate required to write a GenServer because it’s been a month or two since I last wrote one.
Syntax is the easy bit and only a google search away once you understand the solution. Working out the solution could be hours worth of googling by comparison.
