No, scala was clearly sticking to the everything is an object model.
clojure, ocaml, and haskell combined have maybe 1% of the market share. This supports his point.
Javascript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to javascript and are even pushing to add it to the standard.
I think is point holds. Some people have certainly questioned OO, pg is one of them, but they are clearly in the minority.
"JavaScript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to JavaScript and are even pushing to add it to the standard."
Be that as it may, OO lends itself very well to UI programming. widget, containers et al. lend thenselves very well to becoming encapsulated black boxes that notify the larger system through defined event contracts to publish out changes.
I believe that the problem has historically been between the UI and business logic. UI is a natural fit for OO where as business logic is a good candidate for procedural services based workflow that expose their functionality to the UI.
The problem is alot of developers try to solution the entire problem domain with one tool a.k.a the gold hammer.
This is why I think Ajax and JavaScript coupled with toolkits like Dojo are a huge step forward they allow the UI developers to work with in the best toolthat fits their problem domain while the service developers can do the same with the best tools for that problem domain.
The nice part is that their is a hard contract between the two and you cannot cross the barrier with the other tool. As their are built on messaging JSON or XML contracts to and fro.
People have to stop conflating the concept of OOP with that of encapsulation. No one is arguing the value of encapsulated black boxes. Any good paradigm will have that concept! The question is, do you want OO-style black boxes, or functional style black boxes (ML-style modules or Haskell-style type classes)?
Functional style encapsulation is a really good contender for handling UIs, especially given the ease of use of first-class functions, and especially especially reactive programming frameworks.
The inheritance mode is natural to OO for the UI. It flows quite well and helps provide reuse of components by slighly mutating that component into new functionality. Lets take select box --> FilteringSelectBox, I reuse the select box and extend it by adding a method that captures user input runs a match on the internal data store and overrides the display to only display results that are within the partial entered text. With the addition of a method and the overriding of a display method I have created novel functionality. This is harder to reproduce in a purely procedural language.
I have been around for a while and used about all of them and I have never seen the efficiency that OO provides for UI in a non OO language.
For instance in OO I can encapsulate all functionality related to a pop up with that pop-up, so it can have a member variable of content, while also providing a show and hide method. The strong point of OO is that is is easy to encapsulate the data with the functionality (In most cases this is a bad thing but in UI, you are at the end of the rode the functionality and the data start to merge to present it to a human) and scope it so to decide the scope of that dialog, I can create and instance of that dialog and call show on that dialog, it will show that instance of the dialog.
Whereas, if I want that dialog to be a singleton and only share the reference among functionality to guarantee that there is only one true dialog, I can also do that.
Representing a black box like that in functional languages can be done, I am not saying that it cannot. I just have never seen that it is as clean as OO. Now in saying that, languages are subjective. What may be clear to me could seem obtuse to someone else.
For me though Object encapsulation and inheritance model (or mix-in / Interface) makes it far easier to slightly adapt code and make it behave well for The UI. The only other place that I have realized the benefit of OO, was in AI development. In my time as an AI developer, I can not see how we could have realized the systems that we did without OO.
Outside of those realms and a few other problem domains I question the value of OO and it's benefits are marginal at best. Structures handle everything that is needed in a great percentage of places. Though it would be nice to be able to apply Interfaces to structures.
"Functional style encapsulation is a really good contender for handling UIs, especially given the ease of use of first-class functions, and especially especially reactive programming frameworks."
I don't think you can convince me that dumping OO entirely from the UI is going to be a step forward. There is a place for procedural work-flow (I call it a page controller for web) in the UI.
That is why in my original post I was arguing for JavaScript it is actually the perfect language for UI development. It was not created by accident it directly strikes at the heart of the problem.The problem is that the browser implementation until recently have been abominable and used incorrectly it can create a mess. But the basic tenants of the language are sound.
clojure, ocaml, and haskell combined have maybe 1% of the market share. This supports his point.
Javascript is widely used only because it's the only game in town for non proprietary programming on the client side. Also, most people that do heavy js try to bolt typical OO features on to javascript and are even pushing to add it to the standard.
I think is point holds. Some people have certainly questioned OO, pg is one of them, but they are clearly in the minority.