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

21–30 of 34 posts

Re: Functional programming and the death of the Unix Way

#21

Post by Ralith »

> I’m not advocating a return to Lisp machines here. We tried that and it didn’t work. Symbolics is dead, and no one even gave a eulogy at that funeral.

The hell? Lisp machines were awesome. I thought it was well known that they failed partly for political reasons, and partly because Symbolics was absolutely horrendous at business.

The only failing I'm aware of was the lack of multi-user support, which wasn't particularly unusual for era, and even now we don't have anything which can compare to their high points.

Re: Functional programming and the death of the Unix Way

#23

Post by mcav »

jes5199 wrote: post #18

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

Look for "nailgun", which prewarms the jvm. Also, in the interim, clojurescript->nodejs looks promising.

Re: Functional programming and the death of the Unix Way

#24

Post by Ralith »

jes5199 wrote: post #18

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

Not all functional languages run on the JVM or anything similar. In fact, most don't. See: Haskell, *ML, most Lisps and Schemes, ...

Re: Functional programming and the death of the Unix Way

#25

Post by avsm2 »

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.

It's back up now; the ML TCP stack was running a pcap dumper for debugging, which didn't cope well with a hackernews link.

Hacking is going pretty well on Mirage. The longer-term plan is to generalise the support libraries to work with other languages (particularly HalVM and GuestVM for Java), but it's far simpler to work with just OCaml for getting the first cut out. The Xen Cloud toolstack (also written in OCaml) is currently being adapted to support low-latency microkernel establishment, which will remove much of the hassle of coordinating multiple Mirage 'processes'.

Another interesting performance-related aspect has been the heavy IPC workloads that result from using many VM-VM interconnects. Some early benchmarks in http://anil.recoil.org/papers/2012-resolve-fable.pdf .

Re: Functional programming and the death of the Unix Way

#27

Post by adobriyan »

dsrguru wrote: post #7

So basically the author is saying: The UNIX shell pipeline is really just a functional programming language whose functions can only operate on strings. Think how much more powerful, concise, readable, etc. it would be if other data types were supported. I agree. I don't even think this requires changes at the OS level. Newlisp and Racket's shell attempt might be clunky, and Clojure certainly isn't ready for quick-an…

Unix pipes are about octet streams not strings.

Re: Functional programming and the death of the Unix Way

#29

Post by dsrguru »

adobriyan wrote: post #27
dsrguru wrote: post #7

So basically the author is saying: The UNIX shell pipeline is really just a functional programming language whose functions can only operate on strings. Think how much more powerful, concise, readable, etc. it would be if other data types were supported. I agree. I don't even think this requires changes at the OS level. Newlisp and Racket's shell attempt might be clunky, and Clojure certainly isn't ready for quick-an…

Unix pipes are about octet streams not strings.

In most hackers' idiolect, the term "string" refers to an implementation-dependent representation of characters. An octet stream or byte stream is the abstraction that UNIX files and the standard I/O streams happen to be instances of. So it wouldn't be wrong per se to use "octet stream" here, but I'm treating each phase of the pipeline as a hypothetical function that operates on text. With less indirection, you could certainly view them as functions operating on streams, but I abstracted that away in my mental picture.

Re: Functional programming and the death of the Unix Way

#30

Post by draven »

This article reminded me of something I read about the Unix model vs the lisp model. I managed to track it down, it's a comp.lang.lisp posting by Erik Naggum.

http://www.xach.com/naggum/articles/3245983402026014@naggum....

The interesting part is the 3rd paragraph of the answer.

Post reply on HN