Fwd: Re: Paul Graham's PyCon Keynote

[Michael Vanier <address@hidden>]

Forwarded message 1:

> Date: Wed, 09 Apr 2003 16:06:43 -0400
> From: Howard Stearns <stearns@alum.mit.edu>
> 
> [not speaking wrt a particular language or speaker]
> 
> I feel that one source of problems isn't with macros vs strong typing
> per se, but with the compilation constraints that TEND to be associated
> with "good" use of each.  
> 
> In particular:
> 
>   People adept at Lisp-style macros sometimes tend to make heavy use of
> explicit compile-time evaluation and the insertion of complex data
> values as literals in the code.  
> 
>   However, I feel that languages that make effective use of strong
> typing tend to preclude these uses.
> 
> For example, there might be code evaluated at compile-time by macros
> used in different files. The macros communicate with each other by
> manipulating data structures which are referenced in the generated code.
> The linker is expected to be able to load these files in such a way that
> the right data gets loaded and bashed as necessary.  It seems hard (in
> my observation) for strongly-typed compiler writers to stomach support
> for such things.
> 
> Regards,
> Howard Stearns
> 
> 
> Michael Vanier wrote:
> > 
> > Quote: "static typing seems to preclude true macros".
> > 
> > Care to elaborate?  Ocaml has a macro-ish system (camlp4) and I've seen
> > template metaprogramming systems proposed for both ML (meta-ML and
> > meta-ocaml) and haskell.  All of these have something analogous to
> > lisp quasiquote, though I haven't looked into them deeply.
> > 
> > Links:
> > 
> > Camlp4:  http://caml.inria.fr/camlp4/
> > Meta-ML: http://www.cse.ogi.edu/PacSoft/projects/metaml/
> > Haskell: http://www.cse.ogi.edu/~sheard/ (follow the links)
> > 
> > Any comments from experienced users of the above tools (if there are any on
> > this list)?
> > 
> > Mike
> > 
> > > Date: 9 Apr 2003 19:00:51 -0000
> > > From: Paul Graham <pg@archub.org>
> > >
> > > There's now an article derived from this talk at
> > > http://www.paulgraham.com/hundred.html  --pg
> > >
> > > --eli rosenberg wrote:
> > > > Lisp Guru, Yahoo! Store creator, and language designer
> > > > Paul Graham gave the keynote speech at PyCon.  PyCon
> > > > was a great little conference for Python Language
> > > > enthusiastists, with a theme of popularizing the
> > > > Python language and philosophy.  Though I did not
> > > > spend much time at PyCon, I did have the pleasure
> > > > of hearing Paul's speech, so I will briefly
> > > > mention a few of the ideas he covered.  The terminology
> > > > I use is not necessarily the same as Paul's, as I didn't
> > > > take notes.
> > > >
> > > > * The speech centered around the future of programming
> > > > languages, specifically imagining what programming
> > > > will be like in 100 years.
> > > >
> > > > * We are still using paradigms and methods from the 1950s,
> > > > so it is plausible that a creation from today
> > > > would be around in 100 years.
> > > >
> > > > * Paul is critical of Java, of high level languages with
> > > > strong static typing, and believes lower level languages
> > > > should be saved for tasks requiring low level control or
> > > > extreme efficiency.  Even in the far future, some
> > > > programs will be written in low level languages and
> > > > some programs will be written in Fortran (he joked).
> > > > Somebody will always have an application that requires
> > > > maximum computing power.
> > > >
> > > > * Programming will be more oriented towards telling
> > > > the computer what to do, rather than the computational
> > > > steps required to achieve it.
> > > >
> > > > * Programming languages should be for programmers!
> > > >
> > > > * Very high level abstraction will probably come at
> > > > the expense of efficiency, but computers will eventually
> > > > be a million times faster, so inefficiency is fine.
> > > > In fact, inefficiency is good because programmer
> > > > time is cheaper than computer time or computer power.
> > > >
> > > > * Using a core set of axioms and building abstractions
> > > > from these axioms may be a good way to achieve high
> > > > level abstraction, layers of abstraction, or varying
> > > > types of abstraction (domain specific).
> > > >
> > > > * Data will have a more natural appearance, leaving
> > > > details of the representation to the implementors.
> > > > For example, eventually you will not often bother
> > > > with the distinctions between arrays, lists, and strings,
> > > > or perhaps even numbers.
> > > >
> > > > * LISP is good, Macros are good, and SUVs are ugly,
> > > > because they solve an ugly problem- how to make a
> > > > minivan look masculine.
> > > >
> > > > * There is really no such thing as a 'scripting language.'
> > > >
> > > >
> > > >
> > > >
> > > > -eli
> > > >
> > > >
> > >
>