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.

Related: https://www.destroyallsoftware.com/talks/boundaries

Also related: https://www.manning.com/books/grokking-simplicity

If you like these notes, you should read the (very good) book:

https://www.manning.com/books/grokking-simplicity

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.

I've always enjoyed this one: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

I always enjoyed this one:

https://aphyr.com/posts/353-rewriting-the-technical-intervie...

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).

I've found this essay to be a good shortcut to Lisp "enlightenment" without having to put in the effort of actually learning/using Lisp:

https://stopa.io/post/265

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!

https://medium.com/clean-code-development/stratified-design-...

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.

I like that quote, but it's the Rails idioms and conventions that make hairballs, not the fact that it includes a bunch of batteries.

Sounds like “create-react-app”. A bunch of libraries and configurations wrapped up in a “golden-path”.

Provides the “easy” for 95% of usecases and an “eject” button that unwraps everything and puts it under you control for the last 5%.

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.

Late to the party here, but what you propose is not being cheeky.

Rich Hickey (Clojure creator) himself has a similar, interesting, and compelling take on time and mutability [0]. This perspective is the underlying basis of Datomic.

[0] - https://youtu.be/ScEPu1cs4l0

Reading this makes me think of "stratified"[0] design, which I think is a good example of abstraction done right.

[0] - https://medium.com/clean-code-development/stratified-design-...

This is great!

I’m a big fan of Clojure and it’s REPL-driven workflow, but most of my day-to-day work is in JavaScript.

I’ve tried to use Quokka [0] in the past to recreate the REPL experience, and while it’s a good tool, it’s just not the same.

Really looking forward to trying this out!

[0] https://quokkajs.com/

I guess if the concern is around atomically committing to the DB and event stream at the same time, you could hang the event stream off the DB using change-data-capture to populate the events.

Ultimately, whenever you are pushing data between systems you can end up with inconsistencies which why it’s important to clearly define systems of record.

It is possibly that you could get inconsistencies between systems, but you mitigate that with durable event streams (e.g. Kafka) and by ensuring that each data entity in your enterprise has a system of record that can be used to resolve conflicts.

This is really not that different than using ETL jobs to move data about, but taking a streaming approach vs a batch approach.