361–370 of 663 posts
Earlier quoted context omitted.
1st) you use ++def in a loop, don't be weird; 2nd) if 'abc' is to be used in the loop body, define in the loop, e.g. for (int def = 7, abc =3; ...); 3rd) this is an IntelliJ bug - both 'def' and 'abc' in the sample are always defined.
the only thing that is weird is your lack of understanding temporary variables
This shouldn't be a hard and fast rule for everything. Be treated as guidelines and allow the programmer some wiggle room to reuse variables in situations that make sense.
Anyway the outcome of trying to avoid mutation means instead of simply setting player.score you get something like player = new Player(oldPlayerState, updates). This is of course slow as hell. You're recreating the entire player object to update a single variable. While it does technically only mutate a single object rather than everything individually it's not really beneficial in such a case.
Unless you have an object with a lot of internal rules across each variable (the can't be 'A' if 'B' example above) it's probably wrong to push the mutation up the stack like that. The simple fact is a complex computer program will need to mutate something at some point (it's literally not a turing machine if it can't) so when avoiding mutation you're really just pushing the mutation into a higher level data object. "Avoid mutations of data that has dependencies" is probably the correct rule to apply. Dependencies need to be bundled and this is why it makes sense not to allow 'A' in the above example to be mutated individually but instead force the programmer to update A and B together.
After a 2 year Clojure stint I find it very hard to explain the clarity that comes with immutability for programmers used to trigger effects with a mutation. I think it may be one of those things you have to see in order to understand.
I think the advantage is often oversold and people often miss how things actually exist on a continuum and just plainly opposing mutable and immutable is sidestepping a lot of complexity. For exemple, it's endlessly amusing to me to see all the efforts the Haskell community does to basically reinvent mutability in a way which is somehow palatable to their type system. Sometimes they even fail to even realise that it'…
Because that’s not what they’re doing. They’re isolating state in a systemic, predictable way.
Don't be silly and assume if I assign it multiple times in an if condition it's mutable - it's constructing the object as we speak, so it's still const!!!
C# gets this right among many other things (readonly vs const, init properties, records to allow immutability by default).
And the funny thing is the X thread has lots of genuine comments like 'yeah, just wrap a lambda to ensure const correctness' like that's the okay option here? The language is bad to a point it forces good sane people into seeing weird "clever" patterns all the time in some sort of an highest ELO rating for the cleverest evilest C++ "solution".
I was hoping Carbon was the hail mary for saving C++ from itself. But alas, looks like it might be googlified and reorged to oblivion?
Having said that, I still like C++ as a "constrained C++" language (avoid clever stuff) as it's still pretty good and close to metal.
Earlier quoted context omitted.
I'm interested what are those new keywords and features that are of dubious benefit?
There is a huge amount of syntactic sugar that has been added over the years that doesn't do whole lot IMO. It is often imported from other languages (usually JavaScript and/or Python). e.g. Just a very simple example to illustrate the point if (customer != null) { customer.Order = GetCurrentOrder(); } vs if (customer is not null) { customer.Order = GetCurrentOrder(); } Is there really any benefit in adding "is/is no…
Earlier quoted context omitted.
In the cases we're interested in here the variable does vary, what it doesn't do is mutate. Suppose I have a function which sums up all the prices of products in a cart, the total so far will frequently mutate, that's fine. In Rust we need to mark this variable "mut" because it will be mutated as each product's price is added. After calculating this total, we also add $10 shipping charge. That's a constant, we're (fo…
> In the cases we're interested in here the variable does vary, what it doesn't do is mutate. Those are synonyms, and this amounts to a retcon. The computer science term "variable" comes directly from standard mathematical function notation, where a variable reflects a quantity being related by the function to other variables. It absolutely is expected to "change", if not across "time" than across the domain of the f…
fn sin(x: f64) -> f64 {
let x2 = x / PI;
...
Anyway this is kind of pointless arguing. We use the word "variable". It's fine.
classList = ['highlighted', 'primary']
if discount:
classList.append('on-sale')
classList = ' '.join(classList)
Earlier quoted context omitted.
whats the difference between immutable and constant, which has been in use far longer? why are you calling it mutable?
"Constant" implies a larger context. As in - it's not very "constant" if you keep re-making it in your loop, right? Whereas "immutable" throws away that extra context and means "whatever variable you have, for however long you have it, it's unchangeable."
you cant change a constant though
I find that keeping functions short also helps a ton with that.
No, shorter than that. Short enough that the only meaningful place to "move a block of code" is into another function. Often, by itself.
In JavaScript, I really like const and have adopted this approach. There are some annoying situations where it doesn't work though, to do with scoping. Particularly: - if (x) { const y = true } else { const y = false } // y doesn't exist after the block - try { const x = foo } catch (e) { } // x doesn't exist after the try block
Why not do: const y = x ? true : false;
const y = (bool)x;
const bool y = x;