Epigrams on programming, and Bicicleta

[Kragen Javier Sitaker]

In 1982, Alan Perlis wrote a widely-quoted series of epigrams on
programming.  All the good programmers I know recognize deep truths in
many of these epigrams, but some are enigmatic, and I have come to find
new meanings in many of them that I missed at first.  Sometimes, I'm
embarrassed to think of what I used to think some of them meant.

I'm engaged in developing a revolutionary new programming environment
called Bicicleta, which I described a little bit in my earlier
kragen-tol posts, "functional programming for amateurs in an outliner"
and "towards a modern programming environment".  It's unusual in many
ways, and it's sometimes difficult to explain to other people why I'm
making certain choices in its development.  Perhaps a screencast will
help, when it reaches a sufficiently mature stage of development.

I'm calling it Bicicleta for four reasons:
1. A human being on foot is slower than any other land animal of the
   same size; but a human being on a bicycle can go 80MPH, faster than
   any other land animal.  Bicicleta is a bicycle for your mind.
2. According to folklore.org, the above anecdote was a favorite of Steve
   Jobs's during the early development of the Macintosh, and for a time
   it looked like the new machine might be called Bicycle.  If it's
   successful, Bicicleta will change the way people interact with
   computers as much as the Macintosh did, and in many of the same ways:
   it will make difficult things easier for experts, and it will make it
   possible for amateurs to do things that previously required experts.
3. There's already software called Bicycle and lots of software about
   bicycles, but "Bicicleta" is far more googlable.  I plan to spend the
   next several years of my life in Spanish-speaking countries, talking
   mostly to speakers of Spanish, so a Spanish name seems reasonable.
4. "Functional Programming for Amateurs in an Outliner" is too long and
   contains at least three words that scare or offend some people.
   (Maybe I shouldn't worry about this, follow the lead of the Bell Labs
   folks, and call it Castrado or something.)

Rereading Perlis's epigrams, I was struck by how relevant they are to
these difficult-to-explain aspects of Bicicleta.  I thought I would try
to explain Bicicleta in terms of comments on some of the epigrams.  So I
have selected 34 of the 120 epigrams, and added comments.  Probably I'll
be embarrassed when I look back in a few years and see what I used to
think some of these epigrams meant.

1. One man's constant is another man's variable.
   In Bicicleta, every named constant is a potential parameter, with its
   originally specified value as a default.

2. Functions delay binding; data structures induce binding. Moral:
Structure data late in the programming process.
   In Bicicleta, data structures are replaced by, in essence, functions
   with multiple named return values.  Consequently it is never too late
   to restructure the data.

3. Syntactic sugar causes cancer of the semicolon.
   Bicicleta's basic syntax can be written down in a few lines, but it
   does have syntactic sugar.

6. Symmetry is a complexity-reducing concept (co-routines include
subroutines); seek it everywhere.
   Bicicleta uses the same construct to replace the data structure,
   the procedure, the function, the object, the class, and the module.
   Thus many classical OO refactorings become no-ops.

7. It is easier to write an incorrect program than understand a correct
one.
   Bicicleta supports interactive experimentation, so that you can
   understand correct programs more quickly, and find the bugs in your
   incorrect programs as well.

11. If you have a procedure with ten parameters, you probably missed
some.
   Bicicleta allows the caller to override the value of any variable in
   the routine they call.

15. Everything should be built top-down, except the first time.
   To support bottom-up programming, Bicicleta programs execute on
   example values as you write them, so that you can see if they do what
   you wanted; to support top-down programming, it's easy to stub out
   lower-level parts of your code.

19. A language that doesn't affect the way you think about programming,
is not worth knowing.
   Bicicleta differs fundamentally from every well-known or widely-used
   programming language.

22. A good system can't have a weak command language.
   Bicicleta's concise and limitless programming language works for
   manual interaction with your data as well as writing programs to be
   reused, and there is a smooth slope between the two.  It's so good
   that the programming environment itself serves as the user
   interface for many Bicicleta programs.

24. Perhaps if we wrote programs from childhood on, as adults we'd be
able to read them.
   Bicicleta helps children write programs in two ways: first, its
   immediate and visual nature enables them to create programs more
   easily than traditional systems, and children can study and modify
   existing programs in Bicicleta more easily than in traditional
   systems, because it is easy to inspect their execution.

25. One can only display complex information in the mind. Like seeing,
movement or flow or alteration of view is more important than the static
picture, no matter how lovely.
   Bicicleta makes it instant and easy to see what a program would do if
   invoked a little differently; while, of course, no system can make it
   easy to understand a complex program, this ability speeds the process
   up a bit.

26. There will always be things we wish to say in our programs that in
all known languages can only be said poorly.
   The usual solution to this problem is to invent a new domain-specific
   language, which can either be a standalone language or embedded in an
   existing language.  Existing languages vary in how well they support
   embedding domain-specific languages in them.  Bicicleta is close to
   Scheme's and Haskell's excellence here.

28. Around computers it is difficult to find the correct unit of time to
measure progress. Some cathedrals took a century to complete. Can you
imagine the grandeur and scope of a program that would take as long?
   Today, we have programs and libraries that have taken 20 or 30 years
   --- Emacs, DB2, Oracle, BSD, Nethack, SAS, Ingres/PostgreSQL, BRLCAD,
   GCC, and, of course, OS/360/z/OS, VMS, and Microsoft Windows.
   Grandeur is not the first term that comes to mind.  "Rococo, then
   rubble," seems more apt.  Perhaps this is because each new generation
   of masons cannot understand the work of their fathers, or feels
   incompetent to change it?  Bicicleta, more than anything else,
   supports the understanding of existing Bicicleta programs in an
   unprecedented way.

30. In programming, everything we do is a special case of something more
general -- and often we know it too quickly.
   Bicicleta is designed to turn this weakness into a strength, by
   smoothing the path from a solution to a specific case of a problem to
   a more general solution.

35. Everyone can be taught to sculpt: Michelangelo would have had to be
taught not to. So it is with great programmers.
   I began programming when I was 4, and when no computer is handy, I
   write programs with pen and paper.  But I do not think I am yet a
   great programmer; I have only had 25 years to learn, and I wasted ten
   of them not learning because I thought I was a great programmer.
   Perhaps in another 15 years I will be a great programmer.

39. Re graphics: A picture is worth 10K words - but only those to
describe the picture. Hardly any sets of 10K words can be adequately
described with pictures.
   Consequently, the user interface of Bicicleta is still essentially
   textual in nature, although it accommodates pictures and uses
   visual organization.

42. You can measure a programmer's perspective by noting his attitude on
the continuing vitality of FORTRAN.
   My perspective is that FORTRAN has begun to absorb progress, and its
   continuing vitality is a testament to the importance (above all else)
   of language implementation quality, which in this case has won out
   over language design quality.

43. In software systems, it is often the early bird that makes the worm.
   Bicicleta is a radical rethinking of some of our oldest worms: the
   nature of the source/execution distinction, the program/data
   distinction, the definition/use distinction, and the development/use
   distinction.  None of these distinctions disappear, but they change
   in nature.  Such a rethinking is long overdue.

51. Bringing computers into the home won't change either one, but may
revitalize the corner saloon.
   And today we have computers in our homes recycling software systems
   designed for use in research labs and hierarchical office
   environments.  It is time to change the way we interact with
   computers again, as fundamentally as the Macintosh did.

57. It is easier to change the specification to fit the program than
vice versa.
   This is often because the program, once written, was practical to
   write, or to use; while no program that fits the specification was.

59. In English every word can be verbed. Would that it were so in our
programming languages.
   In Bicicleta, the distinction betwen data structure and function,
   noun and verb, disappears from the language and remains only as a
   property of how different things are used.  This is possible because
   it is purely applicative.

68. If we believe in data structures, we must believe in independent
(hence simultaneous) processing. For why else would we collect items
within a structure? Why do we tolerate languages that give us the one
without the other?
   Data structures make programming easier; in the absence of parallel
   hardware, concurrent shared-mutable-memory programs only make it
   harder.  Perhaps a different programming paradigm will change this.
   Bicicleta is purely applicative, which offers one way out.

74. Is it possible that software is not like anything else, that it is
meant to be discarded: that the whole point is to see it as a soap
bubble?
   Bicicleta is designed with the idea that ephemeral programs quickly
   thrown together by end-users are as important as the more enduring
   and carefully crafted artifacts upon which they build.  Burning Man
   has changed me, as has Excel.

76. It is the user who should parameterize procedures, not their
creators.
   Any caller of a Bicicleta procedure can override the value of any
   variable, up to and including the return value.

94. Interfaces keep things tidy, but don't accelerate growth: Functions
do.
   In Bicicleta, as in Smalltalk or Python, any object can be replaced
   by another that implements the same (subset of its) interface that
   its callers demand, so interfaces are implicit; and any object
   attribute can contain functional computation.

100. We will never run out of things to program as long as there is a
single program around.
   Bicicleta expands the set of people who can write any particular
   program, and reduces the effort required, by reducing the gulfs of
   evaluation and action and by making it easier to study the work of
   others.  This only makes sense if you believe in the above epigram.

103. Purely applicative languages are poorly applicable.
   Certainly this was true in 1982; perhaps today Haskell provides a
   counterexample, or perhaps not.  Bicicleta will fail if it turns out
   to be an immutable truth.

104. The proof of a system's value is its existence.
   Bicicleta does not yet exist, so its value is unproved.

106. It's difficult to extract sense from strings, but they're the only
communication coin we can count on.
   Consequently, Bicicleta stores its programs as strings that you can
   send to other people in email or keep in your Darcs or Subversion
   repository; but it provides a user interface that supports the
   programmer in their attempts to understand the programs much better
   than reading the raw strings could.

108. Whenever two programmers meet to criticize their programs, both are
silent.
   Unless they are competent, in which case either one can talk for
   hours about the flaws in their own program.

109. Think of it! With VLSI we can pack 100 ENIACS in 1 sq. cm.
   Yet we cannot yet sell 100 ENIACs to every citizen of the world,
   because they can't yet program them, and because our computers are
   designed for US businesses, who will pay hundreds of dollars for one.

115. Most people find the concept of programming obvious, but the doing
impossible.
   Bicicleta is designed to change this.

117. It goes against the grain of modern education to teach children to
program. What fun is there in making plans, acquiring discipline in
organizing thoughts, devoting attention to detail and learning to be
self-critical?
   Bicicleta does not eliminate these requirements of programming, but
   it does eliminate other unnecessary barriers to children programming:
   the difficulty of imagining in your head events that you can never
   see, for example.

120. Adapting old programs to fit new machines usually means adapting
new machines to behave like old ones.
   As true today as ever.  Much of my computing time today, before
   Bicicleta, is spent using my laptop to run Emacs in full-screen mode,
   editing code and compiling it with a batch-mode compiler ---
   effectively, I'm emulating a space-cadet-keyboard video terminal
   talking to a PDP-10, except that some joker labeled my Meta key
   "Alt", and I'm writing C instead of Lisp.  I'm developing Bicicleta
   in Squeak, which pretends my 3D-accelerated video card is a
   framebuffer on a colorized Alto that can barely blit by itself.