UI based on functional programming

Question

I am learning functional programming concepts now a days, and professionally I am an Asp.net developer. But asp.net makes you to change properties of objects too often in code behind. Functional programming is based on immutable objects. And apply this concept to change the value of a textbox will be very painful. Also in some event handlers like FormView's ItemInserted arguments are made available to the developer like KeepInInsertMode which developer can change to true/false, and in this case we are modifying the input arguments which is against the FP. Your thoughts frnds. Which is the correct way of UI handling in software world ? FP or OOPS.

Answer 1

Using the functional paradigm will lead to thinking in another way: you won't wonder "what will happen when this button is clicked", but rather: what is the new state of my application after a button click.

The 'new state' will be used by the presentation layer of your software to do some GUI work.

This will result in a "state -> event -> state" function, which is probably much more predictable than the OO "tell, don't ask" paradigm.

But it may also be more elaborate.

Answer 2

You ask for the "correct" way, but this is an engineering problem, not a mathematical problem. There are trade-offs, some form of taste comes into play, and it is unlikely that there is a one-size fits all perfect solution.

Also, just because asp.net does something in a certain way, does this mean that all OO frameworks have made the same design decisions. Have a look at Ruby on Rails, or the Smalltalk Seaside web framework for a different, but still OO approach. Even ASP.net MVC for example takes a somewhat different approach than vanilla ASP.net.

The same is true for FP frameworks for UI handling, with the additional caveat that they currently seem to be more experimental - i.e. I don't think all the design options have been explored as much as for OO frameworks. If you want to have a look, I recommend looking into functional reactive programming (mostly for interactive animations), Links (academic - has aspects in common with LINQ), or LiveLab's reactive framework - each emphasizing a different aspect of the problem.

There is much to learn here, the most important thing probably that there is no easy answer...