3 ms·

Is there any good writing on overuse of tuples? Up until this thread, I just always thought that was a pet peeve of mine. Internally I've tried to make the cas

Is there any good writing on overuse of tuples? Up until this thread, I just always thought that was a pet peeve of mine. Internally I've tried to make the case that nobody understands the reason a tuple exists except the person who wrote it, and a discriminating union, record, or variant is always a better choice if you're optimizing for the common case (that is, readability).

slver 6y ago
The industry is balkanized on it. Functional languages which tend to model closed systems, with strict types, and hence easier ad-hoc refactoring swear by tuples. OOP platforms which deal with the "outside world" a lot and so need stable API that can evolve without BC breaks avoid tuples. Notice also web APIs virtually never use tuples (everything is objects with named fields both in complex input and virtually all output). A language that targets the browser is going to be inherently open. It has to deal with browser DOM, it has to deal with service APIs, it also has to potentially interact with JS libraries. It'll be an uphill struggle to apply Ocaml style in it.
- pyrale 6y ago
  > Functional languages which tend to model closed systems [...] OOP platforms which deal with the "outside world" a lot The open vs closed systems logic simply doesn't have any kind of relation with whether one "deals with the outside world", it's about knowing what you're about to receive. And Java, which you quoted earlier, is very much geared for closed systems. On the other hand, Prolog, a language that hardly qualifies as OOP is built to work on open systems. Closed systems language deal with the outside world pretty gracefully, by parsing their inputs. > A language that targets the browser is going to be inherently open. There's been a flurry of closed-system languages for the web in the last decade (e.g. Elm, Fable, etc.), and they work just fine.
  - slver 6y ago
    You fail to account for change, and time. As functional languages often do. /s Tuples have coupling order. That's a fact. So if you have tuple [a, b, c, d], then you can maybe extend this by adding ...e, f] at the end, if your parser can ignore extraneous items. But even if your parser can do that, you still can't remove b without BC breaks, because then the rest get shifted, and you have a mess. This is not a problem when the tuple exists only in the confines of some singular unit of code, that gets refactored together. But if it escapes, you have a problem. Because over time, you'll want to change this tuple, and you can't refactor the entire world at once (which is more often than not the issue of functional programming and why it can't scale well).
    - pyrale 6y ago
      You seem to believe that, because tuples are available in a language, they will be used everywhere. And indeed, that wouldn't be great. From my mileage in this industry, though, the cases you describe simply don't happen. As you said, tuples aren't used in interfaces, because developers know better than to do that. > which is more often than not the issue of functional programming and why it can't scale well I don't know what you've done with FP, but in your last few posts, you've been making claims about it that simply don't match my experience. There's not much to discuss without specifics, though, so maybe you could expand about the cases where you had issues with it?
      - slver 6y ago
        I wish tuples didn't exist in interfaces, unfortunately every function and method argument list is one. /s I appreciate your point that people try and avoid tuples where not appropriate, but the question is why even have that opportunity, when we can nudge the community to use equivalent "named attribute tuples". Regarding scale, FP scales great for certain types of problems. But it's not great at modeling or encouraging boundaries. Imagine doing FP where all your types cease to exist for part of your codebase, but also you need to interact with the code where the types are. Even more, imagine if those two modules may fail independently (i.e. so you lose one of them). Anyway I think I'm becoming too abstract. Basically the FP world needs to be more like Erlang. Erlang is functional but keeps units bounded (in processes).

slver 6y ago

The industry is balkanized on it. Functional languages which tend to model closed systems, with strict types, and hence easier ad-hoc refactoring swear by tuples. OOP platforms which deal with the "outside world" a lot and so need stable API that can evolve without BC breaks avoid tuples. Notice also web APIs virtually never use tuples (everything is objects with named fields both in complex input and virtually all output). A language that targets the browser is going to be inherently open. It has to deal with browser DOM, it has to deal with service APIs, it also has to potentially interact with JS libraries. It'll be an uphill struggle to apply Ocaml style in it.

pyrale 6y ago
> Functional languages which tend to model closed systems [...] OOP platforms which deal with the "outside world" a lot The open vs closed systems logic simply doesn't have any kind of relation with whether one "deals with the outside world", it's about knowing what you're about to receive. And Java, which you quoted earlier, is very much geared for closed systems. On the other hand, Prolog, a language that hardly qualifies as OOP is built to work on open systems. Closed systems language deal with the outside world pretty gracefully, by parsing their inputs. > A language that targets the browser is going to be inherently open. There's been a flurry of closed-system languages for the web in the last decade (e.g. Elm, Fable, etc.), and they work just fine.
- slver 6y ago
  You fail to account for change, and time. As functional languages often do. /s Tuples have coupling order. That's a fact. So if you have tuple [a, b, c, d], then you can maybe extend this by adding ...e, f] at the end, if your parser can ignore extraneous items. But even if your parser can do that, you still can't remove b without BC breaks, because then the rest get shifted, and you have a mess. This is not a problem when the tuple exists only in the confines of some singular unit of code, that gets refactored together. But if it escapes, you have a problem. Because over time, you'll want to change this tuple, and you can't refactor the entire world at once (which is more often than not the issue of functional programming and why it can't scale well).
  - pyrale 6y ago
    You seem to believe that, because tuples are available in a language, they will be used everywhere. And indeed, that wouldn't be great. From my mileage in this industry, though, the cases you describe simply don't happen. As you said, tuples aren't used in interfaces, because developers know better than to do that. > which is more often than not the issue of functional programming and why it can't scale well I don't know what you've done with FP, but in your last few posts, you've been making claims about it that simply don't match my experience. There's not much to discuss without specifics, though, so maybe you could expand about the cases where you had issues with it?
    - slver 6y ago
      I wish tuples didn't exist in interfaces, unfortunately every function and method argument list is one. /s I appreciate your point that people try and avoid tuples where not appropriate, but the question is why even have that opportunity, when we can nudge the community to use equivalent "named attribute tuples". Regarding scale, FP scales great for certain types of problems. But it's not great at modeling or encouraging boundaries. Imagine doing FP where all your types cease to exist for part of your codebase, but also you need to interact with the code where the types are. Even more, imagine if those two modules may fail independently (i.e. so you lose one of them). Anyway I think I'm becoming too abstract. Basically the FP world needs to be more like Erlang. Erlang is functional but keeps units bounded (in processes).