Lambda the Ultimate

Actors seem to allow messages to be recieved in a different order from which they were sent. This sounds a lot like the problems with simultaneity that occur with relativity, effectively messages may take different paths from sender to receiver.

Being an electronics engineer as well as a software developer, the actor model sounds a lot like an asynchronous circuit, which are really difficult to design so they work properly. There is a reason why synchronous design dominates computer architecture, and even this is hard to get right. In synchronous design all messages sent are received at the next clock tick, messages form a stream over pipes. Even so when designing chips we often build a model in 'C' to test the chip against because its so much easier to get sequential code correct.

The ideal solution is to take sequential code like 'C' and compile it to a parallel implementation. The reason, from experience, is that humans are just not good at parallel design. This is even more true of asynchronous design compared to synchronous design.

I am not disputing that actors model communicating processes running on different nodes of a distributed network well. My concern is more that this architecture is only used for very regular problems where a common kernel (or a few different node types as in a map/reduce machine) are distributed because it is difficult to program this way.

Are actors a good model for general computation, or should they only be used when necessary (and when might it be necessary)?

---------------------------------------------------------------------------
6th Workshop on the Evaluation and Usability of Programming Languages and Tools (PLATEAU)

Co-located with SPLASH 2015
Sponsored by ACM SIGPLAN
Pittsburgh, PA, USA

http://2015.splashcon.org/track/plateau2015

CALL FOR PAPERS

Programming languages exist to enable programmers to develop software
effectively. But how efficiently programmers can write software
depends on the usability of the languages and tools that they develop
with. The aim of this workshop is to discuss methods, metrics and
techniques for evaluating the usability of languages and language
tools. The supposed benefits of such languages and tools cover a large
space, including making programs easier to read, write, and maintain;
allowing programmers to write more flexible and powerful programs;
and restricting programs to make them more safe and secure.

PLATEAU gathers the intersection of researchers in the programming
language, programming tool, and human-computer interaction communities
to share their research and discuss the future of evaluation and
usability of programming languages and tools.

TOPICS

Some particular areas of interest are:

- empirical studies of programming languages
- methodologies and philosophies behind language and tool evaluation
- software design metrics and their relations to the underlying language
- user studies of language features and software engineering tools
- visual techniques for understanding programming languages
- critical comparisons of programming paradigms
- tools to support evaluating programming languages
- psychology of programming
- domain specific language (e.g. database languages, security/privacy
languages, architecture description languages) usability and evaluation

SUBMISSIONS

PLATEAU encourages submissions of three types of papers:

Research and Position papers: We encourage papers that describe
work-in-progress or recently completed work based on the themes
and goals of the workshop or related topics, report on experiences
gained, question accepted wisdom, raise challenging open problems,
or propose speculative new approaches. We will accept two types of
papers: research papers up to 8 pages in length; and position papers
up to 2 pages in length.

Hypotheses papers: Hypotheses papers explicitly identify beliefs of
the research community or software industry about how a programming
language, programming language feature, or programming language tool
affects programming practice. Hypotheses can be collected from mailing
lists, blog posts, paper introductions, developer forums, or
interviews. Papers should clearly document the source(s) of each
hypothesis and discuss the importance, use, and relevance of the
hypotheses on research or practice. In addition, we invite language
designers to share some of the usability reasoning that influenced
their work. These will serve as an important first step in advancing
our understanding of how language design supports programmers.Papers
may also, but are not required to, review evidence for or against the
hypotheses identified. Hypotheses papers can be up to 4 pages in
length.

Format: Submissions should use the SIGPLAN Proceedings Format, 10
point font. Note that by default the SIGPLAN Proceedings Format
produces papers in 9 point font. If you are formatting your paper
using LaTeX, you will need to set the 10pt option in the
\documentclass command. If you are formatting your paper using Word,
you may wish to use the provided Word template that supports this font
size. Please include page numbers in your submission. Setting the
preprint option in the LaTeX \documentclass command generates page
numbers. Please also ensure that your submission is legible when
printed on a black and white printer. In particular, please check that
colors remain distinct and font sizes are legible.

All types of papers will be published in the ACM Digital Library at
the authors’ discretion.

Paper Format: http://www.sigplan.org/Resources/Author/
Submission site: https://easychair.org/conferences/?conf=plateau2015

KEYNOTE

Mary Beth Rosson
Professor at Penn State
College of Information Sciences and Technology
Pennsylvania, USA

IMPORTANT DATES
Submission deadline: August 7, 2015

PROGRAM COMMITTEE
Andrew Begel, Microsoft Research, USA
Jeff Carver, University of Alabama, USA
Ronald Garcia, University of British Columbia, Canada
Stefan Hanenberg, University of Duisburg-Essen, Germany
Stephen Kell, University of Cambridge, UK
Brad Myers, Carnegie Mellon University, USA
James Noble, Victoria University of Wellington, New Zealand
Chris Parnin, North Carolina State University, USA
Romain Robbes, University of Chile, Chile
Janet Siegmund, University of Passau, Germany
Andreas Stefik, University of Nevada, Las Vegas, USA
Emma Söderberg, Google, USA

ORGANIZERS
Craig Anslow, Middlesex University, UK
Thomas LaToza, George Mason University, USA
Joshua Sunshine, Carnegie Mellon University, USA
---------------------------------------------------------------------------

I wonder whether we can develop a few simple conventions that clarify what we mean by words when we use them, so a single post has fewer ambiguities, and so we might edit a post later for clarification without substantially altering the original post. The idea would be to define the sense of a specific word used in a post. I'll give an example below, involving channel, since that was the word motivating this train of though. But first I'll expand a bit on my general point.

A word can mean something very specific, or very general, often with both a technical computing sense as well as plain English language sense. In particular, a technical sense often shadows the plain language sense, as if technical meanings have closer lexical scope, so you can't use a more general sense by default unless a reader is forgiving. Sometimes I mean both: a specific technical sense and the general idea too, at the same time, because I expect a reader to bind to as many as works, as if executing a search query on a word database (e.g. all the meanings of channel that work here, for example).

A realistic way to approach the problem is to use footnote format, appending a postscript paragraph to a post that explores the sense of a word used, like a dictionary entry, but biased toward exactly what was intended locally in the current post. The first time channel appears it might be shown in italics, with a paragraph at the end repeating the word again in italics, along with a local clarification of the scope of word meaning as used in the original post.

(An unrealistic but funny way to approach the problem is with new text styles, so the way a word is highlighted might imply whether intended meaning is specific or very general, with the latter especially useful when a word has a narrow technical sense.)

channel - means of getting something to occur: a knob to read and/or write an interface to access data or controls, encompassing things as different as dereferencing a variable, accessing an array member, reading or writing streams, calling functions, or using a datatype named "channel" in a language or computing system.