mrkeen

@expr this is from 10 years ago https://youtu.be/7Zlp9rKHGD4

@dandi8 @JackbyDev Most of the criticism in the article talks about side-effects using a far stricter (and imo more useful) definition than Martin did.

I tend to agree, and would avoid both side-effects and writing code like Martin. However this book targets the mainstream, and afaik the mainstream hasn't yet accepted the new definition of side-effect.

Martin has since embraced FP more than the mainstream. So he's somehow both ahead of and behind the curve.

@agressivelyPassive if you routinely call indirections abstractions, then 'premature abstraction is the root of all evil' holds. If you separate the two concepts, you might think differently.

If my team's codebase had a business logic class that had a concrete dependency on an EntityBuilderFactory, I'd vomit a little, but I wouldn't delete it (can't piss off too many people all the time). But I would route around the damage by allowing the class to depend on the EBF *or* something else.

@agressivelyPassive moving from 'storing a user in postgres' to 'storing anything in postgres' is a step up in abstraction. Same with moving to 'storing a user somewhere' or moving to 'storing anything anywhere'.

Moving from 'storing an entity' to 'storing an entity via a FacadeBuilderFactory' is not a step up in abstraction, it's only an extra indirection.

@arendjr

1. abstraction != indirection. Abstraction allows you to do a deferred architecture: store this user "somehow". Indirection is just early architecture with more steps: MyUserDatabase class is coupled to one way of doing things - it's concrete, not abstract.

2. yet another article advocating 'pure functional' flavour, not a pure functional PL. Recommending purity in an impure language is like recommending memory safety in C. All the work is on the programmer.

@vitonsky this link is political. Do not click it! (You know, for security reasons)

@atzanteol @kogasa bullshit

@DmMacniel @vzq

> Given the nature of JS running only on a single thread.

No no, I think you found the language flaw.

@planet @clojure

"Traditionally, testing was often relegated to the final stages of development, just before the release"

I was going to dismiss this as another strawman - the same strawman that we've been whipping since Winston Royce, 1970.

But then I see:

"At the outset of a project, during the planning phase, testers should collaborate with developers and stakeholders to understand the requirements and define clear, testable acceptance criteria."

How did we get back to waterfall?

@Kecessa no you missed my point. You change the behaviour of the producer, not the consumer.

@Kecessa @grue knowing that the source will be published discourages bad actors from putting crap into the program in the first place.

And if they do it anyway, other people can come along and repackage it without the bad bits, like vscodium.

@errer @pro_grammer

I believe that the trick is not to show the developers the bill.

Let the developers all tell each other "it's cheap because you don't have to buy the servers; you only pay for what you use!"

Only managers see the real price.