OOP is not a philosophy. It is a way to glue data together. OOP is not separate from "procedural, functional, or declarative" programming, so it cannot possibly be "superior". I object to this becoming a religion or a we vs them.

Here is an example for clarity:

   x = new(Complex);
   set_real_part(x, 4);
   set_imag_part(x, 10);
   imag_part = get_imag_part(x);

   x = new(Complex);
   x->set_real_part(4);
   x->set_imag_part(10);
   imag_part = x->get_imag_part();

   x = new(Complex);
   x = x->set_real_part(4);
   x = x->set_imag_part(10);
   imag_part = x->get_imag_part();

philosophy: any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it"

It's not a science, it is a philosophical view point on how code should be arranged. So for me philosophy best fits the definition of the abstract concept that is a though process enshrined in code in particular adherence to a philosophically composed structure. I think philosophy fits the bill quite well.

I think you miss the point, functions and data existing outside of the class do not encapsulate the code base, so for you example, what if I write a widget for the UI and I want to give that widget to my friend, but not my project. In you example, I have to package up the functions, which may or may not reside with other functions, then you have to package up the data and again many or may not. Further the API does not float with the widget, so my friend has to design non conflicting entry points in his system to ensure that those functions are now available to the data for manipulation.

You are introducing external dependancies to a concept that by all intents and purposes can stand alone. OO promote reusability, because it boxes everything you need into a class and that is why when specifically applied to the UI where there is a lot of inherent reusability of items that deviate slightly it provides great application.

External dependancies are the nemesis of isolated components and your example shows why. You are looking outside the object at how it is used by the system. You are looking at how you call and use that class not how it relates to the overall system and keeps itself from becoming intertwined with it, all of the is dealt with inside the class not outside because it is inherent to OO.

Inheritance is a whole other aspect of why it is superior in this context and again it has to do with limiting external dependancies. Being able to extend a code base and suppress existing functionality while adding new novel functionality allow one to build on an existing item while still allowing the existing items to stand independent of that relationship. This allows my friend the ability to build upon my code base while leaving my code base intact. Therefore when I update my code base so long as I do not modify the existing contracts he can take upgrade in whole with no issue and no modification to his existing system. Now I know all this can be done with functional languages, the point is that it is simpler with OO and that is the crux of the issue.

I was thinking about this assertion on a walk, and I realized that this is just a matter of opinion. I can see it apply if you were programming with Tk. The same goes for Gtk, but when you add glide, the UI construction becomes declarative, and to be honest with you, I have preferred that style of UI construction over having to figure out my arrangements by pencil and paper. I would say that for 90% of your cases, you are not writing a truly dynamic UI that requires OOP to construct things.

When we talk about responding to events, we respond with functions. Presumably, we bury those functions in random placeholders, like a class dedicated to the callbacks, but they are still just functions that describe how to behave.

When I do web programming, I find myself with a mixed approach: HTML and CSS (declarative), javascript with jQuery (OOP and functional).

jQuery is an interesting use case of the blending of OOP and FP. Consider that when you make changes to objects in jQuery, a jQuery object is returned. Thus, you can chain things like this:

   jQuery(element).action().action().action();

In you example I have to package up the functions

Packaging issues really have little to do with OOP.

Yes. One way to do that is with a class. Another might be a package or namespace. Organization is a social issue. What you described is not a strength of OOP. In fact, the way most people I have seen do OOP is bulky because they are trying to mitigate this packaging issue: they try to put everything into one single class that is easy to share, as opposed to breaking it down to its logical parts with multiple classes.

Take a simple textarea widget, for example. Let's say you want to extend it to have a spell-checking feature. You extend the class to be TextAreaWithSpellChecking. The typical poorly designed resulting class will include the spell-checking code as opposed to implementing spell-checking in a separate module. It is easier to send the single class than multiple classes, right? Where should the spell-checking live? The answer is not about OOP or FP or other approaches/tools. It is about how you choose to abstract and break things apart.

The reason, everything is implemented on the jQuery tree and you have to chain stuff together. So long as you don't have to extend jQuery, it works well, but as soon as you have to provide a large code base with custom plugins to manage the code it becomes untenable quickly. I know I have done quite a few of them. Please don't take this as me knocking jQuery, I love it and use it extensively for quick solutions in which I am going to use existing functionality, but if you have a problem set that grows beyond whats in the box or that you can't find in a box. It becomes a massive time sink.

One of the major reasons is it does not have the concept of jQuery code existing outside of the jQuery tree you build on jQuery and not with jQuery while subtle it is a huge distinction. It is a monolithic philosophy, you have a hard dependency on jQuery while Dojo does require a dojo API to declare and construct objects they exist independent of the dojo tree.

It is not my intention of devolving this into a toolkit war, but I wanted to highlight that jQuery exemplifies my assertions, it is great for quick a dirty, there is nothing faster, but it does not provide the depth of a more OO centric framework for those of us that produce the building blocks that other people use.

I think this post sums up what I am trying to say better than I am communicating it: http://news.ycombinator.com/item?id=1805143

As well for sake of clarity, when I say UI development, I am not talking about putting text boxes on a page, grabbing the values and submitting them to a service. OO provides no advantage over functional in controller or work-flow logic. When I am talking about OO's advantage it is specific to new and novel UI components that are packaged for others to use off the shelf in controllers and work-flows, in fact I think OO is inferior for work-flow. Just wanted to ensure that I provided clarity on where I believe OO provides superior advantages over functional.

In fact, the way most people I have seen do OOP

sure people do bad OO they also do bad functional the reality is there are more hacks than there are good programmers. It is not an exclusive trademark of OO programmers. I will give you though bad OO is much harder to fix than bad functional. It's the nature of the beast. To quote uncle Ben "With great power comes great responsibility".

I realized that this is just a matter of opinion

You are correct it is my opinion, that is why when I posted my first comment I called it a philosophy. It is all opinion, some of it relies completely on how an individual developers mind works. But for me, and most of the developers that I know that have been doing UI for a long time the opinion is that OO provides a superior philosophy. If you find that something suits you better by all means use what works for you.