Meeting 2014
- Dates: Sunday, June 1 - Friday, June 6, 2014
- Venue: Skamania Lodge, near Portland, Oregon
- Host: Andrew Black
Skamania Lodge
I have made arrangements for five nights (Sunday to Thursday inclusive) at Skamania Lodge, http://www.skamania.com, a beautiful resort about 45 minutes drive from Portland International Airport (PDX). I have negotiated a room rate of $110 per room per night (subject to sales tax, which is currently 7.7%, and occupancy tax, which is currently 2%). There is also a resort fee of $17 per room, which includes unlimited free local calls; 24 hour access to Technology Room; wireless high-speed internet in guestrooms, Gorge Room, Cascade Dining Room and River Rock Lounge; access to three scenic hiking trails, family putting green, health club, pool and outdoor hot tub; tennis and basketball court time; bike rentals parking, coffee in the main lobby; and a copy of the USA Today Newspaper. Total per room per night will thus be about $138. If you find this rate too high, there is always the option of sharing a room with another attendee, which will halve the rate. To lock in this rate, you need to book your room by 28th March. Either telephone 800-221-7117 (+1 509 427 7700 from outside the USA), or go to http://www.skamania.com, and use group code 1XQ1P4 in the "Reserve a room" box at the top of the web page. (Click on Promo Code; enter the group code, and then click BOOK NOW. Alternatively, use this link to insert the dates and group code for you). After 28th March date, rooms may still be available, but may be at a higher rate. Also, the group may be subject to a penalty. So, please book early! Skamania has an excellent restaurant, and less formal dining in the bar. I have negotiated a meal plan for us to eat together in as a group, starting with breakfast on Monday, and finishing with lunch on Friday. The meeting fee will be $500, which includes registration, audio-visual services, use of the meeting facilities, meals, and an off-site excursion. You should plan to arrive at Skamania on Sunday evening, 1st June. Dinner on Sunday is not included in the meeting fee, but there are good options for food at the resort. The meeting will commence at 9am on Monday 2nd June, and finish with lunch on Friday, 6th June.Transportation
The nearest airport is Portland International Airport (PDX) in the eastern suburbs of Portland, Oregon, about 50 miles west of Skamania. PDX is well-served by internal flights from all over the USA, and by international flights from Tokyo, Vancouver, Canada, and Tornonto Canada. Portland also has a Railway station with long-distance trains to Seattle, Oakland, and Chicago. The MAX light rail system connects the Railway station to the airport. It's impractical to get to Skamania by public transport. I'm hoping that enough members have chosen to drive to Skamania, or rent a vehicle, that we are not going to hire a private bus. However, this means that you will need to coordinate ride shares amongst yourselves. Please update the spreadsheet to indicate your flight into PDX, your scheduled arrival time, and the names of the people that you plan to ride with. In case the self-organization fails, Robert Dockins (a postdoc here at PSU) has offered to rent a vehicle and drive the extra people to Skamania � taking as many trips as necessary. If you wish to rent a car from PDX, the cheapest option appears to be Alamo, which operates from an off-airport lot (they have a shuttle pickup). Rates start at $30 per day for a midsize car ($218 per week).Driving from PDX
The simplest route is to head South on I-205 from the airport for 1.5 miles, and then East on I-84, signposted "The Dalles". This will take you into the Columbia River Gorge on the South (Oregon) side of the River. After 36 miles, get off I-84 in Cascade Locks, cross over the Bridge of the Gods into Washington. On the Washington side of the Columbia River, turn right on WA Route 14; Skamania Lodge will be on your left in 1.5 miles. The trip should take about 45 minutes. If you have time to spare, it is well worth while getting off of I-84 East in Troutdale (Exit 17) and taking the Columbia Gorge Scenic Highway instead of the interstate. The Scenic Highway will rejoin I-84 in Warrendale, at exit 24. The Columbia Gorge Scenic Highway will give you magnificent views and the chance to see several waterfalls and take some short walks.Registration
Once you book with the lodge please register here so that we can plan meals, transport, and the excursion.Excursion
On Wednesday afternoon, we will take an excursion to see some local sights in the Columbia River Gorge, followed by dinner at a restaurant in Hood River. Details hereSchedule
For this meeting we are going to try a slightly different schedule than usual. Rather than meeting all day and socializing at night, we will have afternoons off and have meetings before and after dinner. You can use the afternoons for walks, discussions, work, or whatever you want. Thus, the schedule will look as follows on Monday, Tuesday, and Thursday:- 07:00 to 09:00: breakfast
- 9:00 to 12:30: meeting (3.5 hrs)
- 12:30 to 13:30: lunch
- 13:30 to 17:00: break
- 17:00 to 19:00: meeting (2 hrs)
- 19:00 to 20:30: dinner
- 20:30 to 22:00: meeting (1.5 hrs)
- 07:00 to 09:00: breakfast
- 9:00 to 12:00: meeting (3 hrs)
- 12:00 to 13:00: lunch
- 13:00 to 22:00: excursion, including dinner
- 09:00 to 12:00: meeting (3 hrs)
- 12:00 to 13:00: lunch
- 13:00 end of the meeting
Proceedings
Sean McDirmid: Programming with Managed Time in Glitch
Most programming languages expose the hardware’s ability to update global state at any time, leaving programmers to carefully coordinate state updates; an especially tricky task for reactive, concurrent, incremental, or iterative behaviors. As observed by Jonathan Edwards, just as languages runtimes now liberate us from meticulously allocating and freeing memory, they could also properly order state updates for us. In this spirit, we propose a new programming model, Glitch, where all updates between external events appear to execute simultaneously through a combination of incremental replay and update rollback. Programs in Glitch are then immediately responsive to event-induced changes, are iterative without extra logic, and are deterministic in their concurrency. By rationalizing state update, program executions in Glitch can also be replayed in an IDE, and can be revised incrementally under arbitrary code changes.
Mads Torgersen: Opening up C#
The C# team is changing its ways: the C# compiler is rewritten (in C#) with a public API that is immutable, efficient, detailed and full-fidelity. The whole compiler code base is open source. Language design notes are public – everyone gets to see how the sausage is made. In the talk I’ll give the lay of the land and see where the discussion goes. One interesting aspect is whether this codebase is interesting for teaching: the industry has come a long way since the dragon book.
Jonathan Edwards: Two-way Dataflow
Subtext is an experiment in radical simplification of application programming. The goal is to combine the power of frameworks like Rails and iOS with the simplicity of a spreadsheet. Mutable state is a notorious source of complexity in application programming and indeed has long been a central concern in programming language design. I propose a new approach called two-way dataflow which breaks the program into cyclic output and input phases. Output is handled with a form of pure lazy functional programming. Input is governed by a new semantics called one-way action which is a highly restricted form of event-driven imperative programming. Two-way dataflow has been designed not only to simplify the semantics of imperative programming but also to allow a representation in the IDE that, like a spreadsheet, provides a fully WYSIWYG programming experience.
Adam Chlipala: Separating Functionality and Optimizations: A New Programming Paradigm Enabled by Formal Methods?
Programming language design has progressed largely through the invention of new mechanisms for abstraction and modularity. We often expect our languages to enforce modularity, rejecting programs that would break abstraction boundaries. One important sort of modularity has largely eluded us: separating the functionality of a program from the optimizations that lead us to a performant enough implementation. To understand a program, a reader must wade through optimizations that obscure the underlying intent and structure. How might we get a programming language to enforce correct schemes of separating functionality and optimizations? Traditional modularity mechanisms don’t seem up to the challenge, considering the breadth of optimization techniques that programmers feel compelled to apply in different contexts.
I suggest that we use one of the strongest known modularity mechanisms: formal (machine-checked) proof of adherence to specifications. A well-designed specification language lets us say exactly what we mean to say, in as few lines of code as possible. A well-designed proof system gives us plenty of flexibility in demonstrating why a program module meets its specification. These are the ingredients we need to support language-enforced modularity between features and optimizations.
In particular, we are working on a system codenamed Fiat, a library within the Coq proof assistant. The unifying metaphor is correct-by-construction program refinement, an idea with a venerable history in the world of program synthesis. The “functionality” part of a program can be a program with some nondeterministic operations. Our goal is to replace the nondeterminism with efficient code, in a logically sound way called refinement. Any notation for writing down refinement strategies constitutes the “optimizations” part of a program; mistakes in it cannot lead to “breaking the semantics” of a program, since Coq is checking each of our refinements, which must be proved correct. I will demo some of our experiments so far, refining SQL-style specifications into decently efficient functional programs.
Tom van Cutsem: The rise and fall (and rise?) of distributed programming languages
Context/abstract: the 1970’s and ’80s marked an era of innovation in the domain of distributed programming languages. Innovative languages such as Argus (Liskov et al), Emerald (Jul, Black et al), Occam (May, Hoare et al), Erlang (Armstrong et al), Modula-3 (Cardelli et al), etc. were all designed during those days. In the ’90s, with the emergence of Java, we saw a shift toward so-called “middleware”, such as Java RMI, CORBA, etc. where most distributed systems concerns were no longer dealt with in the programming language. Today, these object-oriented middleware systems are in turn largely superseded by “service-oriented architectures”, web services or resource-oriented REST architectures. Whatever happened to good old distributed programming languages? Have they failed? If so, why? If not, why are they receiving so little attention? What can we learn from the past to improve the future of distributed programming abstractions?
James Noble: Capabilities, Trust, and Risk
The Escrow Exchange Contract has been used as a case study of building up complex and trustworthy systems from basic object capabilities, {in the context of concurrent and distributed programming. I’ll present a Rational Reconstruction of the Escrow Exchange Contract case study, expressed in Grace, concentrating on the most essential issues of trustworthiness, and ignoring issues to do with distribution or more complex protocols.
Roberto Ierusalimschy: OO in Lua (or DIY OO Systems)
Lua presents a very basic and simple class-based object-oriented model. In this talk, I discuss how we can build rich prototype-based object-oriented models on top of the original simple model.