3 ms·

This is nice and all, but part of me feels like having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by

• _ZeD_ 6y ago
  If this can make feel better, you can type-alias the tuple shape and "squint" them as classes
• coldtea 6y ago
  >having code structured around the shape of tuples returned by functions has an element of pattern-smell (and by pattern I mean design pattern). This is a near content-less critique, which amounts to: "shaping code around what's returned by functions looks like a design pattern (and implied: design patterns are bad)" Well, design patterns are neither bad, nor good. They are what they are: a high level description of common solutions to common problems. By themselves design patterns are not problems or problematic. It's applying them where they don't fit the problem - or where something simpler will suffice - that's problematic (common e.g. to J2EE era Java). Some also say that design problems point to a language deficiency (that is, make up for a lack of language feature, like e.g. closures or dynamic typing). If we accept the above folk wisdom, built-in pattern matching would be the exact opposite of what you say. It wouldn't be a "design pattern smell" but rather a first-class feature that frees you from having to workaround its lack with design patterns. But I'd go further and say that the complain is nonsensical anyway. What exactly does "having code structured around the shape of tuples returned by function" even mean? If there's a need to extract values from the results of a function (e.g. in a parser, a protocol handler, etc.) then we don't have alternatives, we will structure our code "around the shapes returned". The question if whether we will do it through ad-hoc solutions (like chained "if" statements, a series of switch/case, etc.), through some convoluted design pattern like a Visitor, or by first class support for exactly our need. This first class support is exactly what pattern matching syntax offers. And far from being some smell/Python novelty, it's an old staple found in Haskell, ML, Ocaml, Lisp, and several other places besides...
  • 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...
• mrkeen 6y ago
  If it helps, you can think of 'tuples' as data, and 'shape' as structure. Then your code is structured around 'data structures' returned by functions.
• deleted 6y ago
  [deleted]