Review of practice-led research in art, design & architecture

This review report sets out the outcomes of a 10 month investigation to describe the landscape of practice-led research in Art, Design and Architecture (ADA) in the UK and beyond. We were asked for a qualitative review but of course it has been important to gather some numbers to check and illustrate our observations. We have consulted widely, both face to face and in the virtual world, with experts and novices in the UK and around the world. We have tried to strike a balance between the natural desire of our colleagues to debate the more contentious aspects of this territory (they were never going to forgo that opportunity) and the equally strong wish of the AHRC that we should provide a clear description of what is happening. We have collected some diverse examples of research and subjected them to various examinations. We have also examined a selection of research projects funded by AHRC and other projects by creative practitioners, funded by a non-research organisation. From all this we have been able to describe the landscape in a straightforward sense: We have measures of the proportions of ADA academics involved in practice-led research. We have clarified differences in the ways that the different ADA disciplines engage with practice-led research and identified some problems that indicate possible future support strategies. We have discussed some problems with general definitions of research and identified issues that should be addressed to ensure that the AHRC definition can be applied to the full range of practice-led research. We have picked out some specific case examples that illustrate the range of contexts, methods and contributions made by practice-led researchers, and more are described in detail in Appendix F. We have also sought to assess how this research relates to the wider international picture in which the UK appears to have a strong position in both volume and development of research. We have also set out some issues that affect this community of researchers: What strengths and weaknesses have we observed and where is there a need to support development? Do the AHRC definition of research and guidance on practice-led research provide an effective framework? We have illustrated the state of development of research in ADA, and some reasons why it is less robust than might be expected from such long established disciplines. We recommend that the career path of researchers in ADA needs some attention and make some suggestions about how that could be achieved. We have also indicated some areas of inquiry that might be supported to advance the theory and methods of practice-led research. In particular we have come to the conclusion that conventional ideas of contribution to knowledge or understanding may not be serving us well. This is significant to fine artists but we believe that it relevant across ADA and a shared effort to develop appropriate new models would be a constructive development. The full set of recommendations can be found in chapter 5

Unleashing the Power of Clippy in Real-World Rust Projects

Clippy lints are considered as essential tools for Rust developers, as they can be configured as gate-keeping rules for a Rust project during continuous integration. Despite their availability, little was known about practical application and cost-effectiveness of the lints in reducing code quality issues. In this study, we embark on a comprehensive analysis to unveil the true impact of Clippy lints in the Rust development landscape. The study is structured around three interrelated components, each contributing to the overall effectiveness of Clippy. Firstly, we conduct a comprehensive analysis of Clippy lints in all idiomatic crates-io Rust projects with an average warning density of 21/KLOC. The analysis identifies the most cost-effective lint fixes, offering valuable opportunities for optimizing code quality. Secondly, we actively engage Rust developers through a user survey to garner invaluable feedback on their experiences with Clippy. User insights shed light on two crucial concerns: the prevalence of false positives in warnings and the need for auto-fix support for most warnings. Thirdly, building upon these findings, we engineer three innovative automated refactoring techniques to effectively fix the four most frequent Clippy lints. As a result, the warning density in Rosetta benchmarks has significantly decreased from 195/KLOC to an impressive 18/KLOC, already lower than the average density of the crates-io Rust projects. These results demonstrate tangible benefit and impact of our efforts in enhancing the overall code quality and maintainability for Rust developers

Proceedings of The Rust-Edu Workshop

The 2022 Rust-Edu Workshop was an experiment. We wanted to gather together as many thought leaders we could attract in the area of Rust education, with an emphasis on academic-facing ideas. We hoped that productive discussions and future collaborations would result. Given the quick preparation and the difficulties of an international remote event, I am very happy to report a grand success. We had more than 27 participants from timezones around the globe. We had eight talks, four refereed papers and statements from 15 participants. Everyone seemed to have a good time, and I can say that I learned a ton. These proceedings are loosely organized: they represent a mere compilation of the excellent submitted work. I hope you’ll find this material as pleasant and useful as I have. Bart Massey 30 August 202

Using the Go Programming Language in Practice

When developing software today, we still use old tools and ideas. Maybe it is time to start from scratch and try tools and languages that are more in line with how we actually want to develop software. The Go Programming Language was created at Google by a rather famous trio: Rob Pike, Ken Thompson and Robert Griesemer. Before introducing Go, the company suffered from their development process not scaling well due to slow builds, uncontrolled dependencies, hard to read code, poor documentation and so on. Go is set out to provide a solution for these issues. The purpose of this master's thesis was to review the current state of the language. This is not only a study of the language itself but an investigation of the whole software development process using Go. The study was carried out from an embedded development perspective which includes an investigation of compilers and cross-compilation. We found that Go is exciting, fun to use and fulfills what is promised in many cases. However, we think the tools need some more time to mature

Is Rust Used Safely by Software Developers?

Rust, an emerging programming language with explosive growth, provides a robust type system that enables programmers to write memory-safe and data-race free code. To allow access to a machine's hardware and to support low-level performance optimizations, a second language, Unsafe Rust, is embedded in Rust. It contains support for operations that are difficult to statically check, such as C-style pointers for access to arbitrary memory locations and mutable global variables. When a program uses these features, the compiler is unable to statically guarantee the safety properties Rust promotes. In this work, we perform a large-scale empirical study to explore how software developers are using Unsafe Rust in real-world Rust libraries and applications. Our results indicate that software engineers use the keyword unsafe in less than 30% of Rust libraries, but more than half cannot be entirely statically checked by the Rust compiler because of Unsafe Rust hidden somewhere in a library's call chain. We conclude that although the use of the keyword unsafe is limited, the propagation of unsafeness offers a challenge to the claim of Rust as a memory-safe language. Furthermore, we recommend changes to the Rust compiler and to the central Rust repository's interface to help Rust software developers be aware of when their Rust code is unsafe