[Haskell] Reminder: Call for Presentations: CUFP 2017, September 7-9, Oxford, UK

[Jasper Van der Jeugt]

Hello all,

This is just a reminder that there are 3 weeks until the deadline for
CUFP 2017 submissions.  If you use haskell in the industry, please
consider submitting a proposal.

The CFP and the form for submitting presentations proposals can be
found at: http://cufp.org/2017/call-for-presentations.html

------------------------------------------------------------------------

> 2017 Call for Presentations
>
> Workshop for Commercial Users of Functional Programming 2017
> Sponsored by SIGPLAN
> CUFP 2017
> Co-located with ICFP 2017
> Oxford, UK
> September 7-9
> Talk Proposal Submission Deadline: 9 June 2017
>
> The annual CUFP event 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 event.
> We're looking for two kinds of talks:
>
> Retrospective reports are typically 25 minutes long. Now that CUFP has
> run for more than a decade, we intend to invite past speakers to share
> what they've learned after a decade spent as commercial users of
> functional programming. We will favour experience reports that include
> technical content.
>
> 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 ission
> 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:
>
>     http://www.sigplan.org/Resources/Policies/Anti-harassment
>
> If you are interested in offering a talk, or nominating someone to do
> so, please submit your presentation before 09 June 2017 via the CUFP
> 2017 Presentation Submission Form:
>
>     https://goo.gl/forms/KPloANxHHwdiaoVj2
>
> 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 of a discussion forum than a technical
> interchange.
>
> Nevertheless, presentations will be recorded and presenters will be
> expected to sign an ACM copyright release form.
>
> Note that we will need presenters to register for the CUFP workshop and
> travel to Oxford at their own expense. There are some funds available to
> would-be presenters who require assistance in this respect.
>
> ------------------------------------------------------------------------
>
> Program Committee
>
>     Alex Lang (Tsuru Capital), co-chair
>     Rachel Reese (Mulberry Labs), co-chair
>     Garrett Smith (Guild AI)
>     Danielle Sucher (Jane Street)
>     Jasper Van der Jeugt (Fugue)
>     Yukitoshi Suzuki (Ziosoft)
>     Evelina Gabasova (University of Cambridge)
>     Brian Mitchell (Jet.com)
>
> ------------------------------------------------------------------------
>
> 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. Acceptance and rejection letters will be sent out by July 15th.
> 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-scale software
> development in the absence of pre-existing support tools 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
> cover 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.