Genuine question. It has been a long time since I was a beginner programmer. Does all the cutesy "slow introduction" stuff appeal to novice programmers?
I am kind of impatient, so it seems a bit annoying to me.
If I were learning something technical that I am new to, say flying a plane, or biology I would prefer just to get stuck in. I would expect a pedagogical approach of course to easy me into it. But the cutesy stuff would feel like unnecessary slowing me down.
The writing style of "Joy of Elixir" is (I think) inspired by "Learn you some Erlang for great good" [1] and "Learn you a Haskell for great good" [2]. Personally, I like the cutesy style for getting started with a new tool/technology/language, just to know the basics.
The main selling point of Elixir is concurrency. Dave Thomas gives this great example in the second page of his book [3]:
defmodule Parallel do
def pmap(collection, func) do
collection
|> Enum.map(&(Task.async(fn -> func.(&1) end)))
|> Enum.map(&Task.await/1)
end
end
result = Parallel.pmap(1..1000, &(&1 \* &1))
Elixir developers can see the beauty of that snippet. However, for beginners, it can be overwhelming or intimidating. If you want to understand what is going on, you first need to learn about enumerables, map/filter/reduce, lambda functions, capture and pipe operators, spawned processes, tasks, etc. Yes, that is a great example for showing the power of Elixir but if you are a beginner chances are you are looking for something easier (e.g., Joy of Elixir).
Take Nix and NixOS [4] for example. That is an impressive technology and it has a (not cutesy) documentation. But, as a beginner, I feel lost. I rather prefer a cutesy getting-starter tutorial or book.
So, yes, I think there is a niche for developers that want to start with cutesy material. It is just a matter of taste.
The pattern in the example above is a fork/join model of concurrency. Task.async will spawn a new task and return a handle to it, the task will be scheduled and run at some point. Task.await takes that handle and waits for the associated task to complete before continuing and returns its result.
Sometimes you want something to happen, but you don’t want to block whatever you’re doing on that. Think things like sending a welcome email when someone signs up for a new account.
Not much of an Elixir developer but if I saw that snippet in code review I would flag it for readability.
Just because you can write something in 3 lines of code using lots of nesting and anonymous functions and variables doesn’t mean you should. This code would do better if it was longer, the variables had names, and the transforming functions broken out and named.
Disagree, you probably think it's unreadable because you don't know the language and/or concepts in this snippet.
But does that mean we shouldn't, for example, use destructuring in javascript because some devs might not know it.
At some point you have to assume a common ground of knowledge, and that common ground in Elixir is somewhat different than in algol derived OOP mainstream.
I never quite understand this mentality that many engineers have.
Instead of taking advantage of advanced language features and teach them to people, we more often than not create rules to avoid using them because "someone else won't understand it".
The important thing to realise is that the dot operator is used to access functions grouped into modules (or even invoke anonymous functions) rather than invoke methods on an object. Because Elixir being a functional language, the central operation is invoking functions on data and passing the results to other functions, rather than calling methods on objects.
From this understanding you can just grok from the code that this is a program that takes a list of numbers and squares them concurrently, in the process using your computer’s parallel processing hardware. And as this is a high level language you can create concurrent workloads with minimal implementation knowledge.
Even if you come from C family of languages where the & denotes something to do with address, you’ll realise the way Elixir uses it is not far away from that, but without the added tediousness of memory management. So elixir builds upon common conventions.
Some things like Enum may confuse a Java programmer. It’s Elixir speak for enumerable data rather than a collection of constants. And of course the pipe operator is different.
It’s certainly not easy to see this and write your own code and offer suggestions. But for a mildly experienced programmer who has already adopted the mindset that code is just a bunch of instructions presented in non-linear fashion, like in a legal document, this is an approachable intro to start asking questions from. First of all one should be willing to read a couple of pages from some book on what are anonymous functions and what is the syntax like for that etc.
The task is a bit more difficult for people who tend to look at code with a more inflexible viewpoint ie junior developers.
I'm not an Elixir beginner but all those ampersands means that either one writes that kind of code everyday or one won't understand what it does when coming back next month. Use names, not shortcuts.
You never know in advance who will work on code in a large project, how expert in that language and under which time pressure. I prefer to stick to a common ground between major languages that lets (say) someone that knows only JavaScript at least read the code and understand what it does. If it means that I have to write a few more lines or type more characters in variable and function names, I do it. I never appreciate where languages and developers want to do smart things. Boring and plain is much safer.
If you find yourself in such conditions that JS developers unable to google ‶elixir ampersand″ are the ones reviewing your code often enough for it to be a constraint while developing, your company has much deeper problems far up the command chain.
The ampersand syntax is extremely common in Elixir code - absolutely the kind of thing you'd write every day. If your Elixir developers find the ampersand stuff hard to read, you've hired the wrong Elixir developers.
I very much didn't like the ampersands the first couple of years looking at Elixir code. I think I've gotten used to it now. Looking at my own code, it's definitely more terse than it used to be. I do usually move such things into a separately named method, or a lambda that's assigned to an appropriate named variable.
I do agree with you though, when you get a screenful of ampersands that contains non-trivial business logic - it's not great.
As a guy who swears by Elixir, I completely support you.
I'd wish somebody to sell Elixir to me with transparent parallelism, demonstrating that it's literally 2-3 extra lines of code (compared to other languages where the extra code you have to write is significant). Pepper it with pattern matching and preemptive concurrency and I'm sold in 5 minutes.
I was already fascinated by Elixir, but this video drove the nail home. It's a great presentation and I don't think I have watched any conference talks (on YouTube) without taking a break except this one.
To me, I think Elixir's technical merits are well documented. If they appeal to you, you're welcome to dive into the deep end any time. No one needs to write you a tutorial for you to start using plug and cowboy - you can just do it.
On the other hand, if you're not quite there, or the technical qualities are not that impressive for your use case - the thing that may draw you into a language is how it encourages you to approach problems. How it lets you describe what you are expecting, and what to do when you are surprised. How to navigate data structures. For that latter category of person - I think the slow, cutesy approach makes a lot of sense. The goal is to fascinate and then seduce. No harm if you're not in the mood - but one day, a cutesy introduction may catch your eye. We all have different tastes.
I'm responding because when I found this a while ago and I felt similar to you, but mostly I felt it was weird coming from Ryan Bigg. Maybe I'm giving him too much credit for the awesomess that is the Rails guides, but I don't think I am...
What I did get from these Elixir guides (at least in my head) is that Ryan is always just being Ryan: a particularly great, proficient, and prolific writer of documentation. When he was writing about Rails, he was in his wheelhouse and he feckin' killed it and appealed to the exact right audience. When he wrote about Elixir, it was good but I felt he was out of his comfort zone and trying a new tone (the one you describe). This is purely my speculation but ya... again, just responding since this comment both made me a bit annoyed that you'd even bring this up (of course you have every right to), and struck a pretty hard chord with me.......and I'm tired and a little tipsy.
Anyway, massive respect to Ryan. I feel like he is one of the, if not The, unsung hero of Rails' popularity. The Rails guides are really special.
And we should be clear... it's not that Dave Thomas doesn't use humor in his courses or books to lighten what can be bit tedious. His humor tends not to be condescending or overbearing which is why I think it succeeds. Just good touches of lightness here and there.
Maybe they could provide a kind of base documentation to GPT-3 and then have it generate lots of tutorials in different styles - “cutesy”, “advanced”, “continued education”, etc. (I meant this to be funny but I’d bet someone has considered it even more seriously.)
I recently onboarded 2 JR developers who didn't know Elixir. I purchased pragmatic's video course for them, but they both liked the Joy of Elixir better.
In contrast, the seniors liked the pragmatic training better.
I am kind of impatient, so it seems a bit annoying to me.
If I were learning something technical that I am new to, say flying a plane, or biology I would prefer just to get stuck in. I would expect a pedagogical approach of course to easy me into it. But the cutesy stuff would feel like unnecessary slowing me down.