| Yawn. I wish these talks would start at 303 not 101. (Sorry Paul Graham). I use development paradigms as so: Functional functions to handle the things they can do Procedural parts for those needing … procedures (more complex multi part workflow portions.) Class object wrappers for persistent encapsulation. All in the SAME lib include, by feature. Not everything gets a class. Most things need procedures. I don’t build code from Lincoln logs, I build code from coherent abstract entity relationships. You just can’t “create a document” in such systems. Checks, profile configuration fetching, templates, workflows requirements (what kind of document exactly?) etc. happen. Future proof with procedures. Make a composite embodiment if you need a class. I do criticize developers who do not separate out FUNCTIONAL behaviors into their own atomic function. Those who do not know separating concerns are not senior programmers. Write functional functions at the top of everything to achieve specific behavioral requirements. You never know who will want to parse_someFormat (yes, I just mixed case styles.) Or someFormat_parase. There will always be a different way. Asking why functional programming isn’t the norm is like asking why we aren’t all ninjas or monks. We have modernized and enjoy our leisure. |