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

Jeff Bone jbone at place.org
Thu Nov 12 11:08:40 PST 2009


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





  
    


More information about the FoRK mailing list