521–530 of 663 posts
Earlier quoted context omitted.
What would those names be in this example?
In a real application meaningful names are nearly always possible, eg: const pi = 3.1415926 const 2pi = 2 * pi const circumference = 2pi * radius
Earlier quoted context omitted.
That’s the point, you’re just haggling about scopes now. All the way from being new per program invocation to new per loop. Immutability doesn’t have this connotation.
How? I think the same argument applies: If it's changing from loop to loop, seems mutable to me.
for (0..5) |i| {
i = i + 1;
std.debug.print("foo {}\n", .{i});
}
To potentially make it clearer that this is not mutation of a constant between iterations, technically &i could change between iterations, and the program would still be correct. This is not true with a c-style for loop using explicit mutation.
Earlier quoted context omitted.
The concept is actually pretty simple: instead of changing existing values, you create new values. The classic example is a list or array. You don't add a value to an existing list. You create a new list which consists of the old list plus the new value. [1] This is a subtle but important difference. It means any part of your program with a reference to the original list will not have it change unexpectedly. This eli…
> It means any part of your program with a reference to the original list will not have it change unexpectedly. I don't get why that would be useful. The old array of floats is incorrect. Nothing should be using it. That's the bit I don't really understand. If I have a list and I do something to it that gives me another updated list, why would I ever want anything to have the old incorrect list?
You pass in an array of 10 values.
While the function is executing, some other thread adds two more values to the array.
How many values should the result of the function call have? 10 or 12? How do you guarantee that is the case?
Earlier quoted context omitted.
Made a similar experience with Scheme. I could tell people whatever I wanted, they wouldn't really realize how much cleaner and easier to test things could be, if we just used functions instead of mutating things around. And since I was the only one who had done projects in an FP language, and they only used non-FP languages like Java, Python, JavaScript and TypeScript before, they would continue to write things base…
JS is much more of a functional language than it was given credit for a long time. It had first-class functions and closures from day one if I'm not mistaken.
Earlier quoted context omitted.
If you need new values you just make new things. If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. The nice thing here is you can pass around pointers to fooA and never worry that anything is going to change it underneath you. You don't need to protect private variables because your internal workings cannot be mutated. Other code can copy it but not disrupt it.
> If you want to do an operation on fooA, you don't mutate fooA. You call fooB = MyFunc(fooA) and use fooB. This is the bit I don't get. Why would I do that? I will never want a fooA and a fooB. I can't see any circumstances where having a correct fooB and an incorrect fooA kicking around would be useful.
Earlier quoted context omitted.
> However, don't you still need to understand the entire program as ultimately that's what you are trying to build. Of course not, that's impossible. Modern programs are way to large to keep in your head and reason about. So you need to be able to isolate certain parts of the program and just reason about those pieces while you debug or modify the code. Once you identify the part of the program that needs to change,…
> Once you identify the part of the program that needs to change, And how do you do that without understanding how the program works at a high level? I understand the value of clean interfaces and encapsulation - that's not unique to functional approaches - I'm just wondering in the world of pure immutability where the application state goes. What happens if the change you need to make is at a level higher than a sin…
The point is to determine the points in your program where mutation happens, and the rest is immutable data and pure functions.
In the case of interacting services, for example, mutation should happen in some kind of persistent store like a database. Think of POST and PUT vs GET calls. Then a higher level service can orchestrate the component services.
Other times you can go a long way with piping the output of one function or process into another.
In a GUI application, the contents of text fields and other controls can go through a function and the output used to update another text field.
The point is to think carefully about where to place mutability into your architecture and not arbitrarily scatter it everywhere.
Earlier quoted context omitted.
Doom which was countless fun for people up to this day who make mods? (E.g. the great Myhouse.wad that was perhaps FPS of the year... 2023) Quake, which was a good game, but arguably a better engine that lead to things like Half-Life 1? Other games? Shared the code to Doom and Quake? I guess you dont understand how big of a game Doom was. The first episode holds suprisngly well up to this day, even after hundreds of…
But he didn't design the Doom game. He designed its graphics engine.
Earlier quoted context omitted.
His engines are open source, and graphics are far from the only interesting thing about them. If you don't know what he's done that's on you; it's no secret.
So again, what has he done successfully besides C++ graphics?
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.