4 ms·

I work with purely functional code in my day job and on several side projects, I'm not sure why you'd assume that. 20 years experience as a SE here but honestly

I work with purely functional code in my day job and on several side projects, I'm not sure why you'd assume that. 20 years experience as a SE here but honestly I don't think it adds or subtracts from my point, nor should you use it to prop up yours. I think asimplemind's advice is good advice but it is complementary to good and established testing strategy that is in widespread use across paradigms. I treat with deep suspicion the idea that a programming paradigm can subvert the fundamental principles of good testing.

necovek 3y ago
I don't doubt your experience at all: I just extremely rarely see functional approach applied to larger scale projects, and as we mostly work on legacy projects throughout our careers, I find it more likely that people have not seen it than otherwise. TBH, I've seen only two large projects completely following those patterns in my slightly shorter (than yours) 17 years of professional career (on top of a few years of active free software contribution): at my company, I am looking to introduce those patterns for new projects, but none of the existing stuff is doing that. Basically, you get extreme benefits once you follow the pattern fully: smaller codebases are relatively easier to keep that way, but the benefits are not as pronounced either. Anyway, my apologies if you see my previous message as a knock on your experience: I only consider myself lucky to have seen this applied on a complex project integrating many components (external and internal but from other teams) and with heavy development, and I really wish everybody gets to experience it once too :) Again, you possibly did, which is wonderful! It's also ok if that didn't make you as much of a fan as me :)