« first day (3707 days earlier)      last day (1270 days later) » 

Feeds
Feeds
4:51 AM
 
 
2 hours later…
DemonCode
DemonCode
7:02 AM
@JoelHarmon I've definitely gotten my share of that, especially since I'm trying to move towards a more functional style including in languages like C (not necessarily to the point of trying to fight the actual imperative nature of such languages and avoid all internal mutations of local temporaries in functions or trying to use polymorphic monads and higher-order functions everywhere, but at least avoiding external side effects where possible and making them pure).

It might be specific to my domain, experience, personal things I struggle with, but I've been trying for my entire career to …
 
 
5 hours later…
Joel Harmon
Joel Harmon
11:53 AM
@DemonCode Curiously, the idea of "pushing the mutations of the central program state to a few corners of the software" is essentially what Object Oriented programmers are talking about when they discuss encapsulation.
You can read quite a bit on "one reason to change" for OO classes, and the same for FP functions.
 
DemonCode
DemonCode
12:24 PM
@JoelHarmon Very much so, but I've found that simply maintaining invariants over the internal state of mutable objects to still be quite difficult to comprehend in my domain with respect to what changes can be safely sandwiched between existing code, what can be safely multithreaded... and there are the sort of inter-object invariants that can be difficult to maintain from the outside.
I've never found it quite sufficient in my cases to merely have a hierarchy of mutable objects and be very confident about correctness, even after extensive unit and integration testing, compared to bringing down the number of places that can mutate persistent application state down to the absolute bare minimum -- typically even less that what normal OO approaches entail.
I tended to work in extreme cases though where the architectures were emphasized to be open and extensible, so we often had plugins and scripts and abstract commands and so forth that could have mutable access to the entirety of our program state (our scene graph) at any given time. I found the next best thing I could do in such cases is to effectively make that scene graph immutable, and have things like commands input and output rather than mutate in place.
 
amon
amon
1:14 PM
@JoelHarmon There is a substantial difference between the FP and OOP view on state management:
* FP manages state by making state explicit, thus making it possible to reason about state (often assisted by type systems).
* OOP encapsulates state into (small) objects that can be reasoned about independently since they only communicate by sending messages.
Both of these approaches have problems. E.g. explicit states are fragile because you have to potentially change lots of stuff if the state needs more variables. And many objects aren't that independent and encapsulated in practice.
I kinda miss the time when “functional programming” just meant “lambda functions and recursion”, luckily that aspect of FP has become mainstream in the meanwhile.
 
DemonCode
DemonCode
1:39 PM
@amon A difficulty I've constantly found is that many abstractions tend to become extremely leaky if the software is designed to be an open kind of extensible architecture since we can't reason in advance what parts of the software a plugin or script might want to access. We end up with something like:

struct Command
{
virtual ~Command() {}

// The command ends up taking the entire application state (scene).
virtual void execute(Scene& scene) = 0;
};
At that point, I tend to find the codebase almost as difficult to reason about as one that uses a bunch of global variables if that shared state that's passed around everywhere is mutable.
 
 
1 hour later…
Feeds
Feeds
3:08 PM
Making the most of your one-on-one with your manager or other leadership
Teresa Dietrich on October 27, 2020
As many offices go fully remote, learning how to approach key meetings with your manager can pay big dividends.
 
Joel Harmon
Joel Harmon
4:04 PM
Sure, there are differences, but there are similarities as well. FP changes state by having a function accept a Thing and return a slightly different Thing. OOP changes state by calling methods on a Thing (and some languages like Python even implicitly convert this to calling a function accepting a Thing) and mutating state of that Thing in the background.
Both approaches recommend having few functions/methods that do this; hundreds of methods on an object is generally considered bad form, as is hundreds of functions accepting and returning the same kind of thing.
 
 
2 hours later…
DemonCode
DemonCode
6:25 PM
Immutable objects are interesting to me with methods that are pure. It seems rather unwieldy though to combine with pure virtual interfaces at least in a statically-typed language, as they'd want to return a base (smart) pointer. A lot of what I've found most useful is to favor value/copy semantics for the meaty sections of the codebase as opposed to pointer/reference.
 

« first day (3707 days earlier)      last day (1270 days later) »