Re: Paul Graham's PyCon Keynote

[Paul Graham <address@hidden>]

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
> 
>