Hacker News Reader

Comment by dschiptsov | Hacker News Reader

Unix philosophy has nothing to do with objects. It is about interfaces, streams and common intermediate data representation - plain text.

Scheme or Erlang are real examples of following similar philosophy.

Modularity is much more basic concept, underlying any software. It is about spiting code into blocks for later reuse, named, in case of procedures, or anonymous in case of blocks or lambdas.

The notion that smaller, share-nothing procedures doing only one well-defined task are better than bloated and close-coupled ones is a general one.

So, do not try to mislead others. There is nothing from UNIX Philosophy there, just a basic concept of modularity.

View on HN

Nobody is claiming that the Unix philosophy depends on objects. The author was trying to claim that applying some Unix principles to Object Oriented Programming would be beneficial.

Do one thing, and do it extremely well is a simplified version of the Unix design philosophy. And this can be applied various levels of abstraction, including within OO programs.

I fail to see the controversy in this.

It doesn't become really controversial until someone points out that unclassed functions are the logical extreme of this philosophy at which point the predictable shit flinging starts.

>Unix philosophy has nothing to do with objects.

I'm pretty sure it's an analogy.

> It is about interfaces, streams and common intermediate data representation

And this is what modularity is all about too.

> There is nothing from UNIX Philosophy there, just a modularity

Read the second paragraph: http://www.linfo.org/unix_philosophy.html

a system that is composed of components (i.e., modules) that can be fitted together or arranged in a variety of ways. - So, it is not just about modules, it is mostly about the glue.

In the same way, Lisp without an underlying list structure is just a prefix notation.

I was using the analogy of the composability of Unix tools as a role model for how to think about the segregation of roles in an object-oriented system. I agree with you that the ways in which we can couple these objects together through their interfaces is the core of what we're designing. I think this philosophy as an analogy (especially as outlined by ESR) is applicable to a wide variety of things beyond even programming. Interesting to think about, anyway. Thanks for your thoughts.

I disagree. I once saw a talk by Bob Martin that did a great job of explaining good OO design principles by looking at examples from Unix.

It's true that Unix isn't object-oriented, but the principles that made it great are ones that object-oriented developers can benefit from studying. And given the long lifetime and wide use of the Unix model, it's a great object of study.

>It's true that Unix isn't object-oriented, but the principles that made it great are ones that object-oriented developers can benefit from studying.

Of course because these principles are basic programming principles. Yet , this has nothing to do directly with object orientation. There is no "object orientation" in the way unix works.

No, but Unix is a very good and, more importantly, concrete implementation of these principles. What's wrong with claiming that applying them to your OO programs leads to better code?

> There is no "object orientation" in the way unix works.

Who said there was?

Good OO programming revolves around separation of concerns and coherent message passing. That sounds a lot like small tools and pipes to me. Of course, no analogy is perfect, by I think it is illustrative.

On the other hand, I think the article didn't do the topic justice because it only really talked about separation of concerns. It never really talked about the "pipes". And, as you mention, the consistency of "communication via text" is what makes those pieces so able to be composed.

And, in software, some of the "pipes" we've come up with have often been truly dreadful (COM, anyone?).

Good programming revolves around separation of concerns and coherent message passing. So nothing specific to OOP. You dont need object , inheritance or states to do that. just functions that take parameters and output a result. Seeing OOP everywhere even where there is none is misleading.

Reply on news.ycombinator.com