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

Papers vs. Artifacts

3b84657fdb075382e3781310ca8a9a70?s=47 Philipp Haller
October 27, 2015
92

Papers vs. Artifacts

3b84657fdb075382e3781310ca8a9a70?s=128

Philipp Haller

October 27, 2015
Tweet

Transcript

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

    Sweden SPLASH Doctoral Symposium Pittsburgh, PA, USA, October 2015 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
  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 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 • Every day: reading and programming • 2007: • Every day: programming, OSS community work, reading • Best student paper award • 2008: • Part-time development/maintenance • Offer to write a book • 2009: no development, minimal maintenance 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: 265 Citations) Haller and Odersky. Event-based programming without inversion of control. JMLC ’06 (Google Scholar: 108 Citations) Haller and Odersky. Capabilities for Uniqueness and Borrowing. ECOOP ’10 (Google Scholar: 61 Citations) • Published book (“Actors in Scala”, Jan 2012) • Opportunity to develop research further in context of Typesafe start-up company (2012-2014) • Opportunities in academic service, …
  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 we received: “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 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 • 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 can lead to 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, academic service, start-ups, consulting, … 15