Seeing this is becoming such a popular thread I cannot help but chime
in with a little thought of my own: When you read code you are a human
compiler. Your brain needs to do the same job as a compiler to figure
out how the program works. The human compiler must identify structure
to be able to understand the code. The presentation of this structure
currently takes a number of mainstream forms:
1) semi-colon or newline delimited with optional nesting syntax
Works well with a sequence of instructions
2) visual blocks
Works well with PLC programming hooking inputs to outputs
3) Parenthesis
Works well with highly nested structures which are common in
higher order function use
4) white-space
Some people love it some hate it
These are all just different visualisations of structure, and all seem
to have their pros and cons at the moment, and all seem quite editor
dependent. For highly nested expressions, I do believe parenthesis are
good for a human compiler. And Rich's use of [] {} #{} solve the
'where is my data' problem very nicely. When you have highly nested
code to represent, dropping the top level parenthesis actually makes a
special case which can make the human compiler's task more difficult.
Parenthesis are explicit and easily handled by any text editor, and
those traits also make them explicit and transferable to the human
compiler.
Now this is not an argument for the status quo. It is just an
observation. I can't wait for a better representation of structure
which will take us to the next level of code editing/understanding.
For instance, wouldn't it be great if your IDE could render/edit code
in multiple views, allowing you to choose whichever view you liked? I
think code representation is quite a rich untapped field. Having said
that, possibly not for lack of trying, but more for lack of adoption.
Regards,
Tim.
--
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
