Software systems researchers want to make human-centered claims, but don’t have the proper tools to do so. That’s how we ended up with the ubiquitous lines-of-code comparison found in evaluation sections everywhere. In this post, I explore: what can we reasonably expect researchers to do that’s higher quality than LOC but less effort than a full-blown user study?
The open-source development of the JavaScript programming language is now automatically checked. The language specification written in English is type checked, and the tests are checked for conformance to the specification. This blog post presents how research papers became continuously integrated into the development of a real-world programming language.
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.
We give an introduction to reflective towers of interpreters, a semantic model of reflection with a user level interpreted by a meta level interpreted by a meta meta level and so on.
When developing massively distributed, interactive applications, programmers must select mechanisms that balance consistency, performance, and availability, which can be challenging. New research is looking at ways to automate this selection, with provable guarantees.
