ILC 2003: some impressions

From: Pedro Pinto (ppinto_at_cs.cmu.edu)
Date: 10/16/03 

Date: Wed, 15 Oct 2003 23:05:35 GMT

Just got back from ILC 2003 and I thought I should post some of my notes.

My impressions on the conference are mixed. The lead organizer fell ill
and despite valiant efforts from some of the other organizers, the
feeling of mild chaos was constant. Throughout the conference a complete
schedule (one that included presentation titles) was never posted, some
of the speakers simply did not show up, others did not receive their
schedules until the day of the presentation. Nevertheless the quality of
  some of the talks did make up for the confusion.

Christian Queinnec (http://www-spi.lip6.fr/~queinnec/WWW/Queinnec.html)
tutorial on continuations was outstanding. Queinnec started by
explaining basic CPS. He then introduced call/cc and proceeded to
contrast Scheme continuations with their C and Lisp counterparts,
remarking that Scheme continuations have indefinite extent while in Lisp
and C continuations can only be activated while they are still present
on the stack (i.e. they have dynamic extent). He pointed out that when
coupled with parallel programming continuations pose some interesting
challenges such as possibility for critical regions to be exited more
than once.

Jerry Sussman's (http://www.swiss.ai.mit.edu/~gjs/gjs.html) keynote was
awe inspiring. Having had my brain blown by SICP I was very excited by
the prospect of attending his presentation and I was not disappointed.
Sussman's passion these days is teaching and that was obvious from his
talk. Sussman contends that the greatest achievement of 20th century
computer science is not the computer or the network. Instead he argues
that the development of languages that can be used to precisely specify
processes or algorithms is of greater significance. In their efforts to
devise notations that can be used to explain computers how to do things
like square roots or Lagrange equations, Computer Scientists ended up
creating new kinds of languages for human expression. Such languages
happen to be executable by machines, but Jerry feels this is of
secondary importance compared to their use as tools for precise human
reasoning and communication, particularly in teaching. He has
investigated this insight while teaching classical mechanics at MIT.
The idea of programming languages in general and Scheme in particular as
tools for expressing processes was already present in SICP and seems to
be further explored in Jerry's new book, "Structure and Interpretation
of Classical Mechanics" .

Gregor Kiczale's (of MOP fame) (http://www.cs.ubc.ca/~gregor/)
presentation on Aspect Oriented Programming (AOP) was also fascinating.
Kiczales suggested that the Lisp/Scheme community, because of its love
for beautiful code, is particularly well suited to explore what he
considers to be the brand new design territory introduced by AOP. I had
no previous exposure to AOP so I apologize in advance for any
mischaracterizations. Hopefully any blunderings will be irritating
enough for someone to correct them. AOP introduces the notion of joint
points: basically locations in a running program where control leaves a
method to enter another method. Using a declarative language to define
sets of joint points based on their static or dynamic properties
(including method signatures and call graph information) AOP allows the
programmer to associate code to be executed after, before or around any
joint points in these sets. This allows the modularization of, well,
aspects of the code that cross cut modules and that would otherwise be
sprinkled through out the program. Typical examples of such aspects
include logging, transaction management, locking and display updating.
Kiczales mentioned that one typical initial use of AspectJ (an
instantiation of AOP for Java) is in debugging. Initially users can use
AspectJ simply as a debugging aid to add tracing information to relevant
portions of development code, while still using the vanilla Java
compiler for production builds. Later as the usefulness of the tool
becomes clear, production uses start to emerge. For more practical
information on AOP Kiczales recommends "Aspect J in action"
(http://www.manning.com/laddad/)

Espren Verste gave a very interesting talk on the use of Lisp in the
real world. His employer, Net Fonds - a Norwegian online broker, uses
Lisp daily in the majority of their systems, including a cross-platform
(Linux, Windows, Mac) desktop GUI application developed in Lispworks and
used by Net Fonds clients to monitor stock performance and execute trades.

Antonio Leitão (http://www.evaluator.pt) presented Linj, a fascinating
Lisp to Java compiler. Using some clever heuristics Linj is able to
infer type information from Lisp code and use that information to
generate readable Java code. Additionally full access to the Java API is
possible. Antonio developed this tool in response to some of his
client’s requirement to have solutions implemented in Java. He has been
using this tool for several years and has been able to achieve CL levels
of productivity while still keeping the PHBs happy.

These are only some of the talks. Hopefully others attendees will
provide more information as well as correct any errors or omissions.

-pp

Relevant Pages

  • Re: Symbol Grounding Problem
    ... yet insist that Lisp is more powerful than Java. ... A programming language is "powerful" if it provides the computation substrate ... This is the sense in which Lisp is generally "more ...
    (comp.ai.philosophy)
  • Re: Lisp for enterprise computing?
    ... "the programmable programming language"... ... since it may be a while before I know Lisp enough to be able to find ... software than your current large team of idiot Java programmers. ... Including one significant one at the language ...
    (comp.lang.lisp)
  • Re: Lisp for enterprise computing?
    ... "the programmable programming language"... ... since it may be a while before I know Lisp enough to be able to find ... software than your current large team of idiot Java programmers. ... Including one significant one at the language ...
    (comp.lang.lisp)
  • Re: Common Lisp from a Unix perspective - barriers to using CL
    ... * Documentation for introducing Lisp to existing programmers is poor; ... IMO, tutorials should be "hands on", where the newcomer gets to ... modern programming is often lacking and/or hard to find. ... Java basically does it that way, ...
    (comp.lang.lisp)
  • Re: Why Lisp will never go out of style
    ... >> programming language (next to Lisp, of course), and I hate it. ... >> Java class, we have to use multiple arrays, or an arraylist, which is ...
    (comp.lang.lisp)
Loading