I don’t know what is wrong.
I’m curious if part of the motivation for this is in fact lowering the barrier of entry for developers coming from other languages, specifically Python, as part of a long term strategy of moving Elixir into ML and AI arenas. This would be consistent with recent focus on launching/growing Nx. That’s not an unreasonable motivation if so.
2 Likes
I want to voice my support for this whole heartedly and enthusiastically. This is great and should proceed.
If there are concerns about the similar to module constants then maybe ::local_accumulator = would suffice, though would require new AST I believe.
We could also make a special syntax for it similar to how clojure does atom’s though they aren’t a one to one match for this, they do mark the values as distinct from normal values.
I also do not think we should let FUD about education hold us back either. This change is relatively small in the grand scheme of things and will MOSTLY make things like Advent of Code and other learning problems easier to accomplish, not harder. We should assume people learning Elixir are capable enough to understand what a scope is.
14 Likes
That’s a great goal. And I’ve described here why this feature will be confusing for both python and elixir developers
1 Like
Since you’re supporting this feature, could you please explain what benefits it brings to the language? I mean, like readability of code, shorter solutions or lower learning curve?
1 Like
I agree with the reasoning provided, by José. The problem statement and proposed solution.
2 Likes
Yeah, I understand that 
I just couldn’t find the exact problem in the original post. Original post just compares Elixir’s and Python solutions and shows how we can have Elixir’s solution to look like Python’s one. And I am asking why do we want Elixir’s solution to look like Python’s one?
3 Likes
I have a few examples above where scope of the feature is extremely unclear and is confusing for me as a professional Elixir and Python developer.
I do not know what to say here. I think the annoyances it solves are greater than the annoyances you pointed out. And that José makes a compelling case for his proposed solution.
3 Likes
I think as far as the details of the proposal goes, this is likely the best one yet.
Personally I am on the fence about whether it’s actually a good idea though. I think it sort of trades messier code for a messier mental model. The code with @@ is certainly more clean in a sense, but it’s hard to beat the “cleanliness” of looking at the single line
And knowing that that encapsulates the entire preceding function. When functions are representable by their return value you can just |> debug that one line and watch the whole thing unfold. You can extract it and know that nothing has changed.
I am sure that with some compiler warnings and so forth the experience with @@ can be good. I have just come to really love the “return value has everything” idea because while there may be more code, you can focus on less of it at a time.
21 Likes
I agree with it 100%
4 Likes
I’ve read the original proposals and respective discussion and now this one.
I’m going to be as succinct as possible:
- This proposal going forward doesn’t shock me at all, don’t think it is necessary but I get what benefits it could bring, but still undecided if it is the right call, was more convinced on the past proposal when it was only confined to the compreenhension.
- Of course it can be abused, but so many other things can in the language (and now we have an anti-pattern docs and all)
- My main concern is readability. I know we are not focusing too much on syntax, but the double @ is not pretty, it’s not obvious and while I agree with the reasoning why it might make sense, don’t think it works. Module attributes use it, let’s keep it for that. If this goes forward we need a new symbol for the variable, but please, don’t use @@.
3 Likes
Personally I feel this will be abused a lot by new developers and will require more work for code guidelines and code review.
It reminds me when I was working with C++ and we hired a Java dev, he would use and abuse the new functionality just because that was what he was used to do with Java.
It would not surprise me if I would start seeing a buch of code like this:
@@my_value = false
if some_condition do
@@my_value = true
end
Just because the developer is used to that imperative way of writing it and don’t understand that the if statement is an expression.
If we want to go ahead with this proposal, I would suggest that we, at least, make the syntax have something that would de-incentivize the programmer to use it everywhere.
What came to my mind is the unsafe keyword from Rust, to write unsafe code, you need to create a unsafe code block and then, inside of it, you can write any code that can crash the program, since it has a strong word to it and also needs you to write some extra lines, the Rust developer will only use it when really is necessary.
Of course, before anyone says it, we are not talking about unsafe code here, but if we had something like this, it would incentivize the programmer to only use local accumulators when it is really needed.
For example, something like a mutable code block:
result =
mutable do
@@my_value = false
if some_condition do
@@my_value = true
end
...
end
IMO, something like this would make people think twice before writing the above code instead of a simple if/else expression.
9 Likes
I have repeatedly proven that you can write code to crash a program using nothing but safe Rust. 
1 Like
I’m neutral on the proposal; I see the problem it solves but I’m not sure this is the best take, or if it’s really a problem worth solving with more syntax. In any case I think it’s better than for let proposal though.
What I want to point out to people in this thread is that there is no mutation in this proposal.
It’s sugar over the boilerplate needed to rebind variables in a number of scenarios outlined in the OP. Just in the same way rebinding is sugar over erlang’s non-rebindable variables.
There is no new state going on. There is no mutation. No mutable state. Only the same variables, with a syntax that relaxes scoping rules. None of the code resulting from this proposal would be less safe than what we write today.
10 Likes
That’s clear, but even if behind the scenes there will be no mutation, you will still have to read the function as if it was mutated.
5 Likes
I am against the local accumulators proposal. If it’s added, I would also argue against the @@ syntax. Given all the other options, why pick one that’s backwards incompatible?
I’ll echo many others in this thread: I think the for statement should be expanded to meet this use case. I like the map_reduce form proposal.
My reasoning: I appreciate programming languages that have less ways to write code. I think that elixir is conservative with syntax sugar, which I really appreciate. It reduces my mental overhead when writing and reading code. I think a new syntax should have a compelling reason to be added, and in my opinion, saving a few lines of code for specific kinds of algorithms is not worth it. I definitely could be wrong here though - perhaps a better way to demonstrate the benefits would be to create a mock PR to a real-world elixir app that refactors it using this new proposed syntax?
4 Likes
Is this something that we actually want to gatekeep? I mean, we do have guides, guidelines and other tools precisely because of this. In fact, I think it’s great that we have something so distinct from a traditional variable declaration with the new syntax proposal that you won’t be using it by accident. We are talking about a “escape hatch” and not a hole we are digging for newbies to fall in by accident.
Exactly my thoughts! 
This is the same thing with if, unless and for… They look imperative but in Elixir they are just expressions… We could go around having a philosophical discussion about whether this is actually™ imperative or declarative, but I rather we focus about the practical problem the proposal is trying to solve 
.
I couldn’t disagree more 
! The @@ is beautifully explicit and because we already have @ for module attributes it makes even more sense to use it for this.
2 Likes
I have a question for you then: why do we need to teach newcomers to use Enum and semi-mutable variables in for and their bad practices, while we could only teach them Enum? And another question is: why do we want to have two completely different ways of writing and reading list traversal algorithms? This features makes language inconsistent, introducing special exception, leading to us keeping much more things in mind than we used to, thus making reasoning about the code harder.
I’ve already provided several examples above, which are made completely misleading by this new feature. And there will be more
5 Likes
These are the key points for me.
I also don’t think it’s fair to call out concerns over this as “gatekeeping” or “FUD.” I think a lot newcomers will just default to @@ which has the potential to rob them of really developing the proper mental model for why something like this doesn’t currently exist (and why something similar was at one point removed). Though it’s not like this is the end of the world or anything—I get that adoption is important.
12 Likes
