| > everyone knows exactly what every line is doing At least, until you start to define functions, whereby a line now says "something happens according to a definition elsewhere which is just invoked here". Oh wait, that's also what a piece of syntax or macro also says, pretty much. > I hope you can see the UI advantage to functional programming in an environment of controlled evaluation complexity What I do know is that big programs written in C can be pretty difficult to understand, even though most of their bulk hardly uses much more than what's covered by the operator precedence table on page 53 of Kernighan and Ritchie, 2nd ed. A lot of that has to do with the fact that foo_bar(ptr_widget, 42, gadget_struct) can mean anything whatsoever, even though it isn't a special operator or macro call. The small assurance that three word-sized chunks are passed somewhere by value doesn't actually buy a whole lot of understanding. (Brain* * * * * * has a nice, small, inextensible set of operators. Does it help?) The dictionary you have to comprehend is not that of the language, but of the language, plus that of the code base written in it. What good is it if some language has 20 entities rather than 30, if the code base you're grappling with has 10,000. |
Macros aren't functions. A function call is one thing. A macro can expand to arbitrary code. This code may contain function calls or other symbols.
Before you can even interpret these symbols, you have to expand the macros in your head. This is two steps, rather than one. Expanding is not tracing. This extra step is why whoever is reading your code is so easily tempted to give up and writes it again herself, with her own macro language.
I was not comparing FP to C. If you look at actual Hoon code, it's pretty comparable in size to other functional languages, and also in clarity once you learn to read it. Obviously C is much fatter and harder to understand (and has macros, of course).