The Best Kind of True: Technically True

chromatic on 2008-08-11T22:04:36

If you program in a language with a extensible syntax, such as XML in XSLT or S-expressions in Common Lisp, Scheme, arc, etc., you never run into the problems we see above in Ruby.

Joseph Miklojcik, Growth, Syntax, Ruby 1.9, and That Bad Smell You Smell

That's technically true. Those syntaxes have other problems.

I agree that certain syntax decisions preclude certain growth possibilities (you may recall that I believe Python's whitespace problem is vertical, not horizontal), but S-expressions aren't magic pixie dust to sprinkle around your language to make it perfectly usable and free of all syntax-related problems. The standard argument is that you should use tools to handle all of the curvy or pointy symbols, but if you only ever interact with a programming language via tools, does the internal representation really matter? Why flatten your tree into a two-dimensional textual representation form when you can keep it around in a tree? Note that Smalltalk's not in Joseph's list; it might overshadow the other languages mentioned in terms of human friendliness and power.

How interesting that the sentence "Programs should be written for people to read, and only incidentally for machines to execute." doesn't follow SICP's own blessed (verb noun adjective) form.


Python

sigzero on 2008-08-11T23:41:34

What entry was the whitespace problem one? That sounds like an interesting slant that I haven't heard before.

Re:Python

chromatic on 2008-08-11T23:55:02

It was incidental to a discussion about symbol chunking in Perl 6:

I have trouble reading code without judicious vertical whitespace to separate paragraphs, so Python can be a chore. (Is this empty line the end of an block or just a paragraph within the block?)

See Re:DL$MT%DF@#(hhh.

Re:Python

jplindstrom on 2008-08-12T00:24:20

Hmmm, maybe I read your post first, but I've noticed that too. The little Python I've seen tend to have rather few blank lines to separate paragraphs of code. No rhythm. No flow.

Another counter to the "oooh, it's naturally easy to maintain".

Elisp code seem to be similar in regard to compactness, but probably for different reasons. Maybe I still haven't got the proper Lisp eye, but I find that slightly annoying.

Re:Python

chromatic on 2008-08-12T01:26:48

The little Python I've seen tend to have rather few blank lines to separate paragraphs of code.

That's exactly it.

Consider also that the human brain can count by view somewhere between five to seven items. You have to count by counting, if there are any more items. Compare indentation levels of two pieces of code separated by other lines of code or blank lines, especially if there are multiple indentation levels. It's not as easy as it might seem.

People will argue that you should write clear, concise code with short methods and as little nesting as possible. They're right, but that doesn't fix existing code, which may be nicely-indented but still difficult to read (whereas Perl::Tidy can fix almost all of the poorly-indented Perl code in the world.

If you have to have syntax, sometimes a little bit is an advantage.

verb noun adjective

mr_bean on 2008-08-12T05:51:57

verb noun adjective is Lisp function definition order?

Wikipedia's Word_order entry says: The overwhelming majority of the world's languages are either SVO or SOV, with a much smaller but still significant portion using VSO word order. The remaining three arrangements are exceptionally rare, with VOS being slightly more common than OVS and OSV being significantly more rare than two preceding ones.

Re:verb noun adjective

chromatic on 2008-08-12T06:33:28

You're right; "adjective" there is hand-waving, but Lisp does hew to VSO or VOS, depending on what you consider O or S.