Lambda the Ultimate

For more details, see http://cufp.org/2014cfp

Workshop for
Commercial Users of Functional Programming 2014
Sponsored by SIGPLAN
CUFP 2014
Co-located with ICFP 2014
Gothenburg, Sweden
Sep 4-6
Talk Proposal Submission Deadline: 27 June 2014
CUFP 2014 Presentation Submission Form
The annual CUFP workshop is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work.

Giving a CUFP Talk

If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the workshop. We're looking for two kinds of talks:

Experience reports are typically 25 minutes long, and aim to inform participants about how functional programming plays out in real-world applications, focusing especially on lessons learned and insights gained. Experience reports don't need to be highly technical; reflections on the commercial, management, or software engineering aspects are, if anything, more important.

Technical talks are also 25 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of programmers.

We strongly encourage submissions from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never presented at a conference before. We recognize that inclusion is an important part of our mission to promote functional programming. So that CUFP can be a safe environment in which participants openly exchange ideas, we abide by the SIGPLAN Conference Anti-Harassment Policy.

If you are interested in offering a talk, or nominating someone to do so, please submit your presentation before 27 June 2014 via the

CUFP 2014 Presentation Submission Form

You do not need to submit a paper, just a short proposal for your talk! There will be a short scribe's report of the presentations and discussions but not of the details of individual talks, as the meeting is intended to be more a discussion forum than a technical interchange.

Nevertheless, presentations will be video taped and presenters will be expected to sign an ACM copyright release form.

Note that we will need all presenters to register for the CUFP workshop and travel to Gothenburg at their own expense.

Program Committee

Edward Kmett (McGraw Hill Financial), co-chair
Marius Eriksen (Twitter, Inc.), co-chair
Ozgun Ataman (Soostone, Inc.)
Tim Chevalier (AlephCloud)
Derek Elkins (Now Business Intelligence)
Matthew Might (University of Utah)
Richard Minerich (Bayard Rock)
Audrey Tang (Apple, Inc.)
Jason Zaugg (Typesafe)
More information

For more information on CUFP, including videos of presentations from previous years, take a look at the CUFP website at http://cufp.org. Note that presenters, like other attendees, will need to register for the event. Presentations will be video taped and presenters will be expected to sign an ACM copyright release form. Acceptance and rejection letters will be sent out by July 16th.

Guidance on giving a great CUFP talk

Focus on the interesting bits: Think about what will distinguish your talk, and what will engage the audience, and focus there. There are a number of places to look for those interesting bits.

Setting: FP is pretty well established in some areas, including formal verification, financial processing and server-side web-services. An unusual setting can be a source of interest. If you're deploying FP-based mobile UIs or building servers on oil rigs, then the challenges of that scenario are worth focusing on. Did FP help or hinder in adapting to the setting?

Technology: The CUFP audience is hungry to learn about how FP techniques work in practice. What design patterns have you applied, and to what areas? Did you use functional reactive programming for user interfaces, or DSLs for playing chess, or fault-tolerant actors for large scale geological data processing? Teach us something about the techniques you used, and why we should consider using them ourselves.

Getting things done: How did you deal with large software development in the absence of a myriad of pre-existing support that are often expected in larger commercial environments (IDEs, coverage tools, debuggers, profilers) and without larger, proven bodies of libraries? Did you hit any brick walls that required support from the community?

Don't just be a cheerleader: It's easy to write a rah-rah talk about how well FP worked for you, but CUFP is more interesting when the talks also spend time on what doesn't work. Even when the results were all great, you should spend more time on the challenges along the way than on the parts that went smoothly.

From this article on Boeing moving applications to the cloud:

The application is about 10-years-old, developed with Visual Basic and the .NET Framework. When rewriting the application for the cloud, Boeing chose Azure because it was already using Microsoft technology.

And people are snarky about companies still using COBOL? Really?!

Hi all,

The paper deadline is a few short weeks away, but thought some here might be interested in this call..

2nd ACM SIGPLAN International Workshop on
Functional Art, Music, Modelling and Design
http://functional-art.org

Gothenburg, Sweden; 6 September, 2014

The ACM SIGPLAN International Workshop on Functional Art,
Music, Modelling and Design (FARM) gathers together people
who are harnessing functional techniques in the pursuit of
creativity and expression.

Functional Programming has emerged as a mainstream software
development paradigm, and its artistic and creative use is
booming. A growing number of software toolkits, frameworks
and environments for art, music and design now employ
functional programming languages and techniques. FARM is a
forum for exploration and critical evaluation of these
developments, for example to consider potential benefits of
greater consistency, tersity, and closer mapping to a
problem domain.

FARM encourages submissions from across art, craft and
design, including textiles, visual art, music, 3D sculpture,
animation, GUIs, video games, 3D printing and architectural
models, choreography, poetry, and even VLSI layouts, GPU
configurations, or mechanical engineering designs. The
language used need not be purely functional (“mostly
functional” is fine), and may be manifested as a domain
specific language or tool. Theoretical foundations, language
design, implementation issues, and applications in industry
or the arts are all within the scope of the workshop.

Submissions are invited in two categories:

* Full papers

5 to 12 pages using the ACM SIGPLAN template. FARM 2014
is an interdisciplinary conference, so a wide range of
approaches are encouraged and we recognize that the
appropriate length of a paper may vary considerably
depending on the approach. However, all submissions must
propose an original contribution to the FARM theme, cite
relevant previous work, and apply appropriate research
methods.

* Demo abstracts

Demo abstracts should describe the demonstration and its
context, connecting it with the themes of FARM. A demo
could be in the form of a short (10-20 minute) tutorial,
presentation of work-in-progress, an exhibition of some
work, or even a performance. Abstracts should be no
longer than 2 pages, using the ACM SIGPLAN template and
will be subject to a light-touch peer review.

If you have any questions about what type of contributions
that might be suitable, or anything else regarding
submission or the workshop itself, please contact the
organisers at:

workshop2014@functional-art.org

KEY DATES:

Abstract (for Full Papers) submission deadline: 7 May
Full Paper and Demo Abstract submission Deadline: 11 May
Author Notification: 30 May
Camera Ready: 18 June
Workshop: 6 September

SUBMISSION

All papers and demo abstracts must be in portable document
format (PDF), using the ACM SIGPLAN style guidelines. The
text should be in a 9-point font in two columns. The
submission itself will be via EasyChair. See the FARM
website for further details:

http://functional-art.org

PUBLICATION

Accepted papers will be included in the formal proceedings
published by ACM Press and will also be made available
through the the ACM Digital Library; see
http://authors.acm.org/main.cfm for information on the
options available to authors. Authors are encouraged to
submit auxiliary material for publication along with their
paper (source code, data, videos, images, etc.); authors
retain all rights to the auxiliary material.

WORKSHOP ORGANISATION

Workshop Chair: Alex McLean, University of Leeds

Program Chair: Henrik Nilsson, University of Nottingham

Publicity Chair: Michael Sperber, Active Group GmbH

Program Committee:
Sam Aaron, Cambridge University
David Duke, University of Leeds
Kathleen Fisher, Tufts University
Julie Greensmith, University of Nottingham
Bas de Haas, Universiteit Utrecht
Paul Hudak, Yale University
David Janin, Université de Bordeaux
Richard Lewis, Goldsmiths, University of London
Louis Mandel, Collège de France
Alex McLean, University of Leeds
Carin Meier, Neo Innovation Inc
Rob Myers, Furtherfield
Henrik Nilsson, University of Nottingham (chair)
Dan Piponi, Google Inc
Andrew Sorensen, Queensland University of Technology
Michael Sperber, Active Group GmbH

For further details, see the FARM website:
http://functional-art.org

Hi, I'm looking for a good online forum that focuses on the practical details of building compilers. I've posted a lot of material on LLVM over the years, however that forum is really dedicated to issues specific to LLVM and not compilers in general. Similarly, LtU is more focused on theory than practice (which is not to say that I'm not interested in theory.)

I'd like to find some place where I could post questions about things like efficient multimethod dispatch, garbage collection algorithms, and so on, and not feel like I was off-topic.

Also, when it comes to feedback I would favor quality over quantity.

Any suggestions?

- Synopsis -

What is Code Disease?

A code disease is a pervasive property of a code base that harms or destroys basic ease of software development and maintenance. Often propagating problems up to the business execution and strategic levels, code diseases are costly and risk-inducing. As its strong name indicates, a code disease is very serious and potentially threatening, with its first victims the morale and sanity of the developers who live with it daily, and its final victims the customers who are punished for relying on your business’s affected systems.

Please find the PDF here - Diseases in Code (rev. 5)

LtU is the first place I've posted this, so hopefully I can get a bit of feedback!

I recently created a proposal for a StackExchange site for Programming Language Theory. It is currently in the Definition stage and it requires a plethora of good quality questions - questions which you would expect to see on the actual site once it is created. There are already a few example questions. However most of the questions are by users who seem to be only enthusiasts. We need more followers who are experts at PLT to give the site a definite shape.

Update: I (Ehud) am promoting this thread to the home page. It seems that the proposal has a good chance, if enough people commit to participate (see the discussion thread). I presume LtU readers would want to know about this process, and make up their own minds about whether they want to join or not.

With respect to detected contradictions in large information system, according to [Russo, Nuseibeh, and Easterbrook 2000]:

"The choice of an inconsistency handling strategy depends on the context and the impact it has on other aspects of the development process. Resolving the inconsistency may be as simple as adding or deleting information from a software description. However, it often relies on resolving fundamental conflicts, or taking important design decisions. In such cases, immediate resolution is not the best option, and a number of choices are available:

Ignore - it is sometimes the case that the effort of fixing
an inconsistency is too great relative to the (low) risk that the
inconsistency will have any adverse consequences. In such cases,
developers may choose to ignore the existence of the inconsistency in
their descriptions. Good practice dictates that such decisions should be
revisited as a project progresses or as a system evolves.

Defer - this may provide developers with more time to elicit
further information to facilitate resolution or to render the
inconsistency unimportant. In such cases, it is important to flag the
parts of the descriptions that are affected, as development will continue
while the inconsistency is tolerated.

Circumvent - in some cases, what appears to be an
inconsistency according to the consistency rules is not regarded as such
by the software developers. This may be because the rule is wrong, or
because the inconsistency represents an exception to the rule that had
not been captured. In these cases, the inconsistency can be circumvented
by modifying the rule, or by disabling it for a specific context.

Ameliorate - it may be more cost-effective to ‘improve’ a
description containing inconsistencies without necessarily resolving them
all. This may include adding information to the description that
alleviates some adverse effects of an inconsistency and/or resolves other
inconsistencies as a side effect. In such cases, amelioration can be a
useful inconsistency handling strategy in that it moves the development
process in a ‘desirable’ direction in which inconsistencies and their
adverse impact are reduced.

It is not generally proper to post call-for-papers on LtU. Exceptions have been made, for broad workshops likely to appeal to many LtU readers. I hope the 2014 ML Family workshop also qualifies.

The ML Family workshop intends to attract the entire family of ML languages, whether related by blood to the original ML or not. Our slogan is ``Higher-order, Typed, Inferred, Strict''. Designers and users of the languages fitting the description have many issues in common, from data representation and garbage collection to fancy type system features. As an example, some form of type classes or implicits has been tried or been looked into in several languages of the broad ML family. We hope the ML Family workshop is a good forum to discuss these issues.

Also new this year is a category of submissions -- informed opinions -- to complement research presentation, experience reports and demos. We specifically invite arguments about language features, be they types, garbage collection, implicits or something else -- but the arguments must good and justified. Significant personal experience does count as justification, as do empirical studies or formal proofs. We would be delighted if language implementors or long-time serious users could tell, with examples from their long experience, what has worked out and what has not in their language.

The deadline for submitting an abstract of the presentation, up to 2 PDF pages, is in a month. Please consider submitting and attending!

Recent Turing Award winner Leslie Lamport's talk at the Build 2014 Conference, Thinking for Programmers. I do wonder if the level of specification (thinking) Leslie recommends here is realistic/necessary in this day of apps, web pages, and mostly non-systems/non-critical programming mostly done by app developers with little to no formal education in mathematics or computer science.

"If you don't start off with a spec, every piece of code you write is a patch".

What do you think, when applied to the programming environments of today (apps, web pages, non-critical systems, etc...). Does it go too far to assume this level of thinking?

It appears that too many developers do not understand actors, and that actors have not been explained very well. My thought is that a model that behaves, to a degree, like actors might go a long way to explaining actors through analogy, especially if that model can be implemented with a minimum of code. Mind, the model is only an approximation. But even so, you may find it interesting/informative.

more