hn-classics/_stories/2009/7966068.md

---
created_at: '2014-06-30T16:51:02.000Z'
title: Programming languages, operating systems, despair and anger (2009)
url: http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html
author: astigsen
points: 60
story_text: ''
comment_text: 
num_comments: 37
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1404147062
_tags:
- story
- author_astigsen
- story_7966068
objectID: '7966068'
year: 2009

---
[Source](http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html "Permalink to  [FoRK] Programming languages, operating systems, despair and anger
   ")

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

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

**Jeff Bone** [jbone at place.org ][1]  
_Thu Nov 12 11:08:40 PST 2009_

* Previous message: [[FoRK] Phil Agre missing ][2]
* Next message: [[FoRK] Programming languages, operating systems, despair and anger ][3]
* **Messages sorted by:** [[ date ]][4] [[ thread ]][5] [[ subject ]][6] [[ author ]][7]
* * *
    
    
    Or, the State of the End-User Environment / Programming Onion...
    
    So, in a confluence of events, I have been lately looking at Scala and  
    yesterday spent some time looking at Pike / Thompson / Google et.  
    al.'s "Go" language for "systems programming."  And Guido halts Python  
    syntactic evolution before the job is done...
    
    And it fills me with despair and anger.
    
    Language designers in general:  You are IN THE WAY.  Go here:
    
       <http://www.rebol.com/oneliners.html>
    
    ...then do us all a favor and don't resist the urge to fall on that  
    wakizashi when your shame overcomes you.
    
    First of all, neither Scala nor Go is anything more than incremental  
    evolution;  Go in particular put me over the edge.  It's merely the  
    latest of a series of languages from these same people (former god- 
    like heroes to me) --- most recently Limbo, each successive one of  
    which implements the same ideas in barely, idiosyncratically, every-so- 
    slightly different ways.  And so for 20 years now these folks ---  
    *the* shining lights, in many ways, of "practical" programming  
    language, operating systems, and general systems research --- have  
    continued to fail to "get" the fundamental practical needs of everyday  
    programmers working in The Real World.  "Go" is just another language  
    written first for the compiler and only secondarily for the programmer  
    --- and stuck in a 70s mindset* about the relationship of that  
    programmer to the (digital) world within which they live and work!   
    (But hey, it compiles fast!  Which is, of course, THE problem that  
    really needs addressing.)  (Or rather, a fast-forwarded 70s mindset  
    projected into a fictional future.  I get the sense that Google is a  
    bit Star Trek-ish;  an anachronistic-nostalgic future that doesn't  
    really exist outside of its own fictional milieu.  I mean --- it took  
    'em 200 years to figure out the implications of the transporter  
    buffers --- and then they didn't even take advantage of them  
    consistently?  GMAFB.  But I digress.)
    
    I think Carl Sassenrath may be the only person on the planet working  
    in this area that accurately perceives the "pain" involved in general,  
    everyday, practical programming and is *actually* trying to address  
    it.  Too bad his solution is locked in closed source, in corporate  
    lock-in, and in a company that *clearly* is suffering from a  
    completely schizophrenic (lack of) "business model" --- no doubt due  
    to the influence of investors and suits and isolation.  (Not to  
    mention suffering from ghastly-ugly, mondo-1989 graphic design of its  
    built-in GUI toolkit components and hence all application UIs.)   
    (Other candidates for clue include Eric Meijer who, unfortunately,  
    seems to have been unable to translate clue to practice in many ways,  
    despite lots of "enterprise-scale" innovation;  and Alan Kay, who has  
    some real ideas ("Worlds" == absolutely awesome idea) but is  
    apparently suffering from "research / think tank / industry alumni"  
    inability to reduce research to practical practice.)  (Wolfram might  
    get it...  maybe, part of it...  but let's not go there, same lock in  
    probs as Carl's gig but a whole lot worse, and a lot of other issues  
    too.)
    
    What do we do?  Communication, coordination, automation, analysis, and  
    visualization / animation / interaction.  That's IT.  Over a few-dozen  
    basic kinds of information and in a handful of typical hardware  
    environment / architectural scenarios.  Come on!
    
    J.H.C, folks, it's nearly 2010.  Let's get a few things straight:
    
       - most programming involves schlepping a few but complex data types  
    between different string representations
       - programmers have become plumbers and documentation-archaeologists  
    mostly, which is sad and uninteresting
       - programming languages are for *programmers* --- not compilers and  
    compiler-writers
       - until you make the everyday, "simple" things simple, it will  
    continue to be a dark art practiced by fewer and fewer
       - any language that makes you explicitly import an IO module to  
    read a file or stdin is fucked
       - declarations are a pointless anachronism (same for explicit  
    memory management)
       - if I have to understand category theory to write a program that  
    does IO, IT IS A NON STARTER!
       - less stupid line-noise syntax and punctuation, people
    
    SIMPLE GUI PROGRAMMING!  Remember BASIC?  Logo?  Zero to graphics in  
    three minutes, max.  How the hell are kids supposed to learn to  
    program these days?  Even Python's learning curve is too high, IMHO,  
    though it's probably the closest thing to a reasonable starting ground  
    that has any real traction.  And the GUI bar is raised these days:   
    kids and non-developers (and busy developers w/o time for little,  
    interesting toy projects *just because project set-up cost is so high  
    in almost any language / environment!) need to be able to throw  
    together complex multi-agent 3D microworlds with minutes.  (Yes, I'm  
    aware of Kodu and friends.  It's a start, maybe;  but it needs its  
    textual equivalent;  enough with the "only visual programming" crap,  
    it has shown its limits.)
    
    If you provide some binding / embedding to Tk and you think that's  
    sufficient to satisfy your GUI needs, then IT'S A NON-STARTER!  If you  
    DO NOT provide a CANONICAL cross-platform GUI toolkit, IT'S A NON- 
    STARTER!
    
    If it's more than 5 readable lines to produce a "hello, world" web  
    server --- NON STARTER!
    
    If sending an e-mail isn't a one-liner --- NON STARTER!
    
    Getting a web page or making a simple http post > 1 line --- NON  
    STARTER!
    
    Figuring out the number of days between two dates > 1 line --- NON  
    STARTER!
    
    While I'm on a rant, FUCK JSON.  I mean, first fuck XML thoroughly and  
    nastily, but let's call it like it is -wrt- JSON.  Anything that  
    forces me to do this shit:
    
       {
         'someSymbolicKeyAsString':  'someUriValueAsString'
       }
    
    ...is BROKEN BY DESIGN!
    
    NO MORE TUNNELING CRAP IN STRINGS!!!
    
    *REAL WORLD*, modern datatypes, built-in, literal, batteries-included  
    PLEASE!!!  If the following aren't first-class types with first-class  
    literal constructors / representations supported *at the language  
    level* then your new programming language ISN'T EVEN ON THE PLAYING  
    FIELD:
    
       - symbols AS SUCH
       - numbers AS A SINGLE TYPE
       - strings NOT AS BYTE ARRAYS
       - a single, universal aggregate type (cf. Lua tables, more or  
    less;  Rebol blocks)
       - e-mail addresses, file / directory paths, and general URI types
       - date and time constructions with simple operator arithmetic
       - generic markup constructs (cf. Meijer "Unifying Documents [etc.]")
       - domain names and IP addresses
       - regexes and structural regular expressions
       - generalized patterns for pattern-based dispatch
       - quantities --- numbers with attached dimensionality
       - booleans and *potentially tri-state logic support*
       - ranges and slices
       - some controlled ability to do open classes
       - concurrency constructs AS SUCH
    
    Also:  if your language doesn't include a CPAN / CRAN / etc. repo and  
    package-distribution capability BUILT IN, it's again a non-starter!   
    Dammit, people!
    
    And let's get a few things straight:  I don't care if it's the OS,  
    language, or language-integrated runtime (as opposed to externalized  
    "standard library" or even worse third-party library) but:
    
         - the "operating system" or runtime should provide *real world  
    abstractions*, too
           - higher-level stuff BUILT IN, like:
             - person, group, social network, presence, identity,  
    authority, permission, etc.
             - media objects:  audio, video, pdf, still images, etc. (just  
    a few!)
             - pages, bookmarks, notes, tasks, todo lists, other lists,  
    calendars, events, etc.
             - spreadsheets, charts, diagrams, formulas, maps, etc.
             - tagging rather than hierarchy --- EVERYWHERE
             - workspace, context, orthogonal persistence, location- 
    transparency
             - context awareness, "cluestreams", user activity,  
    remembrance agents enabled / made easy
           - not just multi-core single-machine or homogeneous-cluster  
    programming, but rather:
             - a heterogeneous, loosely-connected, multi-device, multi- 
    input, user-centered universe-of-tools
             - multiple machines, multi-machine-aware tools and objects
               - programmable / multi-machine clipboard / clipping /  
    plumbing
               - scheduling (i.e. cron), rules, etc. (e.g. things like  
    "Puppet" unnecessary!)
               - caching / replicated / fully versioned home dirs, drop  
    boxes, etc.
           - deep support for both client- and server-side personalizable  
    HTTP and mail services
       - handling of disconnection / replication / synchronization
       - dispense with application-level balkanization of data!
       - composition and re-use
    
    
    Grrrr....  it's pretty damn sad that something as limited and now- 
    ancient as bash represents some kind of optimum of productivity for  
    many real-world "everyday programming" tasks --- and yet fails so  
    miserably for so many other everyday programming tasks due to lack of  
    data abstraction and richness.
    
    If I have to write one more polyglot bash / awk / python script to  
    gather data from log files on a bunch of different machines, demux  
    that into a time-ordered event stream, pipe it through something to  
    munge it into some slightly different format, ship that off via post  
    to some web address and get some JSON back, parse that into some other  
    shit, do some computation over it like aggregation or date math over  
    time stamps with unlike representations, wrap the results up in an  
    HTML table and send that table in a MIME-enabled e-mail to myself I  
    think I am going to *explode.*
    
    90% of the shit that gets written doesn't even involve anything as  
    complicated as finding set partitions.  Really.
    
    Somebody do something about this, before I LOSE MY FUCKING MIND!?!?!
    
    
    jb
    
    
    
    
    
      
        
    

* * *
* Previous message: [[FoRK] Phil Agre missing ][2]
* Next message: [[FoRK] Programming languages, operating systems, despair and anger ][3]
* **Messages sorted by:** [[ date ]][4] [[ thread ]][5] [[ subject ]][6] [[ author ]][7]
* * *

[More information about the FoRK mailing list][8]  

[1]: mailto:fork%40xent.com?Subject=Re%3A%20%5BFoRK%5D%20Programming%20languages%2C%20operating%20systems%2C%20despair%20and%20anger&In-Reply-To=%3C429DD459-A9DE-4A4B-8DA3-101DB76C2135%40place.org%3E "[FoRK] Programming languages, operating systems, despair and anger"
[2]: http://www.xent.com/054577.html
[3]: http://www.xent.com/054579.html
[4]: http://www.xent.com/date.html#54578
[5]: http://www.xent.com/thread.html#54578
[6]: http://www.xent.com/subject.html#54578
[7]: http://www.xent.com/author.html#54578
[8]: http://xent.com/mailman/listinfo/fork