Early or Lazily?

[audinue]

Early: Do everything we need at the begining.
E.g. Constructor, File Header.

Lazily: Do as it required.
E.g. Dynamic library, ...

Is it about style?
Is there any reason why do you do with that way?

It is not only in programming but also in our daily life.

[Mario F.]

The more I do it, the less I think there is any pattern to it.
And that goes for daily life too.

[audinue]

Is there some consideration, maybe?

Why we would load all plugins at startup, instead of load it when neccesary?

[jdragyn]

Depends on the needs. In a game where speed is important, having everything pre-loaded makes sense. In a spreadsheet program where most functions are rarely needed and the program is more likely to wait on the user for input, loading things only as they become necessary makes sense. If there is an equal case for either behavior then it would be a matter of style or design. The design of loading everything up front might be easier to accomplish or perhaps more extensible, or it might be the other way around.

Kind of like going to the supermarket to buy all of the ingredients for a recipe before you begin preparing the meal. Wouldn't make sense to go to the store, buy the flour, go home, measure it out into a bowl, go back to the store to buy the eggs, etc. In fact, in most things I can think of, as long as you have the room and you know you will need the "parts", doesn't make much sense to only get some and then have to go get the rest later.

[CornedBee]

Eager
+ Common work for multiple operations needs only be done once
+ No delays when result is actually accessed
- Long initial delay
- Need resources to store result

Lazy
+ Result doesn't need to be stored
+ No time is spent on unneeded operations
- Common work gets repeated
- Access time is longer

Take this list and evaluate each case on its own.

[abachler]

Well, the procedural programming method teaches to lay out the procedures first, then to work on the details once you have the basic problem defined. That said, I tend to do things as I need them, even though I'd probably be more efficient if I stuck with procedural.

[audinue]

Eager
+ Common work for multiple operations needs only be done once
+ No delays when result is actually accessed
- Long initial delay
- Need resources to store result

Lazy
+ Result doesn't need to be stored
+ No time is spent on unneeded operations
- Common work gets repeated
- Access time is longer

Eager
- The parameters should be known first

Lazy
+ The parameters are dynamic

So it's about access time, resource and ?common work??


In CornedBee context, do things lazily is much better than eagerly because "No time is spent on UNNEEDED operations" while "Common work gets repeated" can be solved using caches.

In what content?

[CornedBee]

Eager
- The parameters should be known first

True. But if the parameters are not known at the time of eager computation, then it's not even a choice. I was listing things that are up to the programmer's judgment.

In CornedBee context, do things lazily is much better than eagerly because "No time is spent on UNNEEDED operations" while "Common work gets repeated" can be solved using caches.

That's a gross overgeneralization. For example, there might be no unneeded operations in a particular case, or sufficiently few that it's not worth doing them lazily. (Lazy computation is often more complicated to implement.) Or the result of the common work could be so large that caching it is impractical. For example, let's assume we have a program that extracts information from large images and then does something with it. There are different kinds of information, and not every run needs everything. However, a part of every single information retrieval would be to transform the image into a different form (e.g. decompress). Because the image is very large, caching that different form might simply be impractical, especially if the memory is needed elsewhere. Or you might have enough memory to cache the image, but CPU cache locality still says it's better to do only one scan over the image data and incorporate the retrieved information into several computations at once. So it's better to compute all information at once, eagerly.

[Mario F.]

So it's about access time, resource and ?common work??

It seems to me you are trying to find a commonality and then extrapolate from there what's the best approach. But there is none. That's simply not the best way to evaluate the need for one over the other.

The approach has to be defined on a case by case basis. And even then, what might be a desirable approach in terms of performance or resource usage, may not be in terms of code maintainability or expansibility, or vice-versa, or in any other combination. Meaning, more often than not you are left with a paradigm you need to resolve. And the best option can often be described as "Pick your favorite poison".

[CornedBee]

It's also not black and white. Sometimes there are hybrid solutions. You could wait until the first access to one of a group of properties, and then compute them all at once. You could do part of the computation eagerly, and another part lazily.
Another consideration is this: usually, eager vs lazy is a question of implementation, which leaves the interface untouched. However, if the computation can fail, then in the eager case the initial calculation may fail, while for lazy implementations it's the result fetching that would fail, so you've got a change in the interface. This may sometimes force you to do a computation eagerly, because you cannot afford it failing once you've committed the the larger operation that needs the result.