Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Papers vs. Artifacts

Philipp Haller
July 17, 2016
220

Papers vs. Artifacts

Philipp Haller

July 17, 2016
Tweet

Transcript

  1. Papers vs. Artifacts Philipp Haller KTH Royal Institute of Technology

    Sweden ECOOP Doctoral Symposium Rome, Italy, 17 July 2016 1
  2. Haller Papers vs. Artifacts Artifacts are Important • Enable reproducing

    research results by independent researchers • Enable practically evaluating ideas and theories • Enable experimentation with variations and extensions • Not only by the original authors! 2
  3. Haller Papers vs. Artifacts “Artifacts are a hindrance!” • High-quality

    artifacts require a lot of development effort • Artifacts have no influence on acceptance of a research paper at the top PL/SE conferences • The main requirement for completing a PhD is producing publishable research results 3 “How to justify the effort developing artifacts?”
  4. Haller Papers vs. Artifacts Potential Benefits • Increase quality of

    research • Increase visibility and impact of research • Support discovery of research problems 4
  5. Haller Papers vs. Artifacts Context: My PhD Project • Goal:

    high-level concurrent programming model that • simplifies avoiding data races; • (reduces risk of deadlocks;) • scales to large number of concurrent processes; • guarantees progress in presence of blocking ops; • integrates with thread model of mainstream VMs. • Main sources of inspiration: Erlang and Actor Model 5
  6. Haller Papers vs. Artifacts Actors • Actor = concurrent “process”

    that communicates via asynchronous messages • Asynchronous send, event-based receive • Avoiding low-level data races is straight-forward: • Exchange only immutable objects • Don’t capture mutable state • A lot more complex to ensure race safety for efficient by-reference message passing of mutable objects 6
  7. Haller Papers vs. Artifacts Artifacts • Here: limit to doctoral

    school (2005/2006—2010) • Participation in Scala team meetings from beginning to end of doctoral school (and beyond) • 2006: first release of Scala Actors • 2006—2010: partest compiler test framework • 2008: join patterns for Scala • 2009: uniqueness types for Scala (compiler plugin) 7
  8. Haller Papers vs. Artifacts Noteworthy events… 8 “We saw 5x

    normal tweets-per-second and about 4x tweets-per-minute as this chart illustrates. Overall, Twitter sailed smoothly through the inauguration [...]” Source: https://blog.twitter.com/2009/inauguration-day-twitter Other uses at The Guardian and others
  9. Haller Papers vs. Artifacts Artifacts Annotated 9 • Participation in

    Scala team meetings from beginning to end of doctoral school (and beyond) • 2006: first release of Scala Actors • 2006—2010: partest compiler test framework • 2008: join patterns for Scala • 2009: uniqueness types for Scala (compiler plugin) Co-author of Scala specification, contributions to language, core library, and tools 2008: Twitter starts using Scala Actors in production 2006—2009: lots of development/maintenance End of 2008: start work on new research topic Most of 2010/2011 spent on writing a book on actors in Scala for developers
  10. Haller Papers vs. Artifacts Scala Actors: Timeline • Entire year

    2006 spent developing Scala Actors • 2007: • Development/maintenance, OSS community work, reading • Best student paper award (Coordination ’07) • 2008: • Part-time development/maintenance, OSS community work • Offer to write a book • 2009: minimal maintenance, talk at JavaOne 10
  11. Haller Papers vs. Artifacts Outcome • Several well-cited papers 11

    Haller and Odersky. Scala Actors: Unifying thread-based and event- based programming. TCS ’09 (Google Scholar: 296 Citations) Haller and Odersky. Event-based programming without inversion of control. JMLC ’06 (Google Scholar: 119 Citations) Haller and Odersky. Capabilities for uniqueness and borrowing. ECOOP ’10 (Google Scholar: 69 Citations) • Published book (“Actors in Scala”, Jan 2012) • Opportunity to develop research further in context of Typesafe start-up company (2012–2014) • Wide visibility and reuse Haller and Van Cutsem. Implementing joins using extensible pattern matching. Coordination ’08 (Google Scholar: 45 Citations)
  12. Haller Papers vs. Artifacts Another Artifact • Spent 2009 working

    on uniqueness types in Scala • Solely motivated by experience with actors • One of the most frequent questions of users: “how to ensure isolation of actors?” • At the same time developed a complete and detailed soundness proof • Research had clear priority: artifact (compiler plugin) developed “only” for experimental evaluation • Result: one user who tried it and gave up :-) 12
  13. Haller Papers vs. Artifacts Post Mortem • Making artifact useful

    in practice would have required a lot more engineering effort • Most time spent on type system design and soundness proof • Implementation technology was not ready • But also: experience has served as motivation to explore different approaches 13
  14. Haller Papers vs. Artifacts Increasing Impact • Your research produces

    performance results? • Making your artifact easily usable ensures many researchers compare to your work • (This even helps if your system is slow/limited/..) • If usable by practitioners: enables talks at industrial conferences • Your ideas influence industry: “wider impact” • Even better: useful to practitioners (requires engineering, documentation, community support) • Goal: establish your system as state of the art • Cannot be overlooked 14
  15. Haller Papers vs. Artifacts Conclusion Artifacts: • Not just a

    burden • Can inform research problems • Can dramatically increase impact • Can offer career opportunities: research collaborations, start-ups, consulting, … 15