9 ms·

This language is for fun, but the Unison [1], where names don't matter, is not. [1] https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/

This language is for fun, but the Unison [1], where names don't matter, is not. [1] https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/docs/the-big-idea/

mpweiher 3y ago
Yeah, this always struck me as an anti-feature of Unison, and having listened to some podcasts and read some blog posts of the creators explaining the wonderful things it enables hasn't really changed my opinion. Decoupling and abstraction via naming is fundamental to both computation and data storage.
- lifthrasiir 3y ago
  > Decoupling and abstraction via naming is fundamental to both computation and data storage. While I don't think Unison to become the next big thing(TM), that's irrelevant to what Unison claims in my understanding. You can always name any term as in most other languages, and in fact you can also have a nominal type as well (cf. `unique type`). So you can distinguish multiple terms with otherwise structurally equivalent representations, and use names to refer to them. The obvious following question is: what is different then? In conventional languages where you define a function `f(x, y) = x + y`, `f` is engraved into some sort of namespace, like a symbol table of the static or shared library file. That obviously implies a possibility of collision, and a common remedy is to have multiple or nested namespaces to separate them, but that doesn't fully fix this issue because such separation is not automatic. In Unison everything is first automatically named according to a hash of its implementation, and then can be aliased to other names. So the collision is impossible by default. Unison still has a type system, so I believe decoupling is still possible by multiple terms with the same type but different implementations (thus different hashes).
  - mpweiher 3y ago
    Decoupling and abstraction not distinguishing. The implementation is supposed to be hidden and changeable independently of the interface and independently of clients. If I am coupled to the implementation, it's not an abstraction.
    - lifthrasiir 3y ago
      If that's your definition, I believe no one actually follows that definition because there are a lot of ways for abstractions to leak their implementation details, which might not be fully captured by interfaces. A good example is the performance. If you need a fast enough implementation with the same interface, you are not doing the abstraction in your definition because the "fast enough" implementation is an implicit coupling factor. More commonly, and in my opinion, more reasonably, any abstraction involves a trade-off. Some abstractions can be quite leaky but darn easy to use. Others may be less leaky but difficult to use (or misuse, depending on your view). There is no non-leaky abstraction here. Once you've chosen a trade-off and thus abstraction, you are still not entirely free from coupling for the aforementioned reason, but can enjoy some level of freedom thanks to the trade-off made. Unison is no different from other conventional languages in this sense.

This language is for fun, but the Unison [1], where names don't matter, is not. [1] https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/docs/the-big-idea/

mpweiher 3y ago

Yeah, this always struck me as an anti-feature of Unison, and having listened to some podcasts and read some blog posts of the creators explaining the wonderful things it enables hasn't really changed my opinion. Decoupling and abstraction via naming is fundamental to both computation and data storage.

lifthrasiir 3y ago
> Decoupling and abstraction via naming is fundamental to both computation and data storage. While I don't think Unison to become the next big thing(TM), that's irrelevant to what Unison claims in my understanding. You can always name any term as in most other languages, and in fact you can also have a nominal type as well (cf. `unique type`). So you can distinguish multiple terms with otherwise structurally equivalent representations, and use names to refer to them. The obvious following question is: what is different then? In conventional languages where you define a function `f(x, y) = x + y`, `f` is engraved into some sort of namespace, like a symbol table of the static or shared library file. That obviously implies a possibility of collision, and a common remedy is to have multiple or nested namespaces to separate them, but that doesn't fully fix this issue because such separation is not automatic. In Unison everything is first automatically named according to a hash of its implementation, and then can be aliased to other names. So the collision is impossible by default. Unison still has a type system, so I believe decoupling is still possible by multiple terms with the same type but different implementations (thus different hashes).
- mpweiher 3y ago
  Decoupling and abstraction not distinguishing. The implementation is supposed to be hidden and changeable independently of the interface and independently of clients. If I am coupled to the implementation, it's not an abstraction.
  - lifthrasiir 3y ago
    If that's your definition, I believe no one actually follows that definition because there are a lot of ways for abstractions to leak their implementation details, which might not be fully captured by interfaces. A good example is the performance. If you need a fast enough implementation with the same interface, you are not doing the abstraction in your definition because the "fast enough" implementation is an implicit coupling factor. More commonly, and in my opinion, more reasonably, any abstraction involves a trade-off. Some abstractions can be quite leaky but darn easy to use. Others may be less leaky but difficult to use (or misuse, depending on your view). There is no non-leaky abstraction here. Once you've chosen a trade-off and thus abstraction, you are still not entirely free from coupling for the aforementioned reason, but can enjoy some level of freedom thanks to the trade-off made. Unison is no different from other conventional languages in this sense.