Live data from Hacker News

Religious and spiritual folklore surrounding programming

deusinmachina.net

11–20 of 122 posts

Re: Religious and spiritual folklore surrounding programming

#11

One weird thing I noticed over time is the enshrinement of old and crappy technologies, in the face of all reason. Some examples: Some people for some reason I can't understand have warm and fuzzy feelings about FTP, despite it being a horrible protocol in multiple ways. Yet, for a long time it was often thought of being the "proper" way to download stuff, even though even HTTP is technically better in many respects.…

I feel the need to be "that guy" cause this is hacker news, but the Unix philosophy isn't really about parsing text streams, it's about decomposability of a problem. It's way easier to test and debug 4 simple programs feeding into one another other like a flow chart than building a mega program with an insane internal state (the your problem can be decomposed into 4 subproblems).

The basic core revelation that the Unix folks had was "gee wiz, I seem to need to sort data/open a socket/make a directory super often, and every time I personally try to code one of these operations up it's a huge headache that adds hours to dev time"

Re: Religious and spiritual folklore surrounding programming

#12

One weird thing I noticed over time is the enshrinement of old and crappy technologies, in the face of all reason. Some examples: Some people for some reason I can't understand have warm and fuzzy feelings about FTP, despite it being a horrible protocol in multiple ways. Yet, for a long time it was often thought of being the "proper" way to download stuff, even though even HTTP is technically better in many respects.…

> 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.

Re: Religious and spiritual folklore surrounding programming

#15

One weird thing I noticed over time is the enshrinement of old and crappy technologies, in the face of all reason. Some examples: Some people for some reason I can't understand have warm and fuzzy feelings about FTP, despite it being a horrible protocol in multiple ways. Yet, for a long time it was often thought of being the "proper" way to download stuff, even though even HTTP is technically better in many respects.…

I feel the need to be "that guy" cause this is hacker news, but the Unix philosophy isn't really about parsing text streams, it's about decomposability of a problem. It's way easier to test and debug 4 simple programs feeding into one another other like a flow chart than building a mega program with an insane internal state (the your problem can be decomposed into 4 subproblems). The basic core revelation that the Un…

Everything has good and bad cases where it can be applied of course.

But I see this as a good example of a religious issue because you can often find people think that it's a principle worth rigidly adhering to, regardless of whether it actually does produce better results in a given case.

For instance my experience is that such a model tends to get bad when things get sufficiently complex. Things like GPG and cdrecord are painful to interact with, and would arguably work much better if they were a library because a text stream is actually a pretty bad communication channel.

And sure, I agree that back when Unix was created the model made sense, but it's increasingly less and less relevant.

Re: Religious and spiritual folklore surrounding programming

#16

Earlier quoted context omitted.

I feel the need to be "that guy" cause this is hacker news, but the Unix philosophy isn't really about parsing text streams, it's about decomposability of a problem. It's way easier to test and debug 4 simple programs feeding into one another other like a flow chart than building a mega program with an insane internal state (the your problem can be decomposed into 4 subproblems). The basic core revelation that the Un…

Everything has good and bad cases where it can be applied of course. But I see this as a good example of a religious issue because you can often find people think that it's a principle worth rigidly adhering to, regardless of whether it actually does produce better results in a given case. For instance my experience is that such a model tends to get bad when things get sufficiently complex. Things like GPG and cdreco…

As the previous poster said, it’s not about text streaming, it’s about composability. One “modern” paradigm that follows the Unix philosophy and has gained a lot of traction is micro services which are mostly viewed positively. You need to extract the idea from its original implementation to apply it today.

Re: Religious and spiritual folklore surrounding programming

#17

One weird thing I noticed over time is the enshrinement of old and crappy technologies, in the face of all reason. Some examples: Some people for some reason I can't understand have warm and fuzzy feelings about FTP, despite it being a horrible protocol in multiple ways. Yet, for a long time it was often thought of being the "proper" way to download stuff, even though even HTTP is technically better in many respects.…

> 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…

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.

Re: Religious and spiritual folklore surrounding programming

#19

Earlier quoted context omitted.

> 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…

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 an…

>> 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.

Re: Religious and spiritual folklore surrounding programming

#20
post #18

> websites like The Tao Of Programming The Tao of Programming is not a website. It’s a book . If you saw the whole thing on a web site, that was an illegal copy. Of course, it was also most certainly missing the illustrations, foreword, etc.

There is no "illegal copy".
Post reply on HN