3 ms·

> and implied: design patterns are bad I am honestly amazed you could interpret it that way, rather than the intended: it seems like a questionable design patt

by tus89 6y ago

> and implied: design patterns are bad I am honestly amazed you could interpret it that way, rather than the intended: it seems like a questionable design pattern. > What exactly does "having code structured around the shape of tuples returned by function" even mean? To me it sort of implies a function is serving multiple purposes, essentially multiple functions mashed into one -- and you figure out what really happened by the shape of it's return value. It seems to go against everything we think of functions as pure-as-possible constructs that do one thing well, and that is represented by a clearly defined return value. I agree there might be edgy uses cases like parsers -- but few people are really writing compilers/protocol handlers, and I am afraid that first-class features might be misused by less experienced programmers who start to write frankenfunctions coupled with convoluted pattern-match blocks -- as opposed to traditional, elegant functional decomposition. And I think functional languages are fine, however I don't always agree that just because a feature works well in the FP space it is a good idea to bring it in as a first class feature into a OO/imperative language...

coldtea 6y ago
>I am honestly amazed you could interpret it that way, rather than the intended: it seems like a questionable design pattern. "Design patterns are bad" is an often repeated "folk wisdom" in dev circles. So by under-definining what's meant (leaving it open to interpretation) it's a very easy intepretation for others to assume of the comment. The wording supports this too: "has an element of pattern-smell (and by pattern I mean design pattern)" This doesn't seem to imply "questionable design pattern", but "this smells like a pattern", and given that you object to it, one assumes that for you "smelling like a pattern" is bad. Also, "seems like a questionable design pattern" would be a bizarre interpretation to take -- as this is a first-class syntax, not a design pattern. >To me it sort of implies a function is serving multiple purposes, essentially multiple functions mashed into one -- and you figure out what really happened by the shape of it's return value. It seems to go against everything we think of functions as pure-as-possible constructs that do one thing well, and that is represented by a clearly defined return value. I see where you're coming from, but there's nothing really violating purity here, or even "clearly defined return values". Those clearly defined return values could still take several variations of a shape or even several shapes. Those won't have to be arbitrary shaped or non-pure. It's about handling a class of shapes. AST nodes for example from a parsing function, protocol parts from a protocol handler, network responses in a server that might or might not have a payload, game states in a logic loop, and so on, fall into this. And pattern matching allows you to handle this common need easily. So it's not like (pseudocode): match(foo): foo ~= duck: .. foo ~= 5: .. foo ~= "a string": .. foo ~= triangle: .. but more like: match(astNode): foo ~= expression: .. foo ~= statement: .. foo ~= variable: .. and other such cases...

by tus89 6y ago

coldtea 6y ago

>I am honestly amazed you could interpret it that way, rather than the intended: it seems like a questionable design pattern. "Design patterns are bad" is an often repeated "folk wisdom" in dev circles. So by under-definining what's meant (leaving it open to interpretation) it's a very easy intepretation for others to assume of the comment. The wording supports this too: "has an element of pattern-smell (and by pattern I mean design pattern)" This doesn't seem to imply "questionable design pattern", but "this smells like a pattern", and given that you object to it, one assumes that for you "smelling like a pattern" is bad. Also, "seems like a questionable design pattern" would be a bizarre interpretation to take -- as this is a first-class syntax, not a design pattern. >To me it sort of implies a function is serving multiple purposes, essentially multiple functions mashed into one -- and you figure out what really happened by the shape of it's return value. It seems to go against everything we think of functions as pure-as-possible constructs that do one thing well, and that is represented by a clearly defined return value. I see where you're coming from, but there's nothing really violating purity here, or even "clearly defined return values". Those clearly defined return values could still take several variations of a shape or even several shapes. Those won't have to be arbitrary shaped or non-pure. It's about handling a class of shapes. AST nodes for example from a parsing function, protocol parts from a protocol handler, network responses in a server that might or might not have a payload, game states in a logic loop, and so on, fall into this. And pattern matching allows you to handle this common need easily. So it's not like (pseudocode): match(foo): foo ~= duck: .. foo ~= 5: .. foo ~= "a string": .. foo ~= triangle: .. but more like: match(astNode): foo ~= expression: .. foo ~= statement: .. foo ~= variable: .. and other such cases...