Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix Philosophy

catb.org

Post reply on HN
Print view View original

161–170 of 269 posts

Re: The Unix Philosophy

#161

Post by JadeNB »

jalfresi wrote: post #92
fauigerzigerk wrote: post #32

I keep wondering about what seems to be the most important component of Unix philosophy: write many small programs that do one thing well and interface using text streams! Yes, modularity is important. However, 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. I think Unix philosophy is stru…

Recently I've been exploring the idea that small programs should consist of two parts; a "backend" that you can communicate with via a strict message protocol like protobuf. It can handle multiple requests because it is a mini server, the message format is locked to a "type" and you communicate with it via RPC. The second part is a "frontend", a command-line client that does all the unixy stuff with text streams etc;…

I like this idea! It seems very Unix-philosophy-y (sorry) itself; break up the programme even further, from "do one thing" to "figure out what to do" + "do it".

Re: The Unix Philosophy

#162

Post by Retra »

jayvanguard wrote: post #123
jbooth wrote: post #101

Earlier quoted context omitted.

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.

Amen. Extremism in programming, as in religion, is evil.

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.

Re: The Unix Philosophy

#163

Post by zvrba »

mbrock wrote: post #37
zvrba wrote: post #31

> The ‘Unix philosophy’ originated with Ken Thompson's early meditations on how to design a small but capable operating system with a clean service interface. Except that a program-to-program interface based on formatting and parsing text is anything but clean.

What do you mean by "text"?

Semi-rigid, informally specified output meant for easy inspection by humans. The output of `ifconfig -a` for example. (That's the worst offender, most other commands have a better-formatted output.)

As a general rule of thumb: if you have a command pipeline that would break because programs in it handle locale differently, it's most definitely text-based program.

I like the idea of Power shell: programs pipe formatted (binary) objects between them, and there exist commands to print them out in a nicely formatted way to the terminal. But it's objects. I can extract information through named fields instead of through magic indexes and regexpes in awk/sed/perl oneliners.

IOW, proper object (meta)model, not sucky text streams. Text is great for long-term storage, but awful for data in flight. UNIX ignored this distinction and decided to use text for everything.

Re: The Unix Philosophy

#164

Post by sophacles »

jimmaswell wrote: post #141
DannoHung wrote: post #88

Earlier quoted context omitted.

Python's support for closures is perfectly fine. Its anonymous function support is crappy, but it doesn't stop you from doing what you want, it just looks as ugly as sin.

Python only lets you have one line in a lambda - the return line. In languages with nicer anonymous function support I can make an anonymous function span multiple lines and branches eg. in C# you could assign to a delegate something like myObj.stringToHash = (s) => {int x = 0; foreach(var c in s) x += ... ; return x;} I find python's restriction in this case fairly strange. If I wanted to do that in python I'd have…

Functions can be defined in a nested way setting up closures. It isn't that different from what you wrote to do:

    def some_method(...):
        avar = aval
        .... (some code)
        def throwaway(x, y):
            ....
            something_else(avar, x+y)
        some_obj.somefunc = throwaway
The major difference is you do the function definition just prior to the assignment. The "namespace pollution" is literally limited to the scope of "some_method", so you have an extra local var in a function somewhere. The semantics of python mean that the function is created on the stack, and a closure is created each time the some_method is called, and the closure is later GCed as any other object would be, so there is nothing fundamentally different about the "named" function, and the "anonymous" function in you example, except a single local variable.

Re: The Unix Philosophy

#165

Post by cfallin »

nly wrote: post #59
lmm wrote: post #40

Earlier quoted context omitted.

The big problem I've found is serialization of sum types. thrift (or protobuf or any number of similar systems) is very good at serializing most of the data one tends to work with, with declarations that are suitably strict but easy to write. But it doesn't have a good way to represent "this field is an A or a B".

Thrift has unions, so does Apache Avro. Afaik Protocol Buffers is the only one where you have to string together one yourself with a required tag and a bunch of optionals.

Protobufs has unions now too (they're called "oneofs"), as of version 2.6.0 released last year:

https://github.com/google/protobuf/releases/tag/v2.6.0

Re: The Unix Philosophy

#166

Post by mseepgood »

jokoon wrote: post #13

This should be taught in any programming class. > Rule of Diversity: Distrust all claims for “one true way”. Although, does the python rule "There should be one-- and preferably only one --obvious way to do it." contradict this one ? > Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are ce…

> I wonder what rob pike has to say about OOP

https://talks.golang.org/2012/splash.slide#55

https://talks.golang.org/2012/splash.slide#56

https://talks.golang.org/2012/splash.slide#57

From this talk: http://www.infoq.com/presentations/Go-Google

Re: The Unix Philosophy

#167

Post by sanderjd »

deckiedan wrote: post #120
jalfresi wrote: post #92

Earlier quoted context omitted.

Recently I've been exploring the idea that small programs should consist of two parts; a "backend" that you can communicate with via a strict message protocol like protobuf. It can handle multiple requests because it is a mini server, the message format is locked to a "type" and you communicate with it via RPC. The second part is a "frontend", a command-line client that does all the unixy stuff with text streams etc;…

Surely a lot of that could be done with a commandline switch? tape_robot start -tapeid=1 as the quick hacky version, and: tape_robot --protobuf 'msg:start;tapeid:1' (replace the 'single:quote;string:thing' with your protobuf message.), or tape_robot --protobuf_file filename The filename could be a fifo or socket, of course. Then use a general purpose server which runs the programs: proto_serve tape_robot 127.0.0.1:80…

Interesting. This seems very non-unix-y to me. The `tape_robot` doesn't "do one thing", it does many things, including parsing protobuf from shell strings and files, which seems error prone and way outside its core competency.

Re: The Unix Philosophy

#168

Post by vezzy-fnord »

spiralpolitik wrote: post #126
el33th4xx0r wrote: post #29

I wonder how relevant is it nowadays. Many good things we can't have, like systemd, if we have to follow strictly to the unix philosophy.

Sure you can. See 'launchd' on OSX. The reason that 'systemd' is the ball of mud it is that Linux being just a kernel does not provide the basics for systemd to build on so it has to provide them itself.

The main service management-related components of systemd very much exploit the Linux kernel's facilities, so your claim is completely incorrect.

The broader tools that systemd also provides (stub DNS/LLMNR resolution, network management [DHCP, PPP...], container registration, message bus introspection and library, event loop library, EFI stub loader, device and mount management, hardware database, TTYs, NSS plugins, session and seat management, SNTP client, time/date control, dynamic configuration population, etc.) exist mostly for philosophical reasons of being a one true toolkit/middleware that sits between GNU and Linux.

launchd isn't Unix-y at all, anyway.

Re: The Unix Philosophy

#169

Post by batou »

jalfresi wrote: post #92
fauigerzigerk wrote: post #32

I keep wondering about what seems to be the most important component of Unix philosophy: write many small programs that do one thing well and interface using text streams! Yes, modularity is important. However, 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. I think Unix philosophy is stru…

Recently I've been exploring the idea that small programs should consist of two parts; a "backend" that you can communicate with via a strict message protocol like protobuf. It can handle multiple requests because it is a mini server, the message format is locked to a "type" and you communicate with it via RPC. The second part is a "frontend", a command-line client that does all the unixy stuff with text streams etc;…

A lot of people don't know this but that's pretty much how Windows actually works underneath everything (DCOM, RPC, pipes etc)

Re: The Unix Philosophy

#170

Post by mzs »

zvrba wrote: post #163
mbrock wrote: post #37

Earlier quoted context omitted.

What do you mean by "text"?

Semi-rigid, informally specified output meant for easy inspection by humans. The output of `ifconfig -a` for example. (That's the worst offender, most other commands have a better-formatted output.) As a general rule of thumb: if you have a command pipeline that would break because programs in it handle locale differently, it's most definitely text-based program. I like the idea of Power shell: programs pipe formatte…

env -i ifconfig -a | ... solves a lot (like locale or other special env vars), but yeah...
Post reply on HN