|
|
|
|
|
|
by evincarofautumn
4202 days ago
|
|
|
A familiar example is “goto” versus structured programming. “goto” is supremely expressive—conditional jumps are sufficient to express all of the usual structured programming constructs. But sacrificing “goto” enables much more powerful reasoning about programs because it restricts the shape of the control flow graph to common patterns: “while”, “do…while”, “for”. One of the core features of functional programming is “recursion schemes”, that is, generalising patterns of data flow. While “goto” lets you manipulate control flow arbitrarily, it turns out that you don’t usually want arbitrary control flow—and the same is true for data, so rather than “for” loops, it’s often easier to think in terms of the common patterns: “map”, “reduce”, “filter”. |
|
|
It is. My lament there is that, at least in my experience, optimizers haven't caught up in this department. So while I invariably start with the higher-order operations, all too often the profiler subsequently informs me that I need to replace that code with a for loop.
I suspect that side effects are the culprit there: In a language without referential transparency, the optimizer's very limited in what kinds of reasoning it can make about a function. I'm not quite ready to give up side effects just yet, though. I wish I could work in a language that only allows them in functions that explicitly declare that they want to use them, though.