Hacker News Reader

Comment by Jtsummers | Hacker News Reader

> You still find plenty people harping on about the Unix Philosophy, even though that in modern times it's nigh irrelevant, and significant parts of it are technically obsolete. Yeah, parsing text streams was sorta okay in the 80s, but is very troublesome and brittle in the modern age.

Have you confused the Unix Philosophy with Unix itself? The Unix Philosophy doesn't have any technical components which might become technically obsolete.

View on HN

It's a fuzzy matter because it doesn't have a single agreed on definition. But yes, some parts are definitely showing their age:

> Write programs that do one thing and do it well.

Putting things together from a kit of parts isn't necessarily the optimal way to do many things. In many cases tight integration actually produces superior results, and debugging a system made from many cooperating bits isn't necessarily any easier.

> Write programs to handle text streams, because that is a universal interface.

Or don't, because it's a bad interface, and a cause of many bugs and security issues.

>Putting things together from a kit of parts isn't necessarily the optimal way to do many things. In many cases tight integration actually produces superior results, and debugging a system made from many cooperating bits isn't necessarily any easier.

The reason why this is part of the Unix philosophy is not merely because of the productivity it provides, but largely because of the power it affords end users. Most of the programs on my computer are GUIs that don't interact with each other. How much more powerful and flexible would my PC be if they were designed to do one thing well and be slotted together.

I think back to my days teaching at a college whose CS labs ran on NetWare 3. For “reasons” the user accounts were things like PASCAL; all the students in a course that used Pascal used this account (and kept their files on floppies). I wanted to move to an environment where students had individual accounts. The IT folks said that was way too much work to implement, and showed me the GUI (or TUI?) app they used to manage accounts; I agreed that this made individual accounts very difficult to manage. I sketched out a solution that used awk to identify adds and drops from the class lists the Registrar's office produced, along with scripts for creating and deactivating accounts as appropriate. This elicited much mystification from the IT folks.

A year or so later, we got individual student accounts. I resolutely refused to discover how they implemented it.

The Unix Philosophy is about building small components that compose well together. The fact that some applications benefit from tight integration in no way derogates from its value.

So absolutely true. I work in an “operational facing” engineering group. We are engineering but process data (daily/monthly data processing for factory and customer requests). Having a composable process using the Unix philosophy makes it trivial to stop processing at any point in the work flow for that one customer request that comes up once a year. There is no ROI to make the work flow support these edge cases, it’s cheaper even after a decade or more just to one-off these special cases. But this would be completely impossible if we didn’t architect the system in smaller components. As you say, it’s not text processing, it is units of processing that can be composed, stopped, reordered or have a custom step in the middle.

>> Write programs that do one thing and do it well.

> Putting things together from a kit of parts isn't necessarily the optimal way to do many things. In many cases tight integration actually produces superior results, and debugging a system made from many cooperating bits isn't necessarily any easier.

Define "optimal" here. Without a definition this is a meaningless statement. But even if your definition of "optimal" is "easiest to debug", I'd have to disagree. Tightly coupled systems are nigh impossible to debug because you have to have the whole system composed together to debug anything. Loosely coupled systems allow you to debug each part separately, and small components mean they have little you have to debug. The next part of debugging is the interaction points, but that's easily constrained with a moment's thought when designing and developing a system.

If "optimal" is about performance, that's a debatable thing. The tightly coupled shit some people put together at my office is terrible with respect to performance. It's bordering on negligence the way they designed it and trying to fix the performance issues is almost impossible again because of the tight coupling of different components.

Regarding text streams: Ok, one weak point in some definitions/descriptions of it. The idea of utilizing a more universal data format though still stands. 1 million or so different binary formats isn't much better.

That is kind of the point, you have to define the problem and the tradeoffs involved. Then sometimes one approach better than another. That determination should be made on a case-by-case basis, rather than as a religious matter.

So for instance stringing too many things together also leads to confusion due to the many interactions between disparate bits.

At some point you can end up too much parsing/serialization in the mix, too much accumulation of startup costs, or dealing a system that has components written in shell script, Perl, Python, C, C++ and Rust making the whole system difficult for any random person to comprehend fully.

Stream is a bad interface in general and a cause of (…). Our worst ones were mostly binary, afair.

Reply on news.ycombinator.com