On Sun, Apr 28, 2019 at 10:46 AM Erik Assum <e...@assum.net> wrote: > I see, and acknowledge that eg the go-macro core.async is a wonderful > piece of work, and that it’s really cool that it could be done in a > library. But as an application programmer, I really don’t care if it’s a > macro or a language feature, and I couldn’t really see myself investing > that amount of time (nor would I have the skills to do so if I had the > time) to solve my concurrency problems in such a general manner. >
As an application developer, I'm betting the farm on the maintainability of the core language, and my options are constrained by its portability. Clojure would be a greater liability if core.async were an intrinsic feature, and (IMHO) la little less of one if STM and agents weren't. > 2) Pointers to blogs/articles/codebases which shows how applications > written either with extensive use of macros or by implementing an internal > DSL (and compiler) are significantly quicker to develop than their > brute-force alternatives. > I'm not sure data of this sort yields to analysis, though I do think *speed of development* is a suspicious yardstick. *Maintainability* is the unseemly underbelly of syntactic flexibility, and multiple layers of languages - each specified by implementation - is kryptonite for maintenance and collaboration. Take care, Moe -- 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.
