4 ms·

I'm not sure a new language in 21st century should focus on ordered tuples as a core data type. They're fundamentally hard to debug and not evolvable. Ultimate

by slver 6y ago

I'm not sure a new language in 21st century should focus on ordered tuples as a core data type. They're fundamentally hard to debug and not evolvable. Ultimately all objects/structs/records are at their core tuples. But we refer to their attributes by name for a good reason.

pyrale 6y ago
Imo tuples are a nice feature for the same reason lambdas are. Sometimes, you just want an anonymous way to bundle a few values in a local context. For instance: match (a, b) with: (4, 2) => "Hello" (1, 0) => "World" (_, _) => "nope"
- slver 6y ago
  The trouble is that tuples are not restricted to local context. JS has made a few steps in allowing us to have objects as compact as a tuple, i.e. {foo, bar, baz}. I think we need more effort in that direction. But keep fields addressable by name at all times. In fact, ordered arguments in functions have the same problem (they're a tuple). Unfortunately that ship has sailed.
  - pyrale 6y ago
    The issue with that is that making tuples a local-only construct is not trivial. A run-of-the-mill tuple is a data type that fits in the type system quite well, it's not costly to create. But a tuple that can only be used locally requires to make a special case in the compiler, and to check it everywhere. Besides, you may end up with divergences in your community about how local a tuple should be allowed to be. Can it be passed to a lambda? Can you map over it in a local context? etc. Overall, deciding where tuples should be used is an easy choice for the developer, and a very hard choice for the language creator.
    - slver 6y ago
      If developers used tuples wisely we wouldn't be having this conversation. That's the primary reason why Java has no tuples.
      - pkilgore 6y ago
        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.
    - dgreensp 6y ago
      Making the names part of the type solves this, like structural object types in TypeScript. I’ve come to the conclusion myself that, with the right language syntax supporting it, positional arguments and tuples should be limited to two, maybe three entries, and in the vast majority of cases should be replaced with named/keyword arguments and records even when they are that small (with unnamed, ordered entries being used in cases where there aren’t better names than “first” and “second” or “a” and “b”).
- jffry 6y ago
  Or perhaps a more real-world example ;) match (n % 3, n % 5) with: (0, 0) => print "FizzBuzz" (1, 0) => print "Fizz" (0, 1) => print "Buzz" (_, _) => print n
  - Smaug123 6y ago
    By the way, you have a large number of bugs here if you're trying to solve the famous real-world problem. What about 3 or 5 or 9?
    - jffry 6y ago
      Any resemblance to a specific real-world problem is purely coincidental ;)
    - pyrale 6y ago
      > real-world problem. I never heard about a real-world problem associated with fizz-buzz, besides teaching children to count. Do you have some documentation about that?
otabdeveloper4 6y ago
Tuples are the data type representing "top of the stack", so as a core data type it's great; tuples + arrays + syntactic sugar are the building blocks that give you all the other data types.
- valenterry 6y ago
  Sum-types are missing in your list ("either A or B").
  - Smaug123 6y ago
    Though I will continue to claim that quotient types should belong in the list but aren't - even in Cubical Agda that problem's not really solved! If you don't have an easily-computed canonical form for your equivalence classes, you're doomed in almost any language.
    - valenterry 6y ago
      Thank you for the term "quotient types", that's the first time I'm hearing that!!! I agree that this would be an amazing thing to have, but I've never seen those anywhere in practice (not even in Idris). My gut-feeling tells me that it might not work in combination with composability in the sense that there might never be a proper global "equal" that everyone can agree one. I'm curious - besides the ones mentioned, are there any other fundamental type concepts that you would build into your own programming language? :)
      - Smaug123 6y ago
        Sadly I don't have "my own programming language", and even if I did, I think this is an unsolved problem in language design :P Interesting question, though; I'll think about it.

by slver 6y ago

pyrale 6y ago

Imo tuples are a nice feature for the same reason lambdas are. Sometimes, you just want an anonymous way to bundle a few values in a local context. For instance: match (a, b) with: (4, 2) => "Hello" (1, 0) => "World" (_, _) => "nope"

slver 6y ago
The trouble is that tuples are not restricted to local context. JS has made a few steps in allowing us to have objects as compact as a tuple, i.e. {foo, bar, baz}. I think we need more effort in that direction. But keep fields addressable by name at all times. In fact, ordered arguments in functions have the same problem (they're a tuple). Unfortunately that ship has sailed.
- pyrale 6y ago
  The issue with that is that making tuples a local-only construct is not trivial. A run-of-the-mill tuple is a data type that fits in the type system quite well, it's not costly to create. But a tuple that can only be used locally requires to make a special case in the compiler, and to check it everywhere. Besides, you may end up with divergences in your community about how local a tuple should be allowed to be. Can it be passed to a lambda? Can you map over it in a local context? etc. Overall, deciding where tuples should be used is an easy choice for the developer, and a very hard choice for the language creator.
  - slver 6y ago
    If developers used tuples wisely we wouldn't be having this conversation. That's the primary reason why Java has no tuples.
    - pkilgore 6y ago
      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.
  - dgreensp 6y ago
    Making the names part of the type solves this, like structural object types in TypeScript. I’ve come to the conclusion myself that, with the right language syntax supporting it, positional arguments and tuples should be limited to two, maybe three entries, and in the vast majority of cases should be replaced with named/keyword arguments and records even when they are that small (with unnamed, ordered entries being used in cases where there aren’t better names than “first” and “second” or “a” and “b”).
jffry 6y ago
Or perhaps a more real-world example ;) match (n % 3, n % 5) with: (0, 0) => print "FizzBuzz" (1, 0) => print "Fizz" (0, 1) => print "Buzz" (_, _) => print n
- Smaug123 6y ago
  By the way, you have a large number of bugs here if you're trying to solve the famous real-world problem. What about 3 or 5 or 9?
  - jffry 6y ago
    Any resemblance to a specific real-world problem is purely coincidental ;)
  - pyrale 6y ago
    > real-world problem. I never heard about a real-world problem associated with fizz-buzz, besides teaching children to count. Do you have some documentation about that?

otabdeveloper4 6y ago

Tuples are the data type representing "top of the stack", so as a core data type it's great; tuples + arrays + syntactic sugar are the building blocks that give you all the other data types.

valenterry 6y ago
Sum-types are missing in your list ("either A or B").
- Smaug123 6y ago
  Though I will continue to claim that quotient types should belong in the list but aren't - even in Cubical Agda that problem's not really solved! If you don't have an easily-computed canonical form for your equivalence classes, you're doomed in almost any language.
  - valenterry 6y ago
    Thank you for the term "quotient types", that's the first time I'm hearing that!!! I agree that this would be an amazing thing to have, but I've never seen those anywhere in practice (not even in Idris). My gut-feeling tells me that it might not work in combination with composability in the sense that there might never be a proper global "equal" that everyone can agree one. I'm curious - besides the ones mentioned, are there any other fundamental type concepts that you would build into your own programming language? :)
    - Smaug123 6y ago
      Sadly I don't have "my own programming language", and even if I did, I think this is an unsolved problem in language design :P Interesting question, though; I'll think about it.