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.
Thirded. I also like Grokking Deep Reinforcement Learning a lot. OReilly's Grokking series is 2 for 2 for me. For those who don't know, OReilly stopped selling DRM free PDFs directly, but they still sell DRM free PDFs through other sources like ebooks.com, which I appreciate.
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.
creating and transforming immutable data structures can be a big pain in some languages though, and that's it's own barrier. java is a good example but it's getting better with record types etc
Thanks for stating this so clearly. I am always confused why data flow frameworks, DSLs, or other syntactic sugar inevitably gets entangled with functional programming. Once more logic is in stateless functions and easy to test and compose (as you stated), one can gradually introduce layers, sugar, and abstraction (should the team choose)
On the contrary, that is exactly what those patterns are for, indeed it's the only legitimate justification for using them! If you can make your functions simple and stateless without using "fancy" patterns you should do so. The point of things like monads is to make it possible to do that with functions that do otherwise effectful things.
If your functions are "stateless" (by which I assume you mean they don't depend on or modify outside state), then they are pure functions so... that's exactly FP?
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.
I loved it when I was younger, but I had trouble recommending it more recently because its tone is adjacent to personally attacking people who like Java.
As I get older, I do tend to be more conciliatory, but I do think that even the people who like Java are perpetuating pain and struggle for others that will have to learn some lessons the hard way.
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.
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).
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”.
