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.
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.
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).
The term for this that I have come across is "stratified design" and goes back to the book Structure and Interpretation of Computer Programs by Abelson and Sussman. I have no idea why this approach isn't more well known (especially compared to typical "layered" design approaches) as the benefits are so great!
It was a general comment about frameworks. It’s possible to have a framework that includes all the “batteries” but has idioms and conventions that promote simplicity and maintenance.
Rails chose idioms and conventions that prioritize speed at the cost of complexity. The “included batteries” are not the problem.
Agree. There is a lot of value in the "easy, batteries included" solution which is why Rails gets so much love from the start-up community. The problem always seems to be that the same things that makes Rails easy to get started with (cough ActiveRecord cough) also make it easy to create foot-guns in the future (provided your start-up lasts long enough to get to that point).
Combining a Rails like framework that makes things easy with a language who's idioms prioritize simplicity seems like a great combination.