[dguaraglia]

UI development is one of the areas where object orientation really helps encapsulate the code in smaller chunks that are easy to map mentally to the graphical representation. I'm not sure Go's interfaces are as powerful of an abstraction.

Mind you, there might be an opportunity there for developing a different kind of UI paradigm where interface elements don't map to objects and actions are the main driver of screen updates. Anyone has any ideas of such a paradigm?

[mywittyname]

> UI development is one of the areas where object orientation really helps encapsulate the code in smaller chunks that are easy to map mentally to the graphical representation. I'm not sure Go's interfaces are as powerful of an abstraction.

See, I feel the opposite. I think UI programming is the worst application of OO-design because the data and actions of a UI are inherently decoupled.

You have have n data structures and m events that can be fired on a page and not every event is associated with every data structure. However, importantly, any event can be associated with any number of data structures, some of which may not even be conceived at the time of run/execution. OOP-doesn't work well in situations where you have functions that can operate on lots of disparate data-types.

When you apply OO principals to UI work, you end forcing a coupling that artificially limits what you can do with the data, requiring an increasing the levels of abstraction in order to provide baseline functionality. For example, when you have a button, it's an object, then if you want to apply a listener to it, you need to create a method on Button that accepts a listener. But to ensure that the method can actually interact with the passed object, you need to create an interface then ensure that every potential listener implements it. There is an entire world of classes that could be bound to the listener as-is, but those existing classes don't implement the correct interface since they didn't know of its existence. So the OOP-land solution is to write wrappers for every class you'd like to attach as a listener to the button.

In a functional world, you can attach any function that takes the appropriate number of arguments and be on your merry way. If the function doesn't fit that mold for whatever reason, you can cleanly wrap it in an anonymous function right where you're attaching it as a listener.

[millstone]

I don't like UI frameworks that work the way you describe either! I think this is mainly C++-legacy living on in Java and .NET, where they pay a penalty for being static. OO UI frameworks in dynamic languages can be structured very differently.

In Cocoa, you don't have these silly class-specific interfaces ("ButtonClickListener" or whatever). Instead it uses target/action: you give the button an object, and the method name to call on the object. So it does allow you to bind any member of that "world of classes" as-is.

Next, you allow the target to be dynamically determined. For example, say you have a button representing the Copy to Clipboard. You can set its target object to a sentinel representing the keyboard focus. And the button can even use reflection, and disable itself if the focus doesn't support Copy.

In a functional world, functions are opaque: the only thing you can ultimately do with a function is call it. But in an OO world, functions are closer to objects: they have names, they can be inspected, they can be dynamically dispatched. This is part of what makes OO languages excel at UIs.

[unscaled]

The functional programming approach to UI has more advantages than that. In my opinion, its greatest boon is that it allows you to cleanly separate UI logic, UI state and the actual data models, and reason about them in a straightforward way.

For instance, let's say you have a very simple Resize Image dialog, with two fields for desired height and width and a toggle button for keeping the current aspect ratio. Your data model is just (height : int, width : int), but you also have a UI state (keepAspect : bool). Changing the state could affect the actual data model, but it's not part of the final data you get out of the dialog.

In the traditional OOP paradigm, you'll just have to mix data and state, and once the UI gets more complex, you'll often end up with convoluted and bug-prone UpdateWidgets() methods being called after every user action or external data model update, and this function will both read and update the data model, the UI state and the UI view parameters. With the FP paradigm, you can just cleanly implement one function which receives the data model and state and creates the UI View, another function that enforces constraints on the data model and state and a few event handlers for specific user actions. This is essentially what you get nowadays with the more well-conceived workflows in ReactJS.

But while I really like this style of programming, I don't see how you can apply it to go. If there is one thing Go is worse at than OOP, that's FP. Go has no concept of pattern matching or currying, almost no inference, a cumbersome closure syntax and a pathetically weak type system without generics. Yeah, I know, JavaScript also falls short on most of the items in that list, but being dynamically-typed you can still easily write higher-order functions like map, filter, reduce and compose. Try to do that in Go without using reflection.

The Go authors and community seem to favor explicit for loops to functional constructs or comprehensions, and a little bit of copy-paste to function composition. That's OK, since Go's #1 goal is to be 'simple' in the sense that the code you see describes the imperative execution flow as accurately as possible, with very little magic happening behind the scenes. As far as UI design goes though, Go is probably even worse than C in some respects, since it doesn't even have these fancy macros that helped us brave UI programming back in the day. ;)

C# on the other hand, offers not only better-Java-than-Java OOP, but also an array of surprisingly competent functional features which keeps increasing with every language version. It had proper generics and closures since version 2.0 and covariance/contravariance and lambda syntax since version 4.0, expression bodies since version 6.0, pattern matching and tuples since version 7.0 and it will hopefully have proper record types and discriminated unions by version 8.0.