Glad it was helpful. If you want to see why Unix programmers scoff at OOP, I recommend "The Art of Unix Programming" by Eric Raymond.
OOP advocates threw around words like modularity and encapsulation and a lot. But nobody told programmers that Java and C++ have much worse modularity and encapsulation properties than the traditional Unix style.
Ideally under Unix you would have small Java programs and small C++ programs working together and passing messages. But that's not really how a lot of people architect things these days. You tend to get monolithic Java codebases and monolithic C++ codebases. People don't design protocols with care.
The web is also very Unix-y. It's structured around data and simple protocols. Yet for some reason programmers insist on "abstracting" the web with objects. These attempts have uniformly failed. There's a reason for that.
Note that Linus Torvalds is a C programmer -- he doesn't use any "object oriented" languages. Structuring programs around data makes them modular. A main reason is that you can adapt data from one form to the other, to glue together pieces of code. You can't adapt byzantine sequences of method calls and inheritance trees -- you end up having to rewrite. Look at classes in Java programs that have the word "Adapter". Often they are a big smell and barely work, and this is because the fundamental abstractions being used are non-compositional.
I understand that this was the mentality in "The Art of UNIX programming", and it is really powerful. The problem is that UNIX never provided a good way to compose programs that need to exchange more than text.
As a result, the outputs of a UNIX-like system are great for programmers but terrible to use by everyone else. For example, if you need an interface that display a nice button to execute a function, you're out of luck with UNIX. The more detailed the interface, the more complicated it becomes. That's why OO has become the de facto way to create user friendly UIs.
It's true. Parsing is a pain and a source of security holes. There are a lot of people trying to do things with structured data over pipes. But there are a lot of ways to do it wrong, and consequently it hasn't caught on much. I've been working on some code for awhile which is too much to go into here, but it's trying to solve this problem of text-over-pipes being too limited, without introducing the tighter coupling of OOP.
You could argue that JSON web services are basically this, but in practice I don't see that they're used in a strongly compositional way.
However, the funny thing is that OO arguably isn't the way we create interfaces anymore. We create interfaces by sending domain-specific languages like HTML and CSS over the network.
Although I guess you could argue iOS and Android interfaces are created with OOP, and I won't deny that it's a successful paradigm there. Objects make a lot of sense for things like games and writing CAD programs and so forth. The "modeling" works in those domains. It doesn't really make a lot of sense for server software. Basically OOP is a domain-specific language IMO.
OOP advocates threw around words like modularity and encapsulation and a lot. But nobody told programmers that Java and C++ have much worse modularity and encapsulation properties than the traditional Unix style.
Ideally under Unix you would have small Java programs and small C++ programs working together and passing messages. But that's not really how a lot of people architect things these days. You tend to get monolithic Java codebases and monolithic C++ codebases. People don't design protocols with care.
The web is also very Unix-y. It's structured around data and simple protocols. Yet for some reason programmers insist on "abstracting" the web with objects. These attempts have uniformly failed. There's a reason for that.
On a related note, this was discussed on HN recently: http://programmers.stackexchange.com/questions/163185/torval...
Note that Linus Torvalds is a C programmer -- he doesn't use any "object oriented" languages. Structuring programs around data makes them modular. A main reason is that you can adapt data from one form to the other, to glue together pieces of code. You can't adapt byzantine sequences of method calls and inheritance trees -- you end up having to rewrite. Look at classes in Java programs that have the word "Adapter". Often they are a big smell and barely work, and this is because the fundamental abstractions being used are non-compositional.