On Wed, Mar 7, 2012 at 5:10 PM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > * introducing variables creates new indenting level, making code "creep to > the right"
Mitigated by breaking functions into sub-functions (which is good practice anyway). > * as code creeps to the right, you need to have a lot more newlines Then your code is too deeply nested and should be broken into sub-functions. That's standard best practice across all languages. > * The convention of using hyphens to separate words is hard to read I disagree. I find camelCase far harder to read than hyphenated-names. > * loop/recur is significantly less readable I don't think it's "significantly" less readable but I do agree that recur is a bit of a wart. > * cond branches are sometimes written with the test and the answer on the > same line, or when the test gets too long you have to write it with the test > and answer on subsequent lines; this inconsistent formatting can make it > hard to know in long blocks whether you are looking at the test or the > answer Don't write long blocks. Don't write complex conditions. Introduction more sub-functions. > * Interweavings of cond and let (a common pattern) end up ridiculously > indented and hard to read See above (and I don't agree it's a "common" pattern... perhaps an anti-pattern?). > * Decades worth of classic algorithms involving imperative manipulation of > arrays look significantly uglier in Clojure Yet many algorithms are significantly cleaner in a pure functional style... > * Expression-oriented syntax (along with the indenting cost of using let) > encourages people to pack far too much into one line rather than giving > names to intermediate results. Again, poor style. Break things into sub-functions. > * DSLs are supposed to bring customized readable notation to many tasks, but > by the time you include namespace prefixes and colons for all the keywords, > DSLs don't really look that good. Then those DSLs are not achieving their design goals. DSLs are a good use case for :use or :require/:refer. > * ... But when I read someone else's compact > higher-order stuff, it's usually a nightmare to try to interpret what it is > doing. Really? I find the compaction outweighs the effort involved - as long as the code is modular enough (see comments above). > * And the number 1 problem with all Lisps is that when you look at Lisp > code, it's a sea of sameness. Function applications, Macros, Control > constructs, bindings, data lookups, etc. all look exactly the same. I actually find that to be a plus - there's no distracting variance that artificially makes things "different" that don't need to be. Syntax is very subjective. It's really good to here your pro-Python thoughts tho'... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
