(oops, don't you hate it with the mail client silently assumes you only want to reply to the sender?) On Fri, 9 Apr 2021 at 11:51, Lennart Sorensen <lsorense@csclub.uwaterloo.ca <mailto:lsorense@csclub.uwaterloo.ca>> wrote: But using a loop means you are telling the system how to do things, rather than telling it what you want done and letting it (usually) do a better job at the how. I'd agree if I were doing something like wanting the sum of the values of a list. /list.sum()/ is going to be many times more efficient than an accumulator loop on a system that's got any level of vectorization. Chris Tyler's talk on AARCH64 optimization in gcc a few years back showed that the code isn't anything like my mental model (somewhere around a Z80, with faulty memory management) expected. After all with a loop you are controlling the execution order of the processing. If done right you usually shouldn't need to care. But in document processing, you really really /really/ want the output to come out in the same order as the input. Which is why functional languages seemed a strange choice for document transformation. The absence of side-effects can be handy in document processing, but being in the right order is usually what publishing houses get paid the big bucks to do. I've had to process utility time series power generation data in XSLT. That was horrid. Order matters a lot there, too. But yes functional languages require a different philosophy. Functional languages are not for people that want to micromanage the computer. Call me old-fashioned, but I want my computers to do what I tell them. I don't want exceptions, I want results or error messages to explain why. I know there are many processes running that do things I'll never understand, but they must prove themselves useful to me or get out of my way. cheers, Stewart