Fwd: Re: Paul Graham's PyCon Keynote

[Michael Vanier <address@hidden>]

Forwarded message 2.

> Date: Wed, 09 Apr 2003 16:40:25 -0400
> From: Howard Stearns <stearns@alum.mit.edu>
> 
> Java does let you hack a lot of explicit run-time loading. And there are
> Lisp-like macro packages for Java and Java-like languages. However, the
> ones I know of (and that's not saying much) don't let you insert complex
> literals into the generated code. 
> 
> I suppose you could develop your own mechanisms through run-time
> loading, and clean up that interface through more macros. But my
> intuition is that you'd have trouble coordinating between separate
> invocations of the macros, and that it would be tough to make your
> run-time hand-loading of classes consistent with whatever benefits
> you're supposed to get from the static type compilation. 
> 
> Michael Vanier wrote:
> > 
> > Howard,
> > 
> > Can I forward this comment to the ll1 list?  I agree that many static
> > languages don't like to do things like load modules at run time, but others
> > (notably java) are OK with it (these being less strict about static typing).
> > 
> > Mike
> > 
> > > 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
> > > > > >
> > > > > >
> > > > >
> > >
>