I appreciate that it's a bit frustrating to have someone vaguely identify an area of concern and clarification and actionable suggestions are much more valuable.
There's two things. One is that the data structure ontology[1] is difficult to internalize because of its complexity. When I write Clojure code, I consider the capabilities of the data structures being passed to the function. I think we have some implicit understanding of this early on. You expect the type of such and such to support seq-ing or deref-ing or something else. You're thinking in terms of capabilities and that's good. But if you want to be exacting, at some point you'll have to be able to point to an interface or several in the diagram and say, "yes, I really do expect something that conforms to IPersistentVector or IMeta or something else. In order to preserve backwards compatibility, this is more confusing than it needs to be. Moreover, at that point, you're not in Clojure-land anymore.
My second point is that at this step in the narrative, you're reading Java code and the illusion of 100 functions is broken. I ask myself, "Why, aren't Clojure data structures implemented in terms of protocols?" There's a perfectly good way of abstracting functionality that seems good enough for users, but not good enough for standard library implementers? It feels like the answer is, "We don't want to break Clojure1.x and we don't want to deal with the Python3 problem." Which is fair, admirable even, but it still leaves me left wanting. I think there's a simpler, more consistent Clojure hiding in there, waiting to be let out.
Apologies for the awkward way this reads; I simply wanted to get it out before lunch time.
I don't want this to sound hostile because I have a similar love/hate relationship to Clojure, I truly don't understand what you're arguing. Or, it seems like your issue is with lack of static types rather than an issue with the implementation? I've written a lot of Clojure and have an okay to pretty good understanding of the implementation, but it's just hardly ever relevant to the code I write, so I still don't totally understand what you're getting at exactly. Like, what's the actual problem here? Just that there's more Java "intrinsics" than pure Clojure code? I guess I do agree that Clojure is really just Java, and it would do better for people to think about it just as (really nice) syntax sugar over Java, but I guess I don't see that as a problem, but rather the absolute biggest strength of Clojrue.
I think he is arguing for more protocols than simply sequence. That is a sequence can be attributed fine-granular capabilities represented by protocols and that allows generic functions to be tailored towards those capabilities for improved performance.
I appreciate that it's a bit frustrating to have someone vaguely identify an area of concern and clarification and actionable suggestions are much more valuable.
There's two things. One is that the data structure ontology[1] is difficult to internalize because of its complexity. When I write Clojure code, I consider the capabilities of the data structures being passed to the function. I think we have some implicit understanding of this early on. You expect the type of such and such to support seq-ing or deref-ing or something else. You're thinking in terms of capabilities and that's good. But if you want to be exacting, at some point you'll have to be able to point to an interface or several in the diagram and say, "yes, I really do expect something that conforms to IPersistentVector or IMeta or something else. In order to preserve backwards compatibility, this is more confusing than it needs to be. Moreover, at that point, you're not in Clojure-land anymore.
My second point is that at this step in the narrative, you're reading Java code and the illusion of 100 functions is broken. I ask myself, "Why, aren't Clojure data structures implemented in terms of protocols?" There's a perfectly good way of abstracting functionality that seems good enough for users, but not good enough for standard library implementers? It feels like the answer is, "We don't want to break Clojure1.x and we don't want to deal with the Python3 problem." Which is fair, admirable even, but it still leaves me left wanting. I think there's a simpler, more consistent Clojure hiding in there, waiting to be let out.
Apologies for the awkward way this reads; I simply wanted to get it out before lunch time.
1. https://raw.githubusercontent.com/jafingerhut/clojure-classe...