The “inconsistent” naming is actually a way to distinguish between guard and non-guard functions: is_map can be used in guards while empty? cannot.
You are correct. A keyword list is `[{atom, any}]`.
Then they learn how they work and stop being confused.
I struggle to see why we are so terribly afraid of people learning. Programming is not an innate instinct after all.
A programmer that doesn't understand linked lists yet is basically a newbie, but it's a topic you learn in one day and makes you a better programmer.
This should be encouraged, rather than listed as a con.
def foo(x, opt1: opt1, opt2: opt2)
Of course, we could then say "let's allow a default value to be given when pattern matching keyword lists". The problem is that no other pattern works like this and it would be inconsistent.
I think optional arguments are fundamentally incompatible with pattern matching (in Elixir). I understand why we would want that but, if we did have it, we would be adding tons of complexity and it would stand out as a sore thumb. I am also wary of going towards the same direction as Ruby and Python which have way too much complexity on its argument handling (albeit we have slightly different feature sets).
But i doubt it would be an urgent thing to change.
Tldr: add named arguments (optional). You can call with anon names, in which case it is positional as it is today. If you use named arguments to call, you have to use them in the order they have been declared, just like with positional, but you _can_ omit some. These get the default value.
There are ofc combinations that could be allowed, like anon until the first optional one, whatever.
It was part of this post, but don't it was a solution to a different problem kinda (and kinda not technically) https://faultlore.com/blah/defaults-affect-inference/
I said suggested you could pattern match on keyword lists with guards but that isn't true—I should not respond to things first thing in the morning.
It would be best if there was no confusion whatsoever, but given that it is most likely impossible (in any language), it is important to learn from where the confusion comes from, so we can continue improving the docs. It is a positive loop to have, as long as we listen. :)
Otherwise very nice article and sorry I only focused on the rebuttal points! I absolutely agree about grouped alias/import/require. I know those weren't always in the language and I always assumed it was a community request (but maybe not). I personally prefer to avoid `alias` and `import` whenever possible! There a handful of scenarios where I use them but I love how Elixir is big on locality. Any jumps I can avoid, even to the top of a file, is a win in my book.
Otherwise the focus on pragmatism is apt. Possibly my favourite thing about Erlang is that it is the only currently widely adopted general purpose language that was built to solve an actual business problem, and that problem so closely resembles web programming. All of the language decisions were made in support of their business goal as opposed to trying to come up with a beautiful, academically sound, language. Something about that really resonates with me so I kinda enjoy and embrace the "warts". Call it Stockholm Syndrome if you must :)
Jenny Shih gave a talk comparing Phoenix contexts with DDD bounded contexts.
Unless there’s some kind of behind-the-scenes magic that I’m unaware of, keyword list look up is O(n), not O(1).
The former requires turning an arbitrary piece of data, hashing it to an integer, and indexing a cell based off this value, dealing with potential collisions on the way. In C terms it's 50 lines long.
The latter is a simple iteration and string comparison. In C terms it's 5 lines long.
It is confusing if you've never programmed close to the metal and only know high level languages. Maps are good for data that you need to access in random order, linked lists/keyword lists for data that either you access in linear order, or it is so small the overhead of a map is too much.
If you have less than 10 elements, a linked list will always be faster than any hashmap on modern CPUs.
You mean implementation complexity right? Anyway, I was talking about semantics, not performance or implementation.
> If you have less than 10 elements, a linked list will always be faster than any hashmap on modern CPUs.
Citation needed. That personally sounds totally bonkers to me. Faster HOW? If the pointers of each node in the linked list are far apart in memory the L1/L2 cache misses will absolutely destroy the performance.
I think you're talking from a ton of assumptions that you haven't stated. If the list is that short, why isn't it a contiguous array in memory? That's going to be way smaller and way way faster in every way.
Some notes:
Keywords are not simply "another pragmatic solution that won over finding a more elegant way to support named arguments" and they are inherently different than maps and serve different purposes. Maps are unordered hashes, keyword lists are constant time, ordered list that can have duplicate keys. For example, in the language core, duplicate keys are used:
Ecto's query syntax makes use of both duplicate keys and ordering: Everyone complains about the f.() syntax. It's necessary as explained in the guides in the Anonymous Functions section [0]. There is also a nice little parallel to Erlang in that a regular function call looks like `f()` whereas an anonymous function call looks like `F()`.Contexts can be confusing, unfortunately. They're based off of bounded contexts from Domain Driven Design. I wouldn't say there is one right way to use Phoenix contexts, though reading up on DDD's bounded contexts really helps. I already had DDD experience before I learned Elixir, though, so it's easy for me to say and maybe more of a pain for others who don't want to do that.
Comprehensions can be much more concise in certain situations. You can certainly get away with avoiding them, but they can really come in handy sometimes. Not gonna give examples as this is getting too long. A short example would be Cartesian products.
Finally, I don't quite understand the gripe with `on_mount` or even `live_session` but that's been addressed in another comment.
[0] https://elixir-lang.org/getting-started/basic-types.html