> in some cases, this philosophy has resulted in the "tangled mess held together by duct tape" kind of systems architecture that no one dares to touch for fear of breaking things.
Pretty much, just as Booch's philosophy has given us tangled messes of class hierarchies with cross references pointed every which way. And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton.
The distinction with the Unix-style pipe mess is that it exists and works an order of magnitude faster than other examples of bad code.
Additionally, it's not a religion. Every programmer should be exposed to Unix style programming just like every programmer should be exposed to functional programming. 100% purity in either case is just creating unnecessary problems.
I would like to point out that most extremism is from the perspective of the listener, not the speaker. If I just wrote a book or article called "Functional programming is great," there'd be plenty of people replying with "Oh, but what about MY favorite style? It's not that great! You're just being extreme!"
When the reality is that you can't take an opinion as the whole thought. But people do. Almost always. Regardless of the subject, people will think you're a fanatic for your position, no matter how temporary or experimental it is, unless you pay your dues in apologies and waffle terms.
> I would like to point out that most extremism is from the perspective of the listener, not the speaker.
Believe it or not, there is a significant contingent of crazy, death-threat-making jerks fixated on "The Unix Philosophy". As in, an experimental Unixy project[1] that made the rounds (including on HN) some years back and got a fair bit of attention. The project had a vision with scale similar to that of Atom, which is soaring on the front page today. But unlike Atom, this project was quietly dropped from public view because the author received a full blast of nutball hate from misguided Defenders of the Faith/Purity/Whatever.
I've been using, studying, and working with *nix systems basically forever (longer than almost everyone reading this). But that experience made me rather allergic to ever using or hearing "The Unix Philosophy". I realized that it's heavily overused as an argument-stopper: "that's not the unix way (so <EOF> off)." I've since witnessed similar language used in many projects, taken in whole context, as a dogmatic excuse rather than an actual source of architectural wisdom.
[1] Apologies for being deliberately vague. It's not my place to risk riling up the hate monsters vs. the creator of that project again. I'm still absolutely disgusted that Gamergate-level human insanity was leveled at someone putting forth what was, IMO, one of the most interesting Unix tooling experiments in the past decade.
Which is good if you're programming in an object-oriented imperative language that has a defined program flow. But while that style is the most popular, applying the same concepts to anything that isn't imperative OO will result in unfathomable suffering.
Absolutely, but that doesn't mean we shouldn't try to make some progress.
I think we have actually made progress with HTTP and all the REST. But I feel that the great failure of distributed object systems in the 1990s and 2000s has left a great void when it comes to new thinking about more fine grained sort of interfaces between programs.
Functional programming has influenced so many things but hasn't really arrived in the systems corner of the world yet. Also, looking at the sort of query capabilities of online streaming databases and complex event processing systems I get the feeling that there may be a lot of potential in combining that with Unix pipes and text streams.
Publish-subscribe ala zeromq is also something that could be a core part of modern Unix.
Sorry about the half-baked mess I'm dumping on you here :)
> And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton.
The Gang of Four didn't give us that. An army of OOP novices who were overwhelmed by all of the new choices and only skimmed Design Patterns gave us that.
If you actually read the book (which surprisingly few people have, given the number of people who have strong opinions about it), you'll see the Gang of Four are actually quite clear on the limitations or and ways to abuse the patterns.
The GUI-oriented 90's vibe, meaning zero examples that anybody would ever bother learning. The bizarre stuff nobody ever uses (Flyweight? Bridge?). Singleton -- 'nuff said.
You're left with what, maybe three usable patterns? Factory, which favors opaque, magical return-type polymorphism. Visitor, which is a solution in search of a problem, and also gets confused with trivial tree-walking operations. Interface, which rocks, and became part of Java, but really just shows how much inheritance sucks.
The resulting confusion is the proud sponsor of an AbstractStrategyFactoryBuilderDelegate near you.
> The GUI-oriented 90's vibe, meaning zero examples that anybody would ever bother learning.
It was written in the 90's. GUIs were what application developers did back then. Web apps didn't exist yet.
> The bizarre stuff nobody ever uses (Flyweight? Bridge?).
If you've used enums in Java or instanced rendering in a game, you're effectively using Flyweight.
> Singleton -- 'nuff said.
They caution really hard against overuse of Singleton in the book, but all of those C programmers being dragged into OOP didn't know where else to stuff all their global state so they went to town on it.
> Factory, which favors opaque, magical return-type polymorphism.
If your language doesn't have first-class classes, Factory is really handy. If it does have first-class classes, well that means you basically have the Factory pattern in your language. :)
> Visitor, which is a solution in search of a problem
The day you write a compiler in an OOP language is the day you realize how unbelievably, amazingly, incredibly useful Visitor is.
The Gang of Four book recommends "composition over extension" which fits neatly into the UNIX philosophy of building things by composed of smaller independent programs.
The main issue that most of the common programming languages in use notably Java and C++ have very poor support for composition thus forcing developers to have to extend things.
Example: How in Java do you add a method to the String class so that all instances of String gain the method without extending String and introducing a new subtype ?
It cannot be done. As an example see Categories in Objective-C.
Java's support for composition has improved somewhat with default methods on interfaces in Java 8 but it's still poor compared to the above languages. This leads to the "abundance of classes" anti-pattern you see with Java projects as you are forced to extend to introduce new functionality.
That's true as far as it goes, but you can write beautiful code in most languages too, even Java. The point I was making is just that "able to write bad code" is a poor metric for a philosophy. And also that "bad unix-style pipe hackery with script glue" has the advantage of actually working more often than bad code produced by other disciplines.
Pretty much, just as Booch's philosophy has given us tangled messes of class hierarchies with cross references pointed every which way. And just as The Gang of Four gave us AbstractedTangleMessFactorySingleton.
The distinction with the Unix-style pipe mess is that it exists and works an order of magnitude faster than other examples of bad code.