|
gee id hate to use a machine with this "global mutable state"
|
#
?
Jan 18, 2018 20:47
|
|
|
|
| # ? Jun 9, 2024 05:07 |
|
|
comedyblissoption posted:The primary reason code in Java/C#/C++/javascript/whatever devolves into spaghetti is unnecessary pervasive use of global mutable state. Pervasive use of global mutable state defeats localized understanding of code. To understand code in the context of global mutable state requires looking at how that state is used everywhere. To modify code correctly in the context of global mutable state, you often must maintain implicit global invariants. Even though function Foo might not have global mutable state under the hood now, in the future it silently may. see my imposter syndrome goes off real hard when i read really insightful posts like this that i 1) never would have been able to put to words 2) had to google half of the terms to refresh myself from sophomore year of my bs in cs
|
|
#
?
Jan 18, 2018 20:49
|
|
|
its not insightful its a load of bullshit. if your application doesn't have state its not an application its a math toy. state is hard to do right, but you have to do it.
|
|
#
?
Jan 18, 2018 20:52
|
|
|
Shaggar posted:its not insightful its a load of bullshit. if your application doesn't have state its not an application its a math toy. state is hard to do right, but you have to do it. you're confusing side effects with state. but the only thing they have in common is that the FP crowd rails against both. an app must necessarily have side effects to do anything useful. it doesn't necessarily need internal state. a good backend application will put all its state out of the application code (in the storage, where filesystem and databases take care of hard problems like consistency and atomicity), and then treat each command as if it were brand new and freshly started
|
|
#
?
Jan 18, 2018 21:24
|
|
|
Shaggar posted:its not insightful its a load of bullshit. if your application doesn't have state its not an application its a math toy. state is hard to do right, but you have to do it. comedyblissoption posted:The primary reason code in Java/C#/C++/javascript/whatever devolves into spaghetti is unnecessary pervasive use of global mutable state. The way to do state right is to have the majority of your functions transform immutable data into immutable data, then have clearly-annotated operations manipulate the global state and handle interaction using these functions. Ideally, you express the difference between "function" and "operation" using some method that means you can't accidentally have an operation take place inside a function, such as through the type system.
|
|
#
?
Jan 18, 2018 21:37
|
|
|
NihilCredo posted:you're confusing side effects with state. but the only thing they have in common is that the FP crowd rails against both. cgi was...right?
|
|
#
?
Jan 18, 2018 21:41
|
|
|
Zemyla posted:The way to do state right is to have the majority of your functions transform immutable data into immutable data, then have clearly-annotated operations manipulate the global state and handle interaction using these functions. Ideally, you express the difference between "function" and "operation" using some method that means you can't accidentally have an operation take place inside a function, such as through the type system. Instead of making everything immutable, Rust has an interesting approach to limiting mutability to aid program understanding. In Rust, you must notate scope of mutability and immutability. Rust also enforces that data is not mutably aliased. The default is for immutability. This approach combines the performance benefits of mutability with the localized understanding of immutability. Since all mutability is explicit, you can treat a mutable function parameter as just an input->output relationship of the function. Here's a cool blog post talking about this: https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ Rust does have a way to put in global mutable state for an application, but abusing this system is unidiomatic.
|
|
#
?
Jan 18, 2018 21:58
|
|
|
comedyblissoption posted:Pervasive unnecessary global mutable state is idiomatic in all of the industry C#/C++/Java/javascript codebases I have worked on. you could call it......idiotmatic 
|
|
#
?
Jan 18, 2018 22:00
|
|
|
is there a way to get vs code to automagically hide all the files specified in my .gitignore?
|
|
#
?
Jan 18, 2018 22:03
|
|
|
Lutha Mahtin posted:you could call it......idiotmatic Instead of defining a function that just trivially takes in an A and returns a B, the industry standard is to instead: Write a function that takes in an A. Read and mutate important global variable G. Also return a B. Also maybe mutate A. Repeat for all your functions dealing with this area until you need to understand how all the functions interact together in a grand spaghetti before you can usefully touch any function.
|
|
#
?
Jan 18, 2018 22:05
|
|
|
i wonder if haskell nerds have hard drives...
|
|
#
?
Jan 18, 2018 22:07
|
|
|
idk I think it's important to try to define what causes spaghetti code in concrete terms so you can avoid creating spaghetti code yourself
|
|
#
?
Jan 18, 2018 22:32
|
|
|
most of the spaghetti c++ code I've seen recently was because of fuckers who like to reuse code by massively cut and pasting everything and not that much because of mutability (for instance I was recently able to take a giant disgusting function full of repetitive copy pasted crap and move it almost unchanged into a multithreaded job because as disgusting as it was it wasn't that hard to determine what it touched)
|
|
#
?
Jan 18, 2018 22:52
|
|
|
comedyblissoption posted:In Rust, you must notate scope of mutability and immutability... The default is for immutability. Same sort of thing with F#, though being part of the .net runtime means you can abuse reflection to mutate things the compiler considers immutable. But that's where code review comes in. ML-flavoured languages lend themselves far more to "function returns new state computed from passed args" style programming than C-style languages do imo.
|
|
#
?
Jan 18, 2018 22:53
|
|
|
carry on then posted:i wonder if haskell nerds have hard drives... imagine if you did a thing and it couldn't do anything that it didn't promise it would do. imagine if that was was how things worked by default imagine if you wrote a browser doing things this way because you were tired of being stabbed in the foot because you checked whether the lights were on. imagine you were tired of programming around optimizations that made sense forty years ago, but are deoptizations today. so you threw c++ in the trash, where it belongs you could call it firefox quantum or something
|
|
#
?
Jan 18, 2018 22:58
|
|
|
imagine if you had to ship a product this year
|
|
#
?
Jan 18, 2018 23:00
|
|
|
carry on then posted:i wonder if haskell nerds have hard drives... HDDs are for the dirty mutable peasants to deal with
|
|
#
?
Jan 18, 2018 23:10
|
|
|
c tp s: assumptions about fifo ordering of messages break down in the face of "oh, an exception? just put that message on the back of the queue and deal with it later"
|
|
#
?
Jan 18, 2018 23:11
|
|
|
carry on then posted:i wonder if haskell nerds have hard drives... Haskell actually has several methods of managing mutability:
The first two aren't strictly necessary - any function that could be calculated with ST can be calculated without ST, with at most an O(log n) slowdown; and it's rare that a program would want a plain old IORef instead of an MVar or full STM. The other two are primarily for communicating between threads, which does require mutability (but if you've got threads, you're already doing IO).
|
|
#
?
Jan 18, 2018 23:13
|
|
|
Zlodo posted:imagine if you had to ship a product this year uh i do and i'm using immutable things because it's a technique you can use in any language? you fool, you loving moron
|
|
#
?
Jan 18, 2018 23:16
|
|
|
java/c#/etc are good languages because brainlets can pick them up and start writing software and then you can over the course of several years tenderly beat them around the head with a shovel until they learn how to do it correctly i.e. use immutable and persistent data structures everywhere it makes sense to do so, which when you're writing database skins for http turns out to be most places.
|
|
#
?
Jan 18, 2018 23:19
|
|
|
by enforcing immutable objects everywhere in our codebase i've completely eliminated our lower level guys from doing really dumb poo poo like having models passed around that are sometimes completely filled and sometimes need to be "filled" later by calling another function.
|
|
#
?
Jan 18, 2018 23:22
|
|
|
Brain Candy posted:uh i do and i'm using immutable things because it's a technique you can use in any language? I was talking about the "throw c++ in the trash" part but applying immutability everywhere is also a fantasy when you are performance constrained (console cpus are poo poo and you have 30ms to update the massive amount of disparate crap that have been piled up in your game to reach 30fps) immutability is a useful abstraction but it is still an abstraction: the actual machine that exists in the real world is mutable. that abstraction have a cost that you can't always afford to pay everywhere in all circumstances
|
|
#
?
Jan 18, 2018 23:28
|
|
|
NihilCredo posted:you're confusing side effects with state. but the only thing they have in common is that the FP crowd rails against both. state is the side effect. the entire point of your application is to change state.
|
|
#
?
Jan 18, 2018 23:28
|
|
|
Zemyla posted:Haskell actually has several methods of managing mutability: cool. java also has ways to avoid global state spaghetti so stop comparing the worst java to the best of your favorite language then deciding that all java programmers must be children, thanks
|
|
#
?
Jan 18, 2018 23:40
|
|
|
you're supposed to compare the best of java to the worst of your programming language, then come to exactly the same conclusion
|
|
#
?
Jan 18, 2018 23:42
|
|
|
someone is handing off an android app to me that has apparently been written in groovy. how worried should i be?
|
|
#
?
Jan 18, 2018 23:57
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? a lot
|
|
#
?
Jan 18, 2018 23:58
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? you are already dead
|
|
#
?
Jan 19, 2018 00:07
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? 
|
|
#
?
Jan 19, 2018 00:08
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? prepare for a total refactor, my dude
|
|
#
?
Jan 19, 2018 00:15
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? try decompiling it to java
|
|
#
?
Jan 19, 2018 00:16
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? hahahaha
|
|
#
?
Jan 19, 2018 00:17
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? 
|
|
#
?
Jan 19, 2018 00:17
|
|
|
speaking of writing apps in meme languages, my coworker keeps trying to get us to write android apps in react native and my gut reaction is to run away screaming how terrible is react native
|
|
#
?
Jan 19, 2018 00:18
|
|
|
Zlodo posted:but applying immutability everywhere is also a fantasy when you are performance constrained it's actually loving fantastic when you have many beefy cores or lots of wimpy cores because you can use cool tricks like CAS instead of locks quote:immutability is a useful abstraction but it is still an abstraction: i contend that mutability is instead an optimization? one that was almost always required in the past, but should be used only with cunning and skill now? quote:the actual machine that exists in the real world is mutable. that abstraction have a cost that you can't always afford to pay everywhere in all circumstances even talking about bytes on an 'actual machine' is somewhat of a useful lie. the target of a programming language is primarly a human mind
|
|
#
?
Jan 19, 2018 00:19
|
|
|
HoboMan posted:someone is handing off an android app to me that has apparently been written in groovy. how worried should i be? you have no chance make your time
|
|
#
?
Jan 19, 2018 00:22
|
|
|
Luigi Thirty posted:you are already dead
|
|
#
?
Jan 19, 2018 00:23
|
|
|
JawnV6 posted:gee id hate to use a machine with this "global mutable state" i mean this misses the point on one level, but on another is totally correct? you computer doesn't know poo poo about classes or structs or functions or whatever mental model you write to that lets you get the outcome you'd like
|
|
#
?
Jan 19, 2018 00:25
|
|
|
|
| # ? Jun 9, 2024 05:07 |
|
|
talking about just mutable or immutable persistent data structures is a false dichotomy you can also have mutable data structures (for performance reasons) that you can make explicitly immutable in a scope. you can get most of the benefits of both worlds
|
|
#
?
Jan 19, 2018 00:26
|
|