I see more people mixing up past and present tense randomly, as in this post. It’s confusing to read. Is the concept of tense starting to disappear entirely in US English, I wonder?
The post appears to consistenly use past tense for things that were true in the past at time of writing, and present tense for things that are true in the present or are always true. So the use of tense appears to be valid, though not following commonly prescribed style.
He's walking us through the process of designing the solution. Why wouldn't present tense work for this? We're discovering things with him as he takes us along for the journey.
Aha! advertises as far as New Zealand and I also never heard back when I applied. The excuse they supply (at least they do that much…) is that they receive too many applications to respond to everyone. But then why advertise all over the world? A scummy tactic when I think about it.
[I am the author of the post.] I know that keyword lists are different from maps, but I think their superficial similarity to maps isn’t ideal, and I don’t think that they’re the best possible solution (eg consider pattern matching on keyword lists which is order dependent, it’s not intuitive in the case of named args). They’re confusing to newcomers because of these things.
Both can happen at the same time, they can get confused and be learning.
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. :)
It is unfortunately much trickier because keyword lists are also optional. So what happens if opt2 is not given? We could raise but... since they are optional, we wouldn't want it to raise but rather have a default value.
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 quite complex argument handling (albeit we have slightly different feature sets).
I think there is a possible design for them that is not too bad, but it would need named parameters. I think the time o encountered that idea was part of a longer post about solving a different problem in Rust.
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.
I get that. But it's built on top of the Erlang VM, neither Erlang nor it's VM support these. All languages have their own leaky abstractions, and stuff that should in theory work, but doesn't.
Keyword lists were certainly confusing as a newcomer. But, FWIW, they existed well before maps. The AST is made up of only tuples and keyword lists on top of atoms and other literals. (Actually, if I'm not mistaken, keyword lists themselves are just lists with tuples of atom/value pairs. If you dig far enough down, it's incredible just how much of the language is built on top of a tiny number of primitives. Almost every bit of syntax you can think of is probably several layers of macros.)
Keyword lists are from Erlang's history really. Erlang didn't have maps or records for a long time and used keyword lists to perform a similar function.
Ah yes, sorry, you did say you understood them in the article but wasn't obvious you understood cases where one was better suited than the other.
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 :)
FWIW, no significant changes to the language are expected in the next couple of years.
Another side of this argument is that the rate of Elm ecosystem change is far more manageable than for JS.
A "stable JS framework" is an oxymoron, I'm afraid. My JS tools and NPM packages continuously change from under me, but somehow that's considered normal and not a problem.
I've just looked up a project I have with a mere 9 dependencies, and 7 of them have gone through multiple major version changes since the end of 2019. The other two have had minor releases. None are unchanged, even though all were already "stable" when I added them! Will the code still work if I update them? I don't know. Do I want to spend the time continuously tracking the changes to these dependencies, testing, making new releases of my project? Not really.
Perhaps I could continue deferring dependency updates, but that might make my job that much more painful when I have a legitimate reason to update (eg. for some new features I need) as half the package APIs will have changed beyond recognition by then.
I have so much less trouble with going back to Elm projects and picking up where I left off. That should be taken into consideration too.
One way to get static HTML/CSS from Elm is to execute the JS it produces and serialise the results from the DOM. That's what I do in my static site generator Elmstatic: https://korban.net/elm/elmstatic
reply