Robert Heumüller

@article{sap2020,
title = {Publish or Perish, but do not Forget your Software Artifacts},
author = {Robert Heum\"{u}ller and Sebastian Nielebock and Jacob Kr\"{u}ger and Frank Ortmeier},
editor = {Springer},
url = {https://cse.cs.ovgu.de/cse-wordpress/wp-content/uploads/2020/07/2020-emse-paper-publish-or-perish.pdf},
doi = {10.1007/s10664-020-09851-6},
year = {2020},
date = {2020-06-24},
journal = {Empirical Software Engineering},
abstract = {Open-science initiatives have gained substantial momentum in computer science, and particularly in software-engineering research.
A critical aspect of open-science is the public availability of artifacts (e.g., tools), which facilitate the replication, reproduction, extension, and verification of results.
While we experienced that many artifacts are not publicly available, we are not aware of empirical evidence supporting this subjective claim.
In this article, we report an empirical study on software artifact papers (SAPs) published at the International Conference on Software Engineering (ICSE), in which we investigated whether and how researchers have published their software artifacts, and whether this had scientific impact.
Our dataset comprises 789 ICSE research track papers, including 604 SAPs (76.6,%), from the years 2007 to 2017.
While showing a positive trend towards artifact availability, our results are still sobering.
Even in 2017, only 58.5,% of the papers that stated to have developed a software artifact made that artifact publicly available.
As we did find a small, but statistically significant, positive correlation between linking to artifacts in a paper and its scientific impact in terms of citations, we hope to motivate the research community to share more artifacts.
With our insights, we aim to support the advancement of open science by discussing our results in the context of existing initiatives and guidelines.
In particular, our findings advocate the need for clearly communicating artifacts and the use of non-commercial, persistent archives to provide replication packages.},
note = {Preprint},
keywords = {},
pubstate = {forthcoming},
tppubtype = {article}
}

@article{NielebockLambda2018,
title = {Programmers do not Favor Lambda Expressions for Concurrent Object-Oriented Code},
author = {Sebastian Nielebock and Robert Heum\"{u}ller and Frank Ortmeier},
editor = {Springer},
url = {https://cse.cs.ovgu.de/cse-wordpress/wp-content/uploads/2018/11/2018-11-06-ESEC-FSE-Lambda-In-Concurrency_prepared_publication.pdf
https://cse.cs.ovgu.de/cse-wordpress/wp-content/uploads/2018/10/journal-emse-lambda-1.pdf
https://bitbucket.org/SNielebock/lambdainconcurrentdataset},
doi = {10.1007/s10664-018-9622-9},
issn = {1382-3256},
year = {2018},
date = {2018-05-02},
journal = {Springer Empirical Software Engineering (EMSE)},
volume = {24},
number = {1},
pages = {103--138},
abstract = {Lambda expressions have long been state-of-the-art in the functional programming paradigm.
Especially with regard to the use of higher-order functions, they provide developers with a means of defining predicate or projection functions locally, which greatly increases the comprehensibility of the resulting source code.
This benefit has motivated language designers to also incorporate lambda expressions into object-oriented (OO) programming languages.
In particular, they are claimed to facilitate concurrent programming.
One likely reason for this assumption is their purity: pure lambda expressions are free of side effects, and therefore cannot cause, e.g., race conditions.
In this paper, we present the first empirical analysis of whether or not this claim is true for OO projects.

For this purpose, we investigated the application of lambda expressions in 2,923 open-source projects, implemented in one of the most common OO programming languages: C#, C++, and Java.
We present three major findings.
First, the majority of lambda expressions are not applied in concurrent code and most concurrent code does not make use of lambda expressions.
Second, for all three of the languages, we observed that developers compromise their code by applying a significantly higher number of impure, capturing lambda expressions, which are capable of causing race conditions.
Finally, we explored further use cases of lambda expressions and found out that testing, algorithmic implementation, and UI are far more common use-cases for the application of lambda expressions.

Our results encourage to investigate in more detail the reasons that hinder programmers to apply lambda expressions in concurrent programming and to support developers, e.g., by providing automatic refactorings.},
keywords = {},
pubstate = {published},
tppubtype = {article}
}