I’ve used it in the past when having flash memory blocks that could change but you need the compiler to put them into flash memory and not RAM. It’s mainly to get the compiler to stop assuming that it can optimize using the default value.
Define your terms before relying on platitudes. Mutability isn’t cleaner if we want composition, particularly in the face of concurrency. Being idiomatic isn’t good or bad, but patterned; not all patterns are universally desirable. The only one which stands up to scrutiny is efficiency, which leads to the cult of performance-at-all-costs if one is not thoughtful.
I agree somewhat, but I’d also say any codebase needs some level of “dogmatic” standard (ideally enforced via tooling). Otherwise you still end up with bad, messy code (I’d even say messier, as you don’t even get consistency)
I’d agree with the first half, but not the second. Sometimes mutability allows for more concise code, although in most cases it’s better to not mutate at all
I think the general idea would be to take the original const, and create a new const with the new location applied. Destroy the original when it’s no longer needed or scoped. State maintained through parameters passed to the move function e.g. move(original const, new location) -> new const object instead of stateful members in the object like move(mutable, new location) -> updated mutable.
Random example, imagine a variable that holds the time of the last time the user moved the mouse. Or in a game holding the current selected target of the player. Or the players gold amount. Or its level. Or health. Or current position.
Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can’t have a race condition where two things update the same data when they never update it that way at all.
Rather than me coming up with an elaborate and contrived example, I suggest giving a language like Elixir a try. It tends to force you into thinking in terms of immutability. Bit of a learning curve if you’re not used to it, but it just takes practice.
I’d say this example doesn’t fully show off what immutable data can do–it tends to help as things scale up to much larger code–but here’s how I might do it in JS.
<span style="color:#323232;"><btn mobile big>
</span><span style="color:#323232;"><btn desktop small solid my-class>
</span><span style="color:#323232;"><btn medium>
</span>
Notice that JavaScript has a bit of the immutability idea built in here. The Array.flat() returns a new array with flattened elements. That means we can chain the call to Array.join( " " ). The classes array is never modified, and we could keep using it as it was. Unfortunately, JavaScript doesn’t always do that; push() and pop() modify the array in place.
This particular example would show off its power a little more if there wasn’t that initial btn class always there. Then you would end up with a leading space in your example, but handling it as an array this way avoids the problem.
Very interesting. Actually the part you mention about there being an initial ‘btn’ class is a good point. Using arrays and joining would be nice for that. I wish more people would chime in. Because between our two examples, I think mine is more readable. But yours would probably scale better. I also wonder about the performance implications of creating arrays. But that might be negligible.
The app working isn’t good enough, it needs to be maintainable. From a professional perspective, unmaintainable code is useless code.
Code that mutates everywhere is generally harder to reason about and therefore harder to maintain, so just don’t do it (unless there’s literally no other practical way, but genuinely these are very rare cases)
Fair play, I guess we’re probably just gonna disagree.
In my experience I’d say mutable code (larger than anything other than toy examples) always results in more time spent fixing bugs down the line, predominantly because it’s objectively harder for humans to reason about multiple one to many relationships rather than multiple one to one relationships. I’d say because you need to think about all possible states of the set of mutable variables in your code in order to completely understand it (and I don’t just mean understanding the intended purpose of the code, I mean understanding everything that code is capable of doing), that usually results in a more convoluted implementation than the pretty linear way you typically read functional code.
Longer code is practically always better if it’s easier to understand than the shorter alternative. Software engineers aren’t employed to play code golf, they’re employed to write maintainable software. Though I’ll say ultra high performance applications might be the exception here—but 99% of engineers aren’t doing anything like that.
I’m always happy to be convinced otherwise, but I’ve never seen a convincing argument
I oscillate between using more functional paradigms and more object-oriented ones. is that normal?
I use a linter BTW(TypeScript) if that is a useful info.
I use a combination of both. Objects are declared const, all members are set in the constructor, all methods are const. It doesn’t really work for some types of programs (e.g. GUIs) but for stuff like number crunching it’s great.
I heavily use classes while working on back end, and when I’m making a really self-contained logic, such as a logger or an image manipulation service.
but since most frontend stuff heavily leans on functional side, I go with it
I also do that. Very simple stuff, especially of those that are easy to optimize for the compiler, are often very close to functional programming paradigms.
Ha, you remember 15 year old bugs? I’ve “fixed” bugs that were deliberate decisions because the fix was worse then the bug - so I’ve then unfixed the bug and said “7 years ago xmunk, that was really quite a good decision… SO Y U NO COMMENT!” Of course, since I’ve fixed the same fix twice it’s now burned into my memory so there’s no reason to leave a comment at this point.
I love living vicariously. I feel this whole situation, and I barely ever did more then the (bare bones) intro to AMOS, or or hello world on c64 basic, but Lemmy and the hard R site (before the API mess) memes make me feel the situations at hand, even with very minimal understanding of coding.
There’s been a few times where I had to look into an issue and found a comment I wrote much earlier with a ticket number or link to a previous ticket that explains exactly why this new issue is actually the intended behavior.
It’s really helpful when the product owners clearly can’t make up their minds about what they want their apps to do.
Ive moved jobs 4 times in the last 10 years and only 1 of those jobs has actually moved me off the projects I’ve been working on.
I’ve legitimately responded to my own Issue with a fix to the bug I put in against that code that I wrote at a previous place. It’s weird.
I almost always get another set of eyes since it’s my old code but that’s always fun “hey I wrote this 6 years ago and it still works but it’s gross … please don’t judge me”
Been in mine 25 years. I could probably make more money elsewhere, but then I’d have to get a proper job rather than be the coding equivalent of an unmaintained fire extinguisher.
oh i just meant because usually tech companies go bust or merge in under five years these days :3 but that’s honestly so amazing and i’m happy that you are that happy where you are!
My colleague and “squad leader” (ie boss without the salary) is a few months younger than me and has been in the same company for about 18 years. Meanwhile I think the longest I’ve been somewhere is about 2 years.
“Where do you see yourself in 5 years?” has me giggling every time.
I could’ve used a lot of things, but I’m on my phone and I wanted fewer characters to render it, whilst being sure it would work without having to run it.
Also, I am pleased to have maybe helped. Perhaps we can be friends, you and I. Perhaps not. Idk, maybe you punch dogs, why would you do that? Seems mean.
Have you ever just, like, edited a comment? How do people know when you did it? I guess if I were writing a thing to check it I’d use a registry of timestamps and checksums… So, like, ok, you can track, but why, how does it look?
Anyway sorry I had some drinks between now and first post, goodnight
Code as given can be made valid in scala I believe. My starter was based on that assumption. I think raku can do it too, but you would probably have to x = $ to make it work…
Edit: misread your comment slightly, CBA to change mine now. It is what it is
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.