• (nodebb)

    If the application has not even run a full decade in production, how can it be considered legacy? Especially in finance, legacy is from the previous millennium, or older! Please don't ask how I know.

  • (nodebb) in reply to nerd4sale

    Please don't ask how I know.

    You exaggerate slightly, requiring it to be beyond a quarter-century before it's "legacy". All it requires is a few lava flow antipatterns in each source file, some "here be dragons" areas, and the occasional chunk of system where all the people who ever knew how it works have gone, been wented, or even passed on from this mortal coil.

    A decade is easily enough time for that.

  • (nodebb)

    Actually a good use case to try and utilize AI to write the unit tests (and check them of course) maybe

  • 516052 (unregistered) in reply to Steve_The_Cynic

    You forgot obsolete technology that isn't taught in schools any more and can't be found online.

  • (nodebb) in reply to 516052

    True enough, and you're quite right.

  • (nodebb)

    Well, it has code painting in it - that's always a bad sign.

  • Joe (unregistered) in reply to 516052

    It's funny you put it like that because for the most part, all the tech I learned on in school was older than anything I used after I graduated. That's fine, though, because you're not in school to learn the languages, you're there to learn the principles.

  • (nodebb) 
    var di = referenceData.FundDirectInvestments.Where(x => x.PositionId == lotId);
referenceData.FundDirectInvestments = di;

    I'm not well-versed in LINQ, but isn't it lazy? We're assigning a lazily evaluated IEnumerable to a property of some structure/class. This is bound to backfire.

  • (nodebb) in reply to Maia-Everett

    No, I think you getting confused how IEnumerable and IQueryable work.

    IEnumerable implement GetEnumerator(), which are enumerators based on state machines. So it's quite literally the opposite of lazy since you end up with the most eager (mostly) allocation free way to, well, enumerate collections.

    IQueryable are on other hand the opposite. If you are not using them outright as expression parsers (like f.e. building SQL strings to be send to databases etc.), they are composed as late as possible to optimize for best compute performance sacrificing eagerness.

    But both concept have nothing to do with lazy - an IQueryable can be in a worst case scenario end up being as eager as IEnumerable, especially we combined value type enumerators now commonly used by the compiler to avoid allocations of enumerators themselves due to how the chaining works.

  • (nodebb) in reply to MaxiTB

    IEnumerable can definitely be lazy: All it requires is that it do nothing until GetEnumerator() is called. And even the enumerator itself could be lazy, especially if its implementation assumes the underlying collection won't change but doesn't enforce it.

  • (nodebb) in reply to nerd4sale

    "or older"?!

  • Craig (unregistered) in reply to Medinoc

    Many Linq expressions are lazy. Any time you take an IEnumerable, you had best beware that it might be lazy. If that's a problem, then you need to call something like ToList() to force it to be realized.

Leave a comment on “Do a Lot to Do Nothing”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article