[handrous]

Maybe it's my bias but I took "clean code" not in the traditional sense, but to mean insisting on patterns perceived to be "pure" or "clean" even when their application harms performance or isn't a great fit for the host language (ahem, JavaScript and functional + immutable-datastructure programming) and makes it even easier for devs to footgun into bad performance while staying "pure".

[miltondts]

Yes, I should have typed "clean code". It's exactly what you and also what the parent said. It's about patterns/architectures/abstractions that we consider to be good/beautiful, but with very little regard for performance ("just throw more or better hardware at it, that is not our problem"). What really rubs the salt on the wound, is that the people that advocate them are quite loud, they seem to be growing in numbers and there is a massive lack of evidence for the supposed benefits, while the drawbacks are clear and easy to measure.

[inamiyar]

I don't think that's what they meant but it's a good point! I've seen embedded developers write some...truly terrifying code though.

[9wzYQbTYsAIc]

Function purity is a mathematical term with a clear definition and doesn’t deserve the double quotes which imply some vacuous definition or uncertainty.

Assuming you are referring to “pure”, in the context of functional programming and isolation of side effects.

[handrous]

Was what I was referring to actually ambiguous?

[9wzYQbTYsAIc]

What is ambiguous are the details about how you think that JavaScript and functional + immutable-datastructure programming is detrimental.

[handrous]

Oh, that's totally different from what you posted about before. OK.

Allow me to quote me, to clarify this part, then.

"when [they aren't] a great fit for the host language"

[9wzYQbTYsAIc]

What remains ambiguous is how it is not a great fit, in that specific case.