You should probably both share gists of real code you're talking about, shouldn't you ?
Your discussion made me think that editors may help further in this area, without having to change the syntax. Currently, the editors only try to give some "hints" by playing with colors, but there are some other ideas that could be followed: - playing with contrast by also using the ability to change the fonts - playing with contrast by slowly decreasing the font's opacity as the code gets deeper (but where the cursor is, this should probably go away to ensure good visibility) => could help see the overall structure without seeing to much of the details? - playing with "proximity" by adjusting the line sizes. For example, there could be extra space around the "true" and "false" clauses of an if, there could be extra space around "condition/then" clauses of a cond, etc. - playing with the background color of blocks, potentially minimizing (and to some extend -in a modal structural editor- almost removing from sight) the parens - since it's not the same thing to "write/edit" and to "read" code, there could be the possibility to have a "read" mode where the editor could represent totally differently the source code (think it could even present it in some sort of prefix-notation :-) ) 2012/3/8 Sean Corfield <seancorfi...@gmail.com> > On Thu, Mar 8, 2012 at 2:54 AM, Mark Engelberg <mark.engelb...@gmail.com> > wrote: > > Looking back at my initial email, I can see that it probably came across > as > > a bit of a rant, and probably not as constructive a response as I had > > intended it to be. > > No, I thought it was an interesting set of observations but, like Stu, > I disagree on many points. As noted, syntax is definitely subjective. > Ruby makes my skin crawl but I can't really put my finger on why (it > feels like punctuation has been used for cryptic semantics - but I > don't react to some other languages against which I could level that > criticism). If I was doing heavy numeric computations, I'd probably > find the prefix syntax in Lisp annoying, so I suspect your problem > domain has a lot to do with your feelings about a language too. > > > I understand where Sean is coming from with his > > point-by-point. > > Most of my comments would be true of code in other languages (and > Scala came to mind, specifically, as I was suggesting breaking code > into smaller units to aid readability). I'm interested in hearing more > about the sort of functions that begin "by unpacking and computing a > large number of values that are all important for subsequent > computations". I'm not seeing this in my code so I assume we're > working on very different problem domains - could you elaborate? > -- > 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 > -- 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
