[FoRK] Programming languages, operating systems, despair and anger

Jeff Bone jbone at place.org
Sun Nov 15 21:06:33 PST 2009


Brad Pitt writes:

> It is my pious hope, to quote Roger Penrose, that none of the  
> challenges I've describe above are fundamental and all could be  
> solved with only a modicum of effort from some motivated folk.  
> Whether they are the same sort of problems that raised Jeff Bone's  
> ire I can't say, but I remain quite optimistic there isn't cause for  
> despair or anger in this.
Rather stream-of-consciousness, caveat lector.

Well-acquainted with both Puppet (as in, user) and Chef (not a user,  
but definitely an admirer.)  And I'll even go so far as to say that,  
indeed, they both do in fact represent a kind of benchmark in terms of  
what's reasonable and possible in expression of complex integration  
environments and scenarios.  (Particularly Chef;  I didn't choose  
Puppet over Chef in the situation in which I'm acquainted with it, but  
probably would have had it the other way around had it been my call.)

That said, neither is quite the answer to either the programming-in- 
the-large or programming-in-the-small scenarios I envision;  they  
don't make solving either of the (still-toy) use cases I sort of  
informally sketched out as *trivial* as I believe they could be, with  
only a bit more batteries-included abstraction supported *throughout  
the toolchain.*

All that information, buried in all those strings.  Ruby's DSLish  
support improves things a bit.  Not enough, IMHO.

Despair and anger?  I mean come on.  How can you experience anything  
else when e.g. (a) it's nearly 2010 and *printing still doesn't work  
right, really*, and (b) there's a damn teletype in your sleek MacBook  
Air, and (c) sockets, network servers, and files all still live in  
different namespaces, with different non-generic interfaces, in most  
contexts?  (Particularly the latter is frustrating:  I see Plan 9,  
circa early-90s, perhaps less so Inferno a bit later, as sort of  
practical benchmarks in *how* systems integration should happen.   
Maybe also Plan B and Octopus, slightly later but definitely academic- 
research progeny.  But the kinds of things enabled by a little  
abstraction, universally applied in such environments is science  
fiction in "real world" operating systems and user environments.  And  
*those folks* are the very ones that are now obsessing over receiver  
type designation and return value type declaration syntax in a  
"systems programming language" that looks only epsilon different than  
the language experimentation these guys were doing nearly two decades  
ago.  How can you innovate wildly at the system level of things yet be  
so incredibly overcautious in your language experimentation...?)

Perhaps your level of nerviness is less than mine, or perhaps I just  
enjoy a good rant more than you. ;-)

Can you abstract away a lot of useful stuff with existing tools and  
types, enabling some kinds of easier integration and using  
representations of those higher-level things in terms of lower-level  
things?  But of course;  "solving" many (valuable) problems of  
integration at that level is quite tractable and not at all  
fundamental, and actually quite useful.  Hence e.g. Chef.  But is is  
sufficient in the long run?  I don't think so.  Let's be honest:  do  
we really think that Chef has the potential longevity of, say, the  
Bourne Shell?  Doubtful, and I'd guess that even its authors would  
agree;  it's a point along the way and a useful one, but it's  
evolutionary.  We need a revolution.  Well, at least I *want* one. :-)

Absent another pipelines-like "aha" moment about how things should  
plug together, talk to each other, and exchange data --- maybe some  
reconsideration of namespaces and generic interfaces, ala Plan 9, is a  
reasonable starting point for some serious contemplation --- the  
future is doomed to being rife with Vinge-ian software  
archaeologists.  That's even assuming we even get there, which  
possibility is made more distant by saying that the state-of-the-art  
in such things circa 1970 (or 1990, or whatever) is "good enough."

E.g., I can "pretend" that the tabular data flowing through my shell  
pipeline into my awk program is actually something structured as  
"records" consisting of "fields" --- and awk itself does so.   
Semantically preserving that intent across an arbitrary pipeline of  
arbitrary components written by arbitrary other people at arbitrary  
points in the past --- not so much a winner.)  Raising the bar by  
making those abstractions more first-class and preserving those types  
in some transitive yet reflective rather than strict way *definitely*  
leads to better expression and better composition.


YMMV...


jb


PS - "pious hope" --- well, exactly.


More information about the FoRK mailing list