NEPLS should strive to follow and foster the following tenets:
Research is often a social activity, and NEPLS is a
watering hole for researchers. Hosts should try to enhance
the potential for social interaction, picking venues and
The event is largely non-competitive. There will usually be
only a few more requests to speak than available slots.
Speakers should therefore temper their talks to a broad
audience, rather than try to dazzle their colleagues as they
might be tempted to at, say, a conference.
While NEPLS does offer its attendees a venue to hear about
the best and brightest recent work, it also affords more
incipient work a chance to garner some public review and,
hopefully, useful recommendations. It also gives students
an opportunity to observe projects at intermediate points in
their trajectory, and to seek counsel on their own work in a
more nurturing environment than the typical conference.
Because attendees represent great diversity within the PLS
field, NEPLS both needs and should solicit tutorial talks.
In contrast to conferences, which are (largely) unwilling to
accept tutorial papers, recognition at NEPLS should serve as
an incentive to construct tutorials.
NEPLS should try to meet three times a year: once each in
the spring, summer and fall.
A month into each period seems to be a good time to meet.
This dodges the academic hiring season, the peak vacation
period, the worst of winter weather, and most final exams.
NEPLS should try to avoid meeting soon before or after
meetings of NJPLS (which seems to have a roving home)
and the Programming Languages Day at
IBM Watson. It should also take conference deadlines
NEPLS should strive to be ``regional''. This means events
shouldn't be clustered in one city or region. A tentative
``regionality'' test is that at least one event each year
should be in a venue not easily reachable from the coastal
NEPLS should also recognize that Boston has a preponderance
of researchers in this field. This may mean that one
meeting each year convenes in Boston.
Each meeting will have a three-member speaker selection
committee, consisting of the former, current and next hosts.
The host will try to ensure that the committee represents a
mix of both ``theory'' and ``systems''. The term
systems should be construed to mean people who
either implement and distribute software or analyze the
performance of computer systems, so long as there's a
significant linguistic angle: typically, compiler writers,
environment builders, or garbage collection analysts.
Speakers will petition for a slot length. Slots can be
between 15 and 60 minutes long (including discussion). The
committee may grant a different slot length than requested
either longer, because they believe the topic needs
more preliminary exposition, or shorter, because they feel
the contribution is smaller than advertised. The committee
should remind speakers given a longer slot to use the extra
time for a tutorial, not to cram in additional research
The event should meet from about 10am to about 4pm. It
should start late enough and end early enough to allow
people who need to travel about three hours to attend.
The host venue does not need to provide lunch, though in
this case they should have information handy on where
attendees can find lunch, hopefully nearby. Hosts should
account for dietary preferences such as kosher, abstinence
from pork, and vegetarianism.
Events should have several breaks; ideally, there should be
no more than two talks in a row. Breaks double up as buffer
time to guard against sessions that overflow their allocated
Hosts should try to organize tool demos, and encourage tool
writers to demonstrate their work-in-progress.