Even in OO languages, I'm almost exclusively in an FP style because that style focuses on minimizing redundant code (e.g., don't write loops write loop transfor

Even in OO languages, I'm almost exclusively in an FP style because that style focuses on minimizing redundant code (e.g., don't write loops write loop transformer functions), minimizing redundant top level functions (segmentations, hand-tuned stateful getter/setters, etc), and maximizing the opportunity for correctness. The last part is pretty important because properly testing software that talks to an external service is essentially impossible. Either you test in an integration setting where repeatable results are difficult to maintain, or you mock out your services and then you're testing your opinions against other opinions. Here's an example of how I push this style to typescript, heavily redacted to remove company-specific marks, names and strutures: (this code is simple by intention; we may have a jr dev on the team soon and an excessive number of generator abstractions could help with this process but would cause readability issues). function splitOrders(orders: e.OrderResult[]): {[key:string]: e.OrderResult[]} { return orders.reduce( (accum, borders) => { // I sure would love a better idiom for non-destructive map updates but // this isn't my primary language. Suggestions welcome! let next = {...accum}; next[borders.datatype] = (next[borders.datatype] || []).concat([borders]) return next }, {}) } export async function undoifyUserProcess(env: any, tolkien: client.tolkien, token: client.APIToken, spotData: IThingData): Promise<any> { const legendaryCustomer = await e.getCustomerById(env, spotData.customer_id); const orderResults = await e.findThingContractDetails(env, +spotData.spot_id); const workSchedule = splitOrders(orderResults); let btasks = scheduler.undoifyCustomerFromOrders( env, token, { key: legendaryCustomer.userKey }, workSchedule['newstyle'].map((wi => wi.bigId))); let ltasks = (workSchedule['legacy'] || []).map(async (workItem) => { // .. process elided but... const nodeKey, groupKey = ["things", "were", "removed"]; const customerEmail = legendaryCustomer.some_field + "removed work" // Factoring this out would have introduced a function with a bunch of parameters // or state that is only synthesized here, so we left it embedded & closed over. try { return await omg.undoifyUserWithTagGroup(env, tolkien, customerEmail, nodeKey, groupKey); } catch(e) { console.log(`... malformed database call your mom for help ...`); throw e; } }) try { const work: Promise<any>[] = [btasks, ...ltasks]; const result = await Promise.all(work); return await e.recordUndoifyingThing(env, +spotData.spot_id); } catch(e) { console.log(`...`); } } If a language can't express a decently abstract functional style, I do my best to avoid it. Still, I've had to write a bit of Golang at my current job despite its utter lack of descriptive capabilities. It's poignantly frustrating to deal with, but a good reminder of how bad life used to be for programmers.