5 ms·

In Clojure, this data is represented by open maps instead. Is Clojure unique here? seems this is the norm for Javascript applications too, that are done mostly

• bambataa 4y ago
  It’s interesting though that JS never picked up a Rails alternative.
• Skinney 4y ago
  JS offers classes (or a similar construct pre-ES2015) and you can’t easily merge two objects (there’s the spread syntax, but that doesn’t bring along the prototype). So you’re mostly rewarded by keeping object «types» seperate
  • kaba0 4y ago
    I don’t know, JS is famously a lisp hidden under the C syntax.
    • lispm 4y ago
      and under the rest of the stuff Lisp does not have at its base, like an prototype object system.
• weavejester 4y ago
  Javascript objects have some differences to Clojure maps that make them harder to use in the same way. For example, you don't have to store functions in objects in Javascript, but the language design encourages it. This is problematic because we can't pull data out of an object without considering the functions that rely on it. Another issue is that keys are not unique. Two objects might contain an "id" key, for example, that identifies them in different ways. This is problematic if you want to arbitrarily merge objects together. Idiomatic Javascript might look like this: user.orders.total_cost() But if we want to program in the same way as Clojure, we'd perhaps be writing something more like: Orders.total_cost(user["user/orders"]); Not impossible, but certainly more inconvenient. The more you force rigid categorisations and behaviour on data, the harder it is to manipulate and organise in different ways. In-memory data is almost always ordered with a hierarchical structure, because that's what closed records gravitate toward. But if we take a look at databases, its rare to find any organised along strict hierarchical lines.
  • ithrow 4y ago
    Another issue is that keys are not unique. Two objects might contain an "id" key, for example, that identifies them in different ways. This is problematic if you want to arbitrarily merge objects together. Don't exactly understand this part, if one of your objects has its unique identifier as "userID" and the other as "invoiceID" you can merge them without conflict or what I'm missing? "id" is indeed use widely in blog examples/tutorials and even books but it's not the norm for enterprise data.
    • weavejester 4y ago
      If you ensure that all object keys are uniquely named, then merging objects wouldn't be a problem. But unless you use some sort of naming convention to enforce it, the more keys you have, the more likely it is for naming clashes to occur.
      • ithrow 4y ago
        Ok, so this normally tackle in Clojure using namespace keywords correct?
        • weavejester 4y ago
          Yep. And the advantage of namespaces over a naming convention is that they can be enforced by the compiler and shortened with aliases.