331–340 of 663 posts
Earlier quoted context omitted.
I mean, I use `result` in a function named `generate` within a class `JSON < Generator`. Stuff like this is pretty common.
if you're already committing to generic names, what's wrong with a name like `processed_result`?
Earlier quoted context omitted.
I think the explanation is: When you mutate variables it implicitly creates an ordering dependency - later uses of the variable rely on previous mutations. However, this is an implicit dependency that isn't modeled by the language so reordering won't cause any errors. With a very basic concrete example: x = 7 x = x + 3 x = x / 2 Vs x = 7 x1 = x + 3 x2 = x1 / 2 Reordering the first will have no error, but you'll get t…
I agree that the explicit timeline you get with immutability is certainly helpful, but I also think its much easier to understand the total state of a program. When an imperative program runs you almost always have to reproduce a bug in order to understate the state that caused it, fairly often in Clojure you can actually deduct whats happening.
People jump ahead using AI to improve their reading comprehension of source code, when there are still basic practices of style, writing, & composition that for some reason are yet to be widespread throughout the industry despite already having a long standing tradition in practice, alongside pretty firm grounding in academics.
I had enormous fun optimizng C++ via self-modifying assembly to squeeze the utmost performance of some critical algorithms, and now this drive towards immutable everything feels like cutting my hands and legs off and forcing me to do subpar engineering.
clc
lda value
adc #1
sta value
lda value+1
adc #0
sta value+1
value .byte 0,0
x = 20
x = x + func(y)
x = x / func(z)
x = 20
x1 = x + func(y)
x2 = x1 / func(z)
Earlier quoted context omitted.
That's an aesthetically awkward and also bug-prone syntax: So just a difference of 1 single letter (that looks similar) to mean the completely opposite thing?? Nah you don't want that, and I don't either.
They're intuitively named. A value is a value. A variable is a variable.
Earlier quoted context omitted.
I think the explanation is: When you mutate variables it implicitly creates an ordering dependency - later uses of the variable rely on previous mutations. However, this is an implicit dependency that isn't modeled by the language so reordering won't cause any errors. With a very basic concrete example: x = 7 x = x + 3 x = x / 2 Vs x = 7 x1 = x + 3 x2 = x1 / 2 Reordering the first will have no error, but you'll get t…
I would be nicer if you gave x1 and x2 meaningful names
I try to keep deeper mutation to where it belongs, but I'll admit to shadowing variables pretty often. If I have a `result` and I need to post-process it. I'm generally much happier doing `result = result.process()` rather than having something like `preresult`. Works nicely in cases where you end up moving it into a condition, or commenting it out to test an assumption while developing. If there's an obvious name fo…
That doesn’t make logical sense. You already have a result. It shouldn't need processing to be a result.
> ... making almost every variable const at initialization is good practice. I wish it was the default, and mutable was a keyword. Rust mentioned!
In python its common to see code like this: df = pd.concat(df,other_df) df = df.select(...) ... My eyes hurts, when I see it. It makes me avoid python. I bet the reason for this mutable code is a missing simple pipes syntax. I love pipes. In R can do: df |> rbind(other_df) |> select(...) It feels much better.
df = pd.concat(df,other_df).select(...)One area that I like to have immutability is in function argument passing. In javascript (and many other languages), I find it weird that arguments in function act differently depending on if they are simple (strings, numbers) versus if they are complex (objects, arrays). I want everything that passes through a function to be a copy unless I put in a symbol or keyword that it suppose to be passed by reference. I made…
Earlier quoted context omitted.
Which one, Erlang, Lisp, or ML?
ML superfan here. I don’t mind lisp simplicity either. Erlang is too alien for me, but maybe once I was used to it.
If you have a course where one day you're supposed to do Haskell and another Erlang, and another LISP, and another Prolog, and there's only one exercise in each language, then you're obviously going to have to waste a lot of time on syntax, but that's never a situation you encounter while actually programming.