adamkl

The Mitsubishi Outlander PHEV is very good (and is available without a wait). It differs from some of the other PHEVs in that it is really an EV (with 2 electric motors) and uses the gas engine primarily as a generator. This means it drives like an EV (no transmission, no power bands, just smooth acceleration at all times). A downside is that when running on gas, it's not as efficient because of the losses of going from mechanical energy to electrical energy back to mechanical, but I regularly get 70-80km on a charge, so the engine only kicks in on long weekend trips.

That’s my point. FP can be as simple as that, and applied to any codebase. It’s all the extra stuff (which is good) that typically “defines” FP that scares people away, and keeps them from seeing the utility of a simple, pure function.

Perfect is the enemy of good. I’ll take any percentage of pure functions that I can get.

It’s true that people don’t do it, because of language conventions, but there is no barrier to entry when it comes to writing functions (or methods in these languages) that operate solely as transformations of inputs to outputs. You then orchestrate these “pure” functions with simpler side-effectful methods that handle the external dependencies (data fetching/writing etc).

There’s no pushback because of “strange” FP patterns, code looks just like normal imperative code, but the tricky logic can be isolated in pure functions. The push back is only because of the strong OOP conventions.

I’m my opinion, how to win would be to push for more logic in stateless functions, full stop.

This can be done in any language without introducing “foreign” FP patterns and instantly makes code easier to understand and test.

Agree, but it helps to remember that it’s a product of its time. Feels like we’re overdue for a similar piece poking fun at Node/JavaScript and all of its foibles.

Much higher level than a System Analyst. Enterprise Architects often work directly with the CIO/CTO to shape an organization’s long term technology strategy (i.e. 5+ year time horizons).

The idea being, they are supposed to be “architecting the enterprise”.

Enterprise Architecture is a very different discipline from software development (and even solution architecture), and are usually found in non-tech organizations (i.e. banks, insurance companies, etc).

EA is focussed on evaluating the business processes and technical solutions that make up the operations of a large scale organization. They try to identify and remove redundancy (e.g. multiple billing systems) and ensure the solutions in place (custom internal, or vendor purchases) are fit-for-purpose from technical, business, and strategic standpoints.

It’s very far removed from the practice of software development (since the correct solution, from an EA standpoint, might just be to stitch together a handful of vendor systems and do away with custom development completely).