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

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