Perhaps you mean “the functional side has done away with loops” or “made do with recursion”?
I still remember that as a newbie I was confused about while loops but not recursion. I thought that the while <condition> was being *continuously* monitored during the entire execution of the while <body> and not just at the *start* of the loop! Until I saw it explained in terms of recursion. Recursion is just redoing. Why didn’t they just use *it* instead of adding a confusing construct? They gave loops and never got around to giving us TCO! Even now I find it a bit surprising that many languages allow you to construct collections of data items all at once but don’t provide useful operations on entire collections - you have deal with each item one at a time. Operations such as map, scan, filter, reduce, iterate, group, sort, cross and dot products etc, if built in the language, provide many opportunities for optimization & using concurrency, and you don’t have to worry about getting boundary conditions wrong or off by one errors. These operations compose well and are quite compact (which may make the initial learning steeper but later become very useful). Prof. Alan Perlis wrote a couple of essays relevant to this which I find inspiring: In Praise of APL: A Language for Lyrical Programming http://www.jsoftware.com/papers/perlis77.htm Every time I read this essay I discover something new! Just now I wrote and deleted “The structured programming movement of 60s and 70s has a lot to answer for!” in the context of loops and no TCO. Compared my flippant remark he makes the same case more persuasively. He argues that structured programming is less relevant if you can express your algorithm in a few lines instead of a few pages. Implicitly, a language should make it easy to express algorithms this way. He praises APL but I think we can read it as a praise of a certain style of programming. Also: APL is more French than English http://www.jsoftware.com/papers/perlis78.htm I am less concerned about surface syntax issues such as a lack of a while statement, when the fact is, Go is not very good at providing features to build the above kind of functions easily or efficiently. > On May 3, 2018, at 8:06 AM, Jesper Louis Andersen > <jesper.louis.ander...@gmail.com> wrote: > > In practice, convenience has it that people often add additional syntax, > albeit it seems to me that imperative languages generally have opted on the > side of having multiple loop constructs, whereas the functional side has done > away with recursion, more or less. This is mostly a stylistic argument as > things blend in the end: most modern compilers use SSA, which can be seen as > a variant of implementing all loops as recursion. And vice versa, recursion > is often implemented via tail call optimization: which implements a loop as a > goto. It is just dependent on the glasses you wear, really. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
