@miriamrobern ohh thank you!

it’s probably meant to get past reddit’s extremely over-aggressive censorship filters, but still. at least hint at it more strongly in the post’s description

people need to stop abbreviating their content warnings omg

there’s a post on r/GoneWildAudioTrans and one of its content warnings is “very light sph*” and I have no idea what that’s supposed to mean, which defeats the whole purpose of it being a content warning. and I can’t google for it either because it’s got a special character in it

and tbh googling for content warning abbreviations generally doesn’t work anyway because stuff like “uspol” or “mh-“ is too obscure to have meaningful results

@fargate nope you definitely got it! this was a very interesting read and it definitely addressed my main complaint, about functional programming seemingly have no way to annotate what kind of data a function takes, or how it transforms that data, or what that data means. it looks like in Haskell you can do all three! thanks for explaining all of this

and I’m really glad that Haskell has features like this. I’ve been interested in learning it for a while to be honest. it and also F#

I’m really hoping that Common Lisp will turn out to have this kind of thing too, because at the moment I’ve just been leaving comments where I give everything Python-style type annotations lol just so that I can keep track of all of the datatypes in my head

I’ve been reading a book about Common Lisp lately (Land of Lisp) and it’s given me a new appreciation for object-oriented programming

specifically what I love about OOP is how it adds context to data and data manipulations. so that your code doesn’t just show what specific data manipulations you’re doing, but also why you’re doing those manipulations, what implications those manipulations have for the meaning of the data, and even what exact format of data is expected in the first place

for example here’s a data structure that represents all of the paths that you can take in a text adventure game:

paths = [
    ["living-room", ["garden", "west", "door"],
                    ["attic", "upstairs", "ladder"]],
    ["garden", ["living-room", "east", "door"]],
    ["attic", ["living-room", "downstairs", "ladder"]],
]

can you tell what each section of this data is meant to represent? it’s not exactly self-explanatory

but how about now?:

living_room_paths = AdventureGamePaths(
    location="living-room",
    paths=[
        AdventureGamePath(
            leads_to="garden",
            direction="west",
            description="door",
        ),

        AdventureGamePath(
            leads_to="attic",
            direction="upstairs",
            description="ladder",
        ),
    ],
)

garden_paths = AdventureGamePaths(
    location="garden",
    paths=[
        AdventureGamePath(
            leads_to="living-room",
            direction="east",
            description="door",
        ),
    ],
)

attic_paths = AdventureGamePaths(
    location="attic",
    paths=[
        AdventureGamePath(
            leads_to="living-room",
            direction="downstairs",
            description="ladder",
        ),
    ],
)

paths: dict[str, AdventureGamePaths] = {
    "living-room": living_room_paths,
    "garden": garden_paths,
    "attic": attic_paths,
}

obviously this code is dramatically more verbose but it’s also so much clearer what all of those strings actually mean. grouping data into objects adds so much context and meaning to the data. it also ensures that I’m following exactly the right data format at every step

now let’s pretend that we’re working with the first style of data structure (nesting simple structures like lists and dicts) and we want to make a function that prints descriptions of all of the paths from a given room:

def describe_path(path):
    return "there is a " + path[2] + " going " + path[1] + " of here"

def describe_paths(location, paths):
    return '\n'.join(map(describe_path, paths[location]))

looking at this, can you tell exactly what format of data structure describe_paths() accepts for its path argument? or what about the data structure that describe_path expects? you can definitely figure it out eventually but it’ll take some sleuthing and some assumptions on the part of the reader

also, where is the data that these functions are meant to operate on? is it in this file, or somewhere else? it’s disconnected from the functions, so it could be anywhere. so if you have a nasty monolithic data structure in an unknown format, how are you supposed to figure out which functions you can use on it and which functions you can’t? how do you pull up a list of useful operations for that specific data?

you might be thinking that I’m deliberately making my code overly terse and arcane, but this is a 1:1 recreation of some example code in my Lisp book - I just converted it into Python instead

now compare those two functions above to this instead:

@dataclass
class AdventureGamePath:
    leads_to: str
    direction: str
    description: str

    def describe(self) -> str:
        return "there is a " + path.description + " going " + path.direction + " of here"

@dataclass
class AdventureGamePaths:
    location: str
    paths: list[AdventureGamePath]

    def describe_paths(self, location: str) -> str:
        path_descriptions = ""

        for path in self.paths:
            path_descriptions += path.describe() + "\n"

        return path_descriptions

again, this is much more verbose, but it’s also much clearer isn’t it? now if I see an AdventureGamePaths object I know exactly what it represents (more than one AdventureGamePath) and exactly what I can do with it (I can tell it to describe its paths)

I feel like functional programming tends to result in code that’s very terse but that doesn’t have much context behind it. there are often weird data structures left lying around without any hint about what they represent or what you can do with them - and lying next to them are arcane one-liner functions that may or may not be meant to operate on those data structures. maybe if you stare at those one-liner functions for long enough you can figure out what data manipulation they do, but what does that data manipulation mean?

so I have a renewed appreciation for classes and objects because they allow you to:

• apply tons of meaning to an arbitrarily complex data structure simply because that data structure is composed of objects
• make it clear not just what exact arrangement of data a function takes, but what that data means as well
• associate your data with {the stuff you can do to that data}, so nobody is left scratching their head wondering where to find the functions that operate on it

with all of this said, I don’t think that all functional programming is doomed to be arcane and unclear. I’ve heard about a concept called “typeclasses” that some functional programming languages have. I don’t know too much about them but it sounds like they’re a mathy functional programming take on classes. and those might be able to replicate the advantages of classes and objects without exactly being classes and objects

I will never stop being bitter about how in schools there’s a mandatory class called “English” (implying it’s teaching you how to communicate) whose purpose is to teach kids the “objectively correct” way to engage with art

and the “correct” way is specifically to analyze its symbolism. no other way is considered valid or correct, and even then you have to guess what the “correct” symbolism is. the art is also chosen for them and is often disturbing, but they’re forced to read it anyway

there are at least 9 different reasons why everything I just said is fucked up and wrong

and keep in mind that kids could be learning literally anything else instead of this