[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Paul Graham's PyCon Keynote
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.
Haskell: http://www.cse.ogi.edu/~sheard/ (follow the links)
Any comments from experienced users of the above tools (if there are any on
> Date: 9 Apr 2003 19:00:51 -0000
> From: Paul Graham <firstname.lastname@example.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