I just had a realization about a point of confusion I’ve had with functional programming languages for a long time: sometimes, in functional programming, an entire value can represent an abstraction and you aren’t meant to know anything about its internals at all

in the languages that I’m used to:

• if you have a function, that signals that it’s an abstraction and you’re only meant to understand its inputs, its outputs, and its side effects
• if you have a class or object, that signals that it’s an abstraction and you’re only meant to understand its methods (as if they were functions), its publicly-accessible data, and roughly what data it’s representing internally
• if you have any other type of data, you’re meant to understand every detail of it, because it’s not an abstraction

but since functional programming doesn’t use classes, the abstractions go more like this:

• if you have a function, it’s the same as above (know side effects, inputs, outputs, everything else is abstracted)
• if you have certain data types (I’m not sure how you know which ones but there is probably a well-defined indicator) that signals an abstraction and you’re only meant to know what type it is (so you know which functions can operate on it) and roughly what its internal data represents
• otherwise, you should know everything about the data because it’s not abstracted

so that explains a lot lol. I was talking to a functional programmer about why they were sadistically (from my perspective) asking the caller to do a bunch of very complex function composition in order to use their public API, but from their perspective the function composition was an implementation detail and what was actually happening is that functions were being used to manipulate abstractions in a way that was probably very intuitive to them. and this distinction was completely lost on me at the time so I just got confused and frustrated

stuff like this has me thinking that the cultural differences between functional programmers and {mixed paradigm or OOP} programmers might be so extreme that you’d need a translation layer between functional code and OOP code in order for programmers on each side to use each others’ APIs. because even very fundamental things like “how do I recognize a black box when I see one?” are very different between them, and in a way that’s so implicit that they aren’t even aware that it’s a cultural difference

also this has me worried that I’m going to have no idea how to do abstractions in Racket lol. I think you use structs for that? maybe it’ll make sense when I start experimenting

@kasdeya with what I've worked with. You usually only know for sure that the object passed in has specific fields and the object you return will have specific fields as well. So the abstraction is usually done by using higher order functions that decide based on the input state what kind of function to use and they all ideally have the same shape for the data they return in the end.

Tried coming up with an example. But I'm neck deep in Reactjs render hell and my brain is fried 🤯

@codingcoyote hm I’m having trouble imagining what those higher order functions would be or how they work, but I think I roughly understand overall! it kinda reminds me of Python’s duck typing, where as long as the expected fields are there then everything is okay. almost like following an implicit interface

@kasdeya
This summarizes the agony of switching to nixos quite well.