B) I said I hate the pattern word, let me say it bluntly, elaborate > patterns have the unique > property of fossilizing a language as soon as you start to modify the > language > to support them. Especially complex ones. > It kills evolution the day you need to meet other needs, > you have crippled your implementation with patterns and it no longer > can be > turned around to accomodate future needs. > It's the same with a lot of frameworks, they to go through some heavy > twists > after a number of years just to,keep up. >
C) patterns do not improve readability, they just narrow the readers and > writers > options. Readability is more a factor of your abstraction choices and > the cleanleaness of your implementation which has little to do with > rigid language implemented patterns. A bad choice of pattern will > always > yield obscure/unmaintanable code. > > > I think our difference is minor, what you called "bolts and nuts", I call them "patterns". Our difference is what kind of bolts and nuts should be included in the language. You may argue my proposal is not a good pattern (or bolts/nuts), but I mean, are you sure you don't like any patterns? Is multi-function a pattern? Is FP a kind of pattern? Is namespace a kind of pattern? I truely believe only assembly does not give you any patterns (but maybe the register name shows some patterns, so better just use 0s and 1s). -- 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
