[kryptonomist]

One use case where I found OO particularly unsuitable is applications that rely heavily on events. Trying to understand what's happening is hard, when any call to your object structure can trigger changes at any level of your hierarchy, triggering other changes again, and so on.

Luckily, the rising popularity of Swift, Kotlin, and Go, will push for a more reasonable use of OO in combination with FP.

[tabtab]

Re: One use case where I found OO particularly unsuitable is applications that rely heavily on events.

I agree. Events typically have to "belong" to something in OOP, but how they are best grouped or managed may not fit a single-item belonging-ness.

I'd like to see languages which are flexible in how events are organized in file systems. Their file grouping wouldn't have to reflect some object hierarchy or odd code structure, it would be organized how a team wants. Conway's law. A "header" would define the criteria for triggering. You could have wild-card based triggering and expression based triggering. wild-card triggering would be more efficient and orderly, but one needs expression-based triggering for certain circumstances.

Perhaps manage all those event handlers in an RDBMS. But our existing tools and IDE's are file-centric when they should be looking to be RDBMS-friendly. When you are dealing with thousands of fairly-similar things, such as event handlers, it's time to think about databases, not files and folders. OOP and files/folders don't scale very well.

[professorTuring]

I can't agree. Do you know which application who rely heavily on events is anywhere and it is programmed in OOP all around the world?

Windows management systems. Everywhere. OOP works like a charm.

Also, all that stuff you are saying about "expression-based" triggering, it exists and working fine...

Also you are mixing OOP with files and folders and I can't understand why...

[tabtab]

Re: Windows management systems. Everywhere. OOP works like a charm.

Good enough, perhaps. Charm, no.

Re: Also, all that stuff you are saying about "expression-based" triggering, it exists and working fine...

Perhaps, but expression-based dispatching is not OOP. It's more comparable to relational or functional.

Re" Also you are mixing OOP with files and folders and I can't understand why...

I don't necessarily proposing mixing. If we can do it without OOP, that would be fine by me. I prefer the source code be organize by how a shop wants to work, not how the framework forces you to. Conway's Law.

Better yet, manage it in a database so one can sort, search, group, and filter by specific need at a given time. Why hard-wire a grouping when we have relational? If I want to see all button-handling events together, query, boom, done! If I want to see events for widgets with labels having the text "cup" in them, query, boom, done! Etc. Bill Gates won't determine my grouping/view, you don't determine my grouping/view, but I do. Me, myself, and I. I like that, it makes me productive.