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

Functional programming and the death of the Unix Way

newcome.wordpress.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Functional programming and the death of the Unix Way

#11

Post by chubot »

andolanra wrote: post #6

The gist—as I understand it—is that Unix programs are essentially all equivalent to functions : ([String], TextStream) -> (TextStream, TextStream) which limits how one can tie them together and causes a proliferation of text-processing tools (awk, sed, grep, cut, &c &c) which is not as elegant as functional programming. There are already some Unix command-line tools that work on structured data as mentioned, e.g. jsa…

Not really sure how you jumped from structured data in Unix to a bare metal OS, but this project came up a few weeks ago, OCaml programs on Xen with no OS:

http://www.openmirage.org/wiki/papers (down now, doh)

Seems to have some similarities to halvm.

Re: Functional programming and the death of the Unix Way

#12

Post by luriel »

andolanra wrote: post #6

The gist—as I understand it—is that Unix programs are essentially all equivalent to functions : ([String], TextStream) -> (TextStream, TextStream) which limits how one can tie them together and causes a proliferation of text-processing tools (awk, sed, grep, cut, &c &c) which is not as elegant as functional programming. There are already some Unix command-line tools that work on structured data as mentioned, e.g. jsa…

Just because data is in a text stream doesn't mean it is not structured. Awk is designed to handle structured text for example, the output of most (traditional) Unix tools is 'structured' too (eg., ls and ps).

I recommend you read The Unix Programming Environment which gives many illustrations of how the Unix 'text streams' model works in practice.

One of the authors of that book and other folks that created Inferno (and Plan 9 and Unix) are now at Google working on Go.

Go channels are obviously not the same as Unix pipes, but there are similarities.

Re: Functional programming and the death of the Unix Way

#13

Post by luriel »

andrewflnr wrote: post #9

I wonder, does this mean we actually want types as metadata on our shell commands? Type of args, type of stdin, type of stdout, or whatever we decide to call them? All apps would have to speak a single, more complicated language and we would have to do more explicit translation but it might work out better.

Aren't Go channels similar to typed pipes?

Re: Functional programming and the death of the Unix Way

#16

Post by andolanra »

chubot wrote: post #11
andolanra wrote: post #6

The gist—as I understand it—is that Unix programs are essentially all equivalent to functions : ([String], TextStream) -> (TextStream, TextStream) which limits how one can tie them together and causes a proliferation of text-processing tools (awk, sed, grep, cut, &c &c) which is not as elegant as functional programming. There are already some Unix command-line tools that work on structured data as mentioned, e.g. jsa…

Not really sure how you jumped from structured data in Unix to a bare metal OS, but this project came up a few weeks ago, OCaml programs on Xen with no OS: http://www.openmirage.org/wiki/papers (down now, doh) Seems to have some similarities to halvm.

The (inadequately developed) point was that this idea could be built into an entirely new operating system with e.g. a different notion of a process—as opposed to building new tools on top of Unix—and that this "operating system" could be a lightweight layer like HaLVM or Mirage, so such ideas could be explored without committing to building an entire OS.

Re: Functional programming and the death of the Unix Way

#17

Post by andrewflnr »

luriel wrote: post #13
andrewflnr wrote: post #9

I wonder, does this mean we actually want types as metadata on our shell commands? Type of args, type of stdin, type of stdout, or whatever we decide to call them? All apps would have to speak a single, more complicated language and we would have to do more explicit translation but it might work out better.

Aren't Go channels similar to typed pipes?

I guess, but they're not exactly cross-language inter-process communication. Maybe you could work something like them into the OS, though.

Re: Functional programming and the death of the Unix Way

#18

Post by jes5199 »

I had an idea to write Clojure parsers for the standard unix command line tools that translates the output into s-expressions.

I got too frustrated - on the one hand, Clojure's slow start up time meant it was no fun to use in a simple pipe

and on the other hand, even the simplist unix util has surprisingly complicated behavior. Like `wc` - it outputs three columns of numbers, right? Well, unless it knows filenames, which go in a fourth column. Or unless you pass it flags, which can turn any set of the number columns on and off. And then I thought, wait, what happens if you make a file which has leading whitespace in the name - it turns out it only outputs a single space in front of the filenames, so any whitespace after that is part of the name.

Which lead me to the conclusion: unix tools aren't actually simple - they are actually really complicated, but you can construct a happy-path of simplicity for most use cases

and functional languages are still monolithic when it comes to interacting with the outside world. Maybe someone will make a service I can run in the background that will run my command-line clojure scripts in a pre-warmed JVM, but that's not a piece of technology that I want to try to write.

Re: Functional programming and the death of the Unix Way

#19

Post by ggchappell »

... and the evolution can continue along the same lines as Unix. I think I'll write a Haskell function that takes two strings and returns a string. The first string is a program in a new language I'll invent. The second is the input to the program, and the return value is the output of the program.

Maybe I could call it "herl".

  herl :: String -> String -> String

Re: Functional programming and the death of the Unix Way

#20

Post by msutherl »

Dataflow environments like PureData, Max/MSP, Quartz Composer and vvvv are very much like 2D GUI-driven shells that handle various data types. Max/MSP was, at least, explicitly conceived as a sort of UNIX for multi-media. After working with such tools for years, I must say that the tools the professional programmers use seem comparatively quite primitive in many ways (though much more advanced in others). A graphical environment that utilized the same sort of dataflow model, but with a more general intended audience, more extensible architecture and some concepts from functional programming would have the power to really change how programming is done.
Post reply on HN