Due to the COVID-19 pandemic, many conferences were held online starting in late March 2020, and several of us helped with the fully virtual offering of SPLASH 2020. By mid-2021, however, vaccination was widespread and effective at preventing COVID infection and severe disease, and it became feasible to consider in-person attendance at conferences. Polls of authors and the larger community indicated strong interest in holding an in-person version of SPLASH. Still, as of October 2021 the US had not relaxed its travel restrictions on people from large parts of the world, and even beyond that some people would not be able to travel to SPLASH. We therefore decided to offer SPLASH as a Hybrid conference in October 2021, offering both in-person and virtual attendance options. We were also excited about piloting a hybrid conference, because there are many longer-term benefits if we can run them well, including supporting both in-person networking and accessibility for attendees who can only attend remotely. We knew doing so would be hard, but we also hoped to learn valuable lessons. SPLASH 2021 turned out to be an interesting case study as the first major post-COVID PL conference to go hybrid, and one of the earliest across the ACM as well.
Real programming languages are living things, changing and evolving. As with any production code, most of their designer’s time is spent on bug fixing and small improvements, rather than on the radical new features. One of the unique things about Kotlin is that it has been evolving in the use-case and community-driven fashion for years, starting way before it went to the stable 1.0 release in 2016, even for some time before it went public in 2011. Language design in the real world is a maintenance of a complex system and it runs into novel research questions with respect to type systems, feature interactions, usability, real-life code patterns in big code, etc.
You have heard your grandmother tell you many times: parallel programming is hard. In 2022, does it still have to be? Back in grandma’s heyday, they knew a cool and breezy way to do parallelism: pure functional programming. They knew that pure functions are parallel by default, being free of pesky concurrency bugs and all. But, parallel functional programming remained slow and steady, resisting practical efficiency for decades. This post shows the way towards solving the performance problems of functional programming.
The ASPLOS Steering Committee is considering two changes to the ASPLOS submission process: 1) three submission deadlines spread over the year, and 2) the possibility for papers near acceptance to be revised and resubmitted. This proposal outlines these changes.
“Undefined Behavior” often has a bad reputation. But what, really, is Undefined Behavior, and is it actually that bad?
In this blog post, I will look at this topic from a PL perspective, and argue that Undefined Behavior is a valuable tool in a language designer’s toolbox.