James Reeves <ja...@booleanknot.com> writes: >> Yes, which is what I have done, of course. Now it won't work in any IDE >> which looks for the docstring as :doc metadata. It is totally >> unextensible. I do not think that this is good. >> > > Clojure prefers "simple" solutions over "easy" solutions.
A nice aphorism sometimes, but content free in this case, I think. > Unrestricted polymorphism and universal access would make solving this > problem easier, but they also create more complexity. > > Or to put it another way, rather than trying to shoehorn a solution into a > system that wasn't built for it, we should design a new system around the > desired solution. So, there is this tourist, and he asks a local, "how do I get into town". "Hmmm," says the local, "if I want to get into town, I wouldn't start from here". Software engineering is a compromise, and designing a new system is a pain, especially if multiple people have to update to it. I think Clojure's doc string support is weak. Part of the reason for this, is because it is not extensible. The main reason that it is not extensible is that, in Clojure, once you have decided that something is a value, you are stuck. Don't care about my use-case? That's fine. Have a look at Andy Fingerhuts thalia which helps to fix Clojure's poor documentation. https://github.com/jafingerhut/thalia Same problem -- all has to be done up front, which is ugly and nasty. As a result, I don't use thalia, which is a shame. >> The response may be computed, but once it's sent to the client it's >> > immutable data. >> >> Well, that's the point, you cannot tell. So, for example, I can provide >> a website implemented over a relational database. Or I can serialize it >> out as static files. Or I can add a caching layer which serializes >> lazily, and redoes every hour. >> > > Yes, and so can a function. Clojure doesn't say, "you shouldn't compute", > it says, "you should separate computations and data". Which is nice and simple, yes. And has negative consequences in terms of extensibility. I understand if you are happy with this compromise. But it is a compromise. > The point I was trying to make was that computed values (such as those > produced by a web server) do not necessarily imply UAP. > > I don't disagree that UAP has some benefits, but it comes with a huge > number of tradeoffs. Given that the problem it tries to solve is, in my > experience at least, exceeding rare, it really doesn't seem worth the > additional complexity. Well, the question is, where does this additional complexity come from. In Java, it results in enormous quantities of boilerplate get/set methods. In Scala, these are autocoded away. In Clojure, I don't see an easy solution. Not going to stop me using the language, but it's a weak spot. Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
