You end up having to fight the compiler in some situations just to get code to compile. But that isn't an argument about succinctness or expressiveness, so now I'm starting to rethink it.
Update: After reading the recent thread on hygiene (http://arclanguage.org/item?id=12700) I'm reminded that one of the themes of arc was to assume you're building for smart programmers, and to avoid constraints as far as possible. Hygiene is a constraint. Ordering definitions is a constraint. Better to replace them with conventions.
Ah, but that still doesn't address the question of why ordering is so much better and whether or not some of those reasons can be reified into useful code. Yes, many things can be typed in repetitively by intelligent people who can remember design patterns. But that doesn't prevent those same intelligent people from wanting utilities and macros to simplify the process.
So far none of the macros and higher-order functions that constitute complete abstractions require you to code that way, they just allow you to if you wish. And help you by making the computer do a lot of the heavy lifting.
It's possible that this abstraction is just that - too abstract - but if so I'd still like to know why.
Hmm, are there any kinds of constraints that help you write less code?
I'm finding this to be a useful line of inquiry; it's also starting to get too abstract. Are you still thinking about sequential definition, or about design patterns in general?
Why ordering is better: sequential definition helps localize errors. So where does this answer lead?
