
Tell Don't Ask (1997) - tpaschalis
https://pragprog.com/articles/tell-dont-ask
======
mgummelt
The author is incorrectly using the term "declarative" when he's really
describing "imperative". Stateful OOP is in no way declarative.

It's also unclear what the thesis is. He says to not ask objects about their
state, then later advocates for CQRS, which does exactly that.

~~~
culturedsystems
Of course, imperative programming is just the Church encoding of declarative
programming.

~~~
mgummelt
Well, no. The lambda calculus isn't imperative.

------
phkahler
This seems to fit a couple other things. Functions to "get device
capabilities" from device drivers are misguided to some extent. Also, web
sites checking capabilities of your browser should be considered an anti-
pattern.

~~~
uryga
what approaches do you think would be better? do you mean something along the
lines of "ask for forgiveness, not permission"?

------
ryanthedev
I stopped at his argument about getting a string with the contents of RED.

That's why you have a variable. Which is a specific named property of an
object.

var lastName ="RED"

Umm. It's his last name?

~~~
majormajor
and then you have a function like: `def printGreeting(lastName, firstName)`

and you call it like `printGreeting(firstName, lastName)`

and whoops, the compiler won't tell you you did something wrong. Maybe your
editor will, if it shows handy little param name stuff next to the args in
your call, but a github PR won't.

So someone ordering the arguments in a method in a non-intuitive way makes
your variable name much less useful once you have to pass it around.

Sure, this is a trivial example ("why did you order the params in such a dumb
order!?!?") but that's what is meant by variables not knowing much about what
they are. It's a String. That doesn't tell us much, and doesn't tell the
compiler or interpreter much about which functions expect it in what places.

