Better Stories, Better Languages

What do programmers do?

(note: click Ø in the menu on the lower-right to disable slideshow mode)

This Presentation

The Take Home Points

Software tools imply a story.

New stories can help invent new tools.

Explicit stories are a great meta-tool...

Talk Structure: Better Stories

A: Average stories commonly told.

B: Better stories improving upon them.

You: Compare. Agree? Find a pattern?

Average: How to fund software?

Issue: Starved programmers don't code

Story: Owning SW, static Vendor & Customers

Solution: Proprietary SW, One True (Closed) Source

Better: How to fund programming?

Story: Owning Labor, dynamic contributors

Solution: FLOSS, anyone can fork/merge at anytime

Tools: source tuned for open maintenance, DVCS

Average: Decompose programs?

Issue: software is too big to handle in one lump.

Story: hierarchical design in parts; fully informed.

Solution: top-down management, layers.

Better: Decompose programming?

Story: Partial information. Propagator network.

Solution: Packages. Version Control.

Tools: Software Distributions (Debian). DVCS.

A: Get good libraries?

Issue: software components are hard to design

Story: get expertly designed language, library...

Solution: experts standardize now for everyone after

B: Get good expertise?

Story: dynamically delegate responsibility to expert.

Solution: dynamic market in expert service.

Tools: modular system extensions, software repos.

A: Choose features in a PL?

Issue: not every PL is as fit for a problem

Story: Programming languages are for machines

Solution: match machine features, Turing tar pit

B: Express programming ideas?

Story: Programming languages are for humans

Solution: match human cognition & social process

Tools: simpler, cleaner programming languages

A: Handle repetitive programs?

Issue: repetitive programmer behavior

Story: programmer as grunt worker

Solution: Theorize repetitions as Design Patterns

B: Remove programming drudge?

Story: Programmer as abstract thinker

Solution: metaprograms (Turing!)

Tools: PL extensibility (macros, etc.).

A: Have an extensible syntax?

Issue: limitations of a fixed syntax

Lisp Story: side-effect One True Lisp World.

Solution: bind symbols to macros, modify readtable

Problem: new syntax makes your language autistic

B: Explore useful syntaxes?

Story: exploration of many worlds, purely

Solution: scoped syntax extension

Tools: PLT modules, locally extensible grammars

A: Users != Programmers?

Story: speech for users, writing for programmers

Solution: unrelated languages, multiple levels

B: Using = Programming?

Story: no difference b/w using and programming

Solution: integrated interactive interface

Tools: dynamically extended interfaces

A: Programmer != PL Implementer?

Issue: writing a compiler is hard

Story: specialists write compiler, others use

Solution: closed implementation for each language

B: Programming = PL Impl'ing?

Story: special (meta) case of using and programming

Solution: same language can switch level of abstraction

Tools: MOP for DSLs, "A implements B" (PCLSRing)

A: PL Definer != PL Impl'er?

Issue: designing a language is hard

Story: specialists define big language, others implement

Solution: static language, blind spots, slow update, bit rot

B: PL Defining vs PL Impl'ing?

Story: specialists know and implement specialty

Solution: modular language, delegate specialties

Tools: grammatical mixins, monadic lifting

A: Get a specialized language?

Issue: programming involves heterogeneous activities

Story: each activity has its own language

Solution: C, scripting glue, sysadmin tools

B: Specialize conversation?

Story: the same brains do all these different things

Solution: one language w/ many contexts

Tools: universal languages

A: Debugged Programs?

Issue: interrupt, inspect, extend, fix running programs

Story: exceptional situation, retrofit ad-hoc tools

Solution: low-level debugger, ad-hoc debug info

B: Explore Semantics?

Story: compiler as reversible lens, VW controler

Solution: generalize PCLSRing, external meta-info

Tool: dynamic controlling (remote) meta-process

A: Secure software?

Issue: security is a hard, whole system property

Story: get it to run, think about security later

Solution: try retrofit fixes to most glaring leaks

B: Build software securely?

Story: security is a deep component of SW quality

Solution: design SW with security from the start

Tools: capabilities, whole-system protocol design

A: Dealing with catastrophes?

Issue: bad manipulations happen, data gets lost

Story: error is exceptional, catastrophic

Solution: confirm, remove bin, undo last

B: Eliminating catastrophes?

Story: error is normal, casual

Solution: monotonic info, never lose data

Tools: reversible interfaces

A: Write a Contract?

Issue: a PL constrains the contracts you can express

Story: PL as a given. Follow it. Document the rest.

Solution: team division, informal contracts.

B: Agree on Responsibilities?

Story: PL as convention. Extend it.

Solution: Formalize contracts. New formalism if needed.

Tools: DSLs. Better type systems.

A: Arbitrate Resource?

Issue: arbitrate resource, enforce invariant?

Story: Central dictator

Solution: Kernel, needs perfect static model

B: Resolve Conflicts?

Story: Property Law

Solution: self-enforced contracts

Tool: invariant-enforcing linkers, delegated authority

A: Resource Possession?

Issue: who controls (accesses, frees) a resource?

Story: control possible iff low-level

Solution: manual management (C/C++) vs GC

B: Resource Ownership?

Story: essential concurrency b/w H&M processes

Solution: mononotic + linear logic

Tool: pure values vs actor-owned regions

A: Connect Computers?

Issue: technical and social limits of single-machine computing

Story: putting together many different systems

Solution: invoke remote methods, ship information around

B: Distribute Computation?

Story: many agents partake in the same system

Solution: share pure information, manage local state

Tools: content-based addressing, declarative deployment

A: Role = Virtual Machine?

Issue: can't have a single trust domain for everything

Story: when in a mess, virtualize ad-hoc domain

Solution: virtual process, virtual Unix, virtual PC

B: Using = Virtualizing?

Story: everyone is "root" in his Virtual World

Solution: Never log as root. Create your sub-domain.

Tool: PL support for VM. Create a sub-user!

A: Persist important data?

Issue: important data must persist against hw/sw failure

Story: persistence is disjoint from PL design

Solution: ad-hoc files, databases w/o good PL

B: Write persistent software?

Story: persistence is an essential aspect of PL

Solution: integrate persistence & virtualization

Tools: orthogonal persistence, explicit prevalence

A: Model a changing world?

Everything is stateful. Java.

B: Model changes to the world?

Functional programming.

Mostly functional. OCaml, Clojure.

Purity at base-level. Haskell.

Purity at meta-level, too. Unlambda.

C: Discuss relevant change?

Actors encapsulate state. Erlang, Reactive FP.

State is meta-level modularity.

Encapsulate and recapsulate.

Conclusion: The Grand Challenge

None of these Stories is revolutionary.

Each Story has been at least foretold in a past system.

But no system embodies all these Stories at once.

Better Conclusion: The Meta-Story

Average stories are about things.

Better stories are about people making things.

Average stories have early binding of what's Good.

Better stories have early banning of what's Bad.

http://fare.tunes.org/computing/fare-ilc09-lightning.html