5 ms·

"all functions are pure, there is no data mutation, and entities are represented by data structures instead of objects." God i love to see this

recursive 2y ago
In javascript, what data structure can you implement without objects? Pretty much nothing. Even arrays are objects.
- metaxy2 2y ago
  They're using objects, including arrays [1], so I think they would have been more precise to say that they're using objects and arrays as simple data structures rather than using OO features like inheritance and mutation. [1] https://github.com/tonaljs/tonal/blob/main/packages/chord/index.ts https://github.com/tonaljs/tonal/blob/main/packages/chord/in...
  - pcthrowaway 2y ago
    This is just semantics then. If you're implementing a linked list or a tree without a class (or at the very least a function that behaves like a class), it's going to be awkward and clumsy. Data-structures beyond what the standard lib gives you (string and array) are the main reason the addition of classes to JS was so helpful.
    - eitacaraleo 2y ago
      Uh… what? It’s quite the opposite; why would you need a class for linked lists and trees?
      - hasty_pudding 2y ago
        You definitely need generic node objects to define the nodes. You could have a completely stateless class/object that would manipulate those nodes and add them and remove them from the data structure.
        metaxy2 2y ago
        Well, in principle you could have the node objects be created with an object literal in an outside builder function, and the manipulation also be done by outside functions. That's how it's done in languages without OOP. The question is how far are you willing to go to avoid doing anything that looks like OOP.
        hasty_pudding 2y ago
        Very far
      - recursive 2y ago
        To provide an easy place to find the behaviors that are included with those data structures.
    - kamov 2y ago
      This isn't quite right, linked lists and trees in functional languages can be represented extremely succintly, i.e. data List a = Nil | Node a (List a) data Tree a = Leaf a | Node (Tree a) (Tree a) there is nothing stopping you from writing something like this in JS const list = { kind: 'node', val: 3, next: { kind: 'nil' } }; And then using a switch case to navigate the list/tree matching on the kind field.
      - recursive 2y ago
        Absolutely. The navigation behaviors will have to be in functions though. And from an application code developer's perspective, the connection between these objects and functions may not be obvious. If only there were some way to associate behavior with state.
        lioeters 2y ago
        The whole point of the top comment is that they appreciate how this library chose not to associate behavior with state, and instead organized things as functions and data structures. With the latter approach, the user is not limited to the bahaviors that the library author wrote. The data (not state) can be used freely. Similarly, the functions are not tied to any particular state - the data can come from anywhere, as long as it has the right shape.
- hasty_pudding 2y ago
  What they mean is functions and data are separate, emulating a more functional paradigm and less mutable state. The functions are kept pure and the data is kept pure. As opposed to an object oriented programming style in which data and functions share the same object and create bug ridden state machines thats not as easy to reason about. Some further explanation about this: https://www.goodreads.com/quotes/702062-immutable-objects-are-simple-they-can-only-be-in-one https://www.goodreads.com/quotes/702062-immutable-objects-ar... a semi-nuanced discussion: https://www.reddit.com/r/scala/comments/ejwsp1/is_mutability_really_that_bad/ https://www.reddit.com/r/scala/comments/ejwsp1/is_mutability... you can just Google mutable state to find more info. separating your data structures and functions in many cases will make your code cleaner and more bug free.
  - recursive 2y ago
    I'm well aware of the pros and cons of mutability. I object (hah!) to this novel new use of the word "object". The concept is well defined by the ECMAScript spec. Your first link's first sentence's first two words are "Immutable objects". No problem there. It doesn't conflate objects with mutability.
    - hasty_pudding 2y ago
      you know how unsufferable it is when people bog a conversation down with semantics instead of ideas. the point is obvious. Being that every single language on Earth uses objects for non-primitive data structures that should be inferrable to a reasonable person. a data structure in that context is clearly an ordered grouping of objects versus an unordered/loose grouping of objects.
      - recursive 2y ago
        I mean some languages don't. I have ideas but I don't think I'm getting them through. Most of the problems functional proselytizers have with objects come from inheritance and mutability. Instance methods from classes don't seem to conflict with any of the functional tenets. As for mutability, I think it's good sometimes. Dates should have been immutable, but Maps are a good fit for mutation. Immutable maps might make sense too sometimes. But I find it difficult to communicate about any of this when fundamental terminology is used in novel ways.
- hasty_pudding 2y ago
  What languages on Earth implement non-primitive data structures without objects? I guess maybe low level c and assembly where you implement everything as bits in physical memory?
  - recursive 2y ago
    It's mostly a question of what the language considers to be an object. There's often a stack-/heap-allocated dichotomy. Some languages consider stack-allocated structs not to be objects. They have no reference identity. Assignment has copy semantics. C# is one such language.

recursive 2y ago

In javascript, what data structure can you implement without objects? Pretty much nothing. Even arrays are objects.

metaxy2 2y ago
They're using objects, including arrays [1], so I think they would have been more precise to say that they're using objects and arrays as simple data structures rather than using OO features like inheritance and mutation. [1] https://github.com/tonaljs/tonal/blob/main/packages/chord/index.ts https://github.com/tonaljs/tonal/blob/main/packages/chord/in...
- pcthrowaway 2y ago
  This is just semantics then. If you're implementing a linked list or a tree without a class (or at the very least a function that behaves like a class), it's going to be awkward and clumsy. Data-structures beyond what the standard lib gives you (string and array) are the main reason the addition of classes to JS was so helpful.
  - eitacaraleo 2y ago
    Uh… what? It’s quite the opposite; why would you need a class for linked lists and trees?
    - hasty_pudding 2y ago
      You definitely need generic node objects to define the nodes. You could have a completely stateless class/object that would manipulate those nodes and add them and remove them from the data structure.
      - metaxy2 2y ago
        Well, in principle you could have the node objects be created with an object literal in an outside builder function, and the manipulation also be done by outside functions. That's how it's done in languages without OOP. The question is how far are you willing to go to avoid doing anything that looks like OOP.
        hasty_pudding 2y ago
        Very far
    - recursive 2y ago
      To provide an easy place to find the behaviors that are included with those data structures.
  - kamov 2y ago
    This isn't quite right, linked lists and trees in functional languages can be represented extremely succintly, i.e. data List a = Nil | Node a (List a) data Tree a = Leaf a | Node (Tree a) (Tree a) there is nothing stopping you from writing something like this in JS const list = { kind: 'node', val: 3, next: { kind: 'nil' } }; And then using a switch case to navigate the list/tree matching on the kind field.
    - recursive 2y ago
      Absolutely. The navigation behaviors will have to be in functions though. And from an application code developer's perspective, the connection between these objects and functions may not be obvious. If only there were some way to associate behavior with state.
      - lioeters 2y ago
        The whole point of the top comment is that they appreciate how this library chose not to associate behavior with state, and instead organized things as functions and data structures. With the latter approach, the user is not limited to the bahaviors that the library author wrote. The data (not state) can be used freely. Similarly, the functions are not tied to any particular state - the data can come from anywhere, as long as it has the right shape.
hasty_pudding 2y ago
What they mean is functions and data are separate, emulating a more functional paradigm and less mutable state. The functions are kept pure and the data is kept pure. As opposed to an object oriented programming style in which data and functions share the same object and create bug ridden state machines thats not as easy to reason about. Some further explanation about this: https://www.goodreads.com/quotes/702062-immutable-objects-are-simple-they-can-only-be-in-one https://www.goodreads.com/quotes/702062-immutable-objects-ar... a semi-nuanced discussion: https://www.reddit.com/r/scala/comments/ejwsp1/is_mutability_really_that_bad/ https://www.reddit.com/r/scala/comments/ejwsp1/is_mutability... you can just Google mutable state to find more info. separating your data structures and functions in many cases will make your code cleaner and more bug free.
- recursive 2y ago
  I'm well aware of the pros and cons of mutability. I object (hah!) to this novel new use of the word "object". The concept is well defined by the ECMAScript spec. Your first link's first sentence's first two words are "Immutable objects". No problem there. It doesn't conflate objects with mutability.
  - hasty_pudding 2y ago
    you know how unsufferable it is when people bog a conversation down with semantics instead of ideas. the point is obvious. Being that every single language on Earth uses objects for non-primitive data structures that should be inferrable to a reasonable person. a data structure in that context is clearly an ordered grouping of objects versus an unordered/loose grouping of objects.
    - recursive 2y ago
      I mean some languages don't. I have ideas but I don't think I'm getting them through. Most of the problems functional proselytizers have with objects come from inheritance and mutability. Instance methods from classes don't seem to conflict with any of the functional tenets. As for mutability, I think it's good sometimes. Dates should have been immutable, but Maps are a good fit for mutation. Immutable maps might make sense too sometimes. But I find it difficult to communicate about any of this when fundamental terminology is used in novel ways.
hasty_pudding 2y ago
What languages on Earth implement non-primitive data structures without objects? I guess maybe low level c and assembly where you implement everything as bits in physical memory?
- recursive 2y ago
  It's mostly a question of what the language considers to be an object. There's often a stack-/heap-allocated dichotomy. Some languages consider stack-allocated structs not to be objects. They have no reference identity. Assignment has copy semantics. C# is one such language.