Imagine you were trying to explain the temperature-conversion program's behavior in the simplest, clearest way possible. (That is, after all, what programmers fundamentally do: try to explain things to computers as simply and clearly as possible.) You'd probably say something like: "When the user changes the Celsius textbox, the computer changes the Fahrenheit textbox to the converted value." And indeed, that's the program most people would write:
celsiusTextbox.whenChanged do
fahrenheitTextbox.value = cToF(celsiusTextbox.value)
end
What you wouldn't say is something like: "The Fahrenheit textbox's value depends on whether the Fahrenheit textbox or the Celsius textbox was edited more recently. If the Fahrenheit textbox was edited more recently, its value is equal to the value the user entered into it most recently. If the Celsius textbox was edited more recently, the Fahrenheit textbox's value is equal to the converted value of the value the user entered into the Celsius textbox most recently." But that's the program you have to write in the "DCTP" approach proposed by the author.
I think this is true of a lot of UI programming: most people intuitively think about it in terms of "when X happens, do Y", so trying to cram it into another programming model is more trouble than it's worth.
Yeah. More power to people like this who are trying to make pure-functionalism more accessible and practical, but I have my doubts that contorting logic that's naturally stateful into a denotational paradigm will ever feel natural or intuitive. Human intuition is rooted in navigating the physical world, and imperative/cause-and-effect thinking is a very physical way of accomplishing things.
Won't your example trigger an infinite loop of celsius/fahrenheit conversions? Especially if the floating point value is slightly off.
I think your example is exactly why stuff like React won vs data-binding frameworks. With declarative programming, you just have a single source of truth that you change once (you can arbitrarily pick celsius or fahrenheit or even kelvin) and let the framework figure out what needs to be diff-ed in the derived views.
I'm not aware of any actual real-world GUI system where ".whenChanged do" is valid syntax, but just for the sake of argument, pretend that it only fires when the user changes the textbox. Coincidentally, this also happens to be how the "change" event works in JavaScript.
When working on GUIs that used callbacks like this, I’d have a method for setting the value of the second component which didn’t raise a ’changed’ event, or I’d turn off raising events for the second component before telling it to change then tell it to continue.
They weren’t beautiful, but both methods worked fine for the rare cases they proved necessary.
I think this is true of a lot of UI programming: most people intuitively think about it in terms of "when X happens, do Y", so trying to cram it into another programming model is more trouble than it's worth.