|
|
|
|
|
|
by bunderbunder
4201 days ago
|
|
|
> 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. |
|
|
That’s what Haskell does. The big scary M-word just gives you all the other features you end up wanting from your effect system once you have one. See my explanation here: http://programmers.stackexchange.com/questions/258011/altern...