Plan 9 had userspace filesystems. Moreover, it encouraged services to export control interfaces as filesystems -- so you could mount a service and then configure it using open(), read() and write().
Have a look at the Plan 9 wiki. You can even run it inside vmware or Xen.
I totally agree with the need to return more interesting values from functions. In O'Caml I just write
let a, b = foo ()
as you suggest.
However, one minor niggle: The idea of a function returning one item comes from math. However in math these items can be anything; a single int (member of Z), a pair of ints (member of Z x Z), a huge complicated structure describing the state of an interpreter or whatever. Maths doesn't restrict functions to only return one single integer, or float or whatever. It just so happens that many common functions are defined that way, it's not true of functions in general. So the restriction comes from C/C++ and not math.
Don't forget that the "backbone" is the cheap bit -- the biggest bit (most cable, most equipment) and by far the most expensive is in the "access" network (aka the last few miles). That costs quite a lot... especially when you're expected (like telcos are) to provide service to rural places where it's economically unviable.
Too many language "features" leads to problems. How well do the features interact (are they orthogonal to each other)? How many people understand how to use them all?
Modern research on language design focuses on finding the simplest, most elegant combination of features that allows you to express the concepts you want to, in a safe a way as possible.
If you add in lots of random features things become far too complicated to manage.
Slashdot Mirror
Plan 9 had userspace filesystems. Moreover, it encouraged services to export control interfaces as filesystems -- so you could mount a service and then configure it using open(), read() and write().
Have a look at the Plan 9 wiki. You can even run it inside vmware or Xen.
However, one minor niggle:
The idea of a function returning one item comes from math. However in math these items can be anything; a single int (member of Z), a pair of ints (member of Z x Z), a huge complicated structure describing the state of an interpreter or whatever. Maths doesn't restrict functions to only return one single integer, or float or whatever. It just so happens that many common functions are defined that way, it's not true of functions in general. So the restriction comes from C/C++ and not math.
Don't forget that the "backbone" is the cheap bit -- the biggest bit (most cable, most equipment) and by far the most expensive is in the "access" network (aka the last few miles). That costs quite a lot... especially when you're expected (like telcos are) to provide service to rural places where it's economically unviable.
Too many language "features" leads to problems. How well do the features interact (are they orthogonal to each other)? How many people understand how to use them all?
:)
Modern research on language design focuses on finding the simplest, most elegant combination of features that allows you to express the concepts you want to, in a safe a way as possible.
If you add in lots of random features things become far too complicated to manage.
Keep it simple (and elegant)...