429 research outputs found
INTERACTIVE ONLINE DEBUGGER FOR INTRODUCTORY C++ PROGRAMMING COURSES
The development process for every high-level programming language is heavily
dependent on integrated development environments (IDEs) or code editors, which allow software
engineers to write code efficiently in terms of time consumption, clean code, and debugging.
These tools are in demand for numerous reasons, including auto-completion, extensions, built-in
artificial intelligence that memorizes code patterns, built-in debuggers, and readability. Almost all
of the listed bullet points share one common objective, which is to alleviate the coding process
for advanced users.
However, during the learning process and acquisition of unknown information, priorities
change. As a result, syntax and knowledge of the underlying processes of syntax take precedence
over time efficiency and clean code. Moreover, the presence of those listed features can make the
study process overwhelming and tedious for students, as they need to familiarize themselves with
the concepts of IDEs, code editors, compilers, and debuggers before studying the programming
language.
It is worth mentioning that visualization is crucial in the debugging activity, since the
survey conducted as a part of our research shows that 75 students out of 96 students prefer
visualization during studying rather than plain text. We believe, visualization is particularly
important when students start dealing with computer science concepts such as memory
allocation, data structure behaviors when core methods are called, and finally, with algorithms.
IDEs and code editors provide simple tables as visualizations in debugging procedures, which
may not be intuitive at first glance.
Another problem mentioned by professors is the distinction of hardware systems that
students use. This distinction reveals the problem of installing components that work only for
certain hardware systems. For instance, gdb is not suitable for new ARM circuits, whereas LLDB
works properly. Meanwhile, for x86 GDB works correctly.
In several courses of the School of Engineering and Digital Sciences, first-year students
who take introductory courses related to high-level programming languages tend to use IDEs and
code editors. Some of those courses are Engineering 101, CSCI 151, and CSCI 152. Students in
those courses have faced similar problems as mentioned above. They spend time ineffectively
downloading and installing components, instead of spending the same time learning actual
programming. The objective of this thesis is to present a resolution for developing a
comprehensive application, which allows for the visualization of the debugging process. To
achieve this objective, the optimal technologies for the application will be assessed, comparing
network protocols like HTTP and WebSocket, as well as examining statelessness and
statefulness. The role of threads in this process will also be explored. For compiling and
debugging, GCC and GDB were utilized respectively. Furthermore, the concept of a Process will
be introduced to run the GCC/GDB process separately, and Input/Output streams will be
explained. Finally, the thesis will explore parsing GDB responses and rendering them as a React
component to provide an easily understandable visualization
Recommended from our members
Proceedings of the 33rd Annual Workshop of the Psychology of Programming Interest Group
This is the Proceedings of the 33rd Annual Workshop of the Psychology of Programming Interest Group (PPIG). This was the first PPIG to be held physically since 2019, following the two online-only PPIGs in 2020 and 2021, both during the Covid pandemic. It was also the first PPIG conference to be designed specifically for hybrid attendance. Reflecting the theme, it was hosted by Music Computing Lab at the Open University in Milton Keynes
Towards the Humanisation of Programming Tool Interactions
Program analysis tools, from simple static semantic analysis by a compiler, to complex dynamic analyses of data flow and security, have become commonplace in modern day programming. Many of the simpler analyses, such as the afore- mentioned compiler checking or linters designed to enforce code style, may even go unnoticed or unconsidered by most users, ubiquitous as they are. Despite this, and despite the obvious utility that such programming tools can provide, many warnings provided by them go unheeded by programmers most of the time.There are several reasons for this phenomenon: the propensity to produce false positives undermines confidence in the validity of warnings, the tools do not in- tegrate well into the normal workflow of the developer, sometimes the warning message is simply too esoteric for most users to understand, and so on. A com- mon theme can be drawn from these reasons for ignoring the often-times very useful information given by a programming tool: the tool itself is difficult to use.In this thesis, we consider ways in which we can bridge this gap between users and tools. To do this, we draw from observations about the way in which we interact with each other in the most basic human-to-human context. Applying these lessons to a human-tool interaction allow us to examine ways in which tools may be deficient, and investigate methods for making the interaction more natural and human-like.We explore this issue by framing the interaction as a "conversation" between a human and their development environment. We then present a new programming tool, Progger, built using design principles driven by the "conversational lens" which we use to look at these interactions. After this, we present a user study using a novel low-cost methodology, aimed at evaluating the efficacy of the Progger tool. From the results of this user study, we present a new, more streamlined version of Progger, and finally investigate the way in which it can be used to direct the users attention when conducting a code comprehension exercise
NuzzleBug: Debugging Block-Based Programs in Scratch
While professional integrated programming environments support developers
with advanced debugging functionality, block-based programming environments for
young learners often provide no support for debugging at all, thus inhibiting
debugging and preventing debugging education. In this paper we introduce
NuzzleBug, an extension of the popular block-based programming environment
Scratch that provides the missing debugging support. NuzzleBug allows
controlling the executions of Scratch programs with classical debugging
functionality such as stepping and breakpoints, and it is an omniscient
debugger that also allows reverse stepping. To support learners in deriving
hypotheses that guide debugging, NuzzleBug is an interrogative debugger that
enables to ask questions about executions and provides answers explaining the
behavior in question. In order to evaluate NuzzleBug, we survey the opinions of
teachers, and study the effects on learners in terms of debugging effectiveness
and efficiency. We find that teachers consider NuzzleBug to be useful, and
children can use it to debug faulty programs effectively. However, systematic
debugging requires dedicated training, and even when NuzzleBug can provide
correct answers learners may require further help to comprehend faults and
necessary fixes, thus calling for further research on improving debugging
techniques and the information they provide.Comment: To appear at the 2024 IEEE/ACM 46th International Conference on
Software Engineering (ICSE '24), April 14--20, 2024, Lisbon, Portuga
Recommended from our members
Leveraging Learning Collectives: How Novice Outsiders Break into an Occupation
Existing research depicts occupational learning as predominantly happening through formal education, situated learning, or a combination of the two. How career switchers might develop occupational skills outside of these established learning pathways is understudied. This paper examines how novice outsiders break into a skilled occupation by looking at the case of aspiring software developers attending coding bootcamps. Drawing on 17āmonths of fieldwork in the San Francisco Bay area, I find that bootcamps did not resemble either schools or workplaces, the two institutions that facilitate occupational learning. Instead, bootcamps scaffolded learning collectivesāgroups composed of peers and near peers who learn collaboratively and purposefully to reach a shared goal. Within learning collectives, aspirants progressed from novice outsiders to hirable software developers, despite limited access to proximate experts to learn from or legitimate peripheral participation opportunities. Three scaffoldings facilitated learning at bootcamps. First, peer team structures turned what is normally a solitary activityāwriting codeāinto a collaborative endeavor and facilitated peer-to-peer knowledge exchange. Second, near-peer role structures engaged recent graduates in teaching and mentorship relationships with novices so that aspirants could access knowledge quickly and easily. Third, bootcamps encouraged aspirants to self-learn by reaching out to the expertise of the broader occupational community. This third scaffolding prepared aspirants for learning beyond the bootcamp curriculum and socialized them for an occupation with high learning demands. The outcome of this process was that novices pursuing an alternative mode of occupational entry developed both occupational skills and new self-conceptions as software developers
A multiple case study of high school perspectives making music with code in Sonic Pi
The purpose of this study was to investigate perceptions of high school students who made music with code in Sonic Pi. This qualitative multiple case study focused on individuals in an extracurricular club at a public charter high school who volunteered to participate on-site and remotely asynchronously via Canvas learning management system. This study was guided by five research questions, including: (1) What musical ideas, if any, do participants report learning or demonstrate through making music with code in Sonic Pi? (2) How does making music with code impact participantsā perceptions of their music making? (3) How does making music with code impact participantsā perceptions of their ability to learn to make music? (4) How does making music with code impact participantsā interest in music courses? (5) How does making music with code impact participantsā interest in computer science courses? Participants completed research study materials, including a series of tutorials for Sonic Pi. Data included answers to questionnaires and surveys, multimedia artifacts including the source code and exported audio of participantsā music making, and interviews of participants that were codified and analyzed in two cycles, utilizing descriptive coding, values coding, and longitudinal coding. Participantsā code and multimedia artifacts revealed a close alignment to the four properties of sound, including: pitch, duration, intensity/amplitude, and timbre. Participantsā artifacts revealed themes and demonstrated ideas extending beyond the four properties, including: form, non-traditional music notation, and randomization. Participants all agreed their coded artifacts are music. Additionally, participantsā varied responses about musicianship and composers suggests that making music is something anyone can engage in, regardless of how one identifies themself. All participants agreed that Sonic Pi is a useful tool for learning and understanding musical concepts and that Western staff notation is not required knowledge for making music. Participantsā interests in music or computer science courses were impacted by their prior experiences in music and/or coding. This study concludes with a discussion of themes based on the findings
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
- ā¦