To be fair, I think the parent commenter is aware this is not the fault of the one who asked.
Though when doing a PhD, it's a worthy goal to be able do give a quick description. It also forces you to think about the goal / meaning of your work. Some topics are more easily summarized, but still.
We do science for people, it's only fair to be able to present them your work more or less roughly.
I had something for people not into computers, like: "I work on a method to find and understand computer bugs quicker and better." (Familiar with bugs? you don't like them? So you know it's useful!)
And then I could develop for the curious.
"Programs are written with code that tells the computer what to do, step by step. Like a cooking recipe. There are tools to see programs do things step by step so you can notice some step is wrong. On big programs this gets tedious. My approach helps starting this step by step investigation closer to the problematic step."
If still curious: "How? There's another method that looks at the step that looks at these steps and check they are correct with respect to some given rule. For instance, if you have a bag of objects, no step should try to remove an object if the bag is empty. This technique usually tells you something is wrong but does not tell you why it happen. I combine the first method with the second one: when some rule is broken, you are left exploring the program step by step at the point the rule broke, which is way better than doing it from the beginning". And go further / present the caveats if I feel whoever is listening is still curious.
For the people who already actually interacted with some code, I would also drop the technical words that are probably familiar to them. If you don't know whether they already actually know some stuff, they usually say the technical words themselves, to clarify.
For people who asked politely, they would receive the one sentence summary but often they want to know more if you piqued their curiosity. I had something like a progressive image of the thing that gets more and more precise to stop at the right time.
By the way you probably started skipping paragraphs in my comment at the point yours was satisfied. I made several paragraphs to allow you to do so.
I worked on combining Interactive Debugging with Runtime Verification (and we called it Interactive Runtime Verification).
Interactive debugging is the usual step by step debugging you know, offered by your standard IDE or debugger like GDB.
Runtime Verification evaluates properties from a stream of events, the program execution being usually seen as a sequence of events (there are ways to represent concurrency / parallel executions too, a bit more complicated than a mere sequence in this case).
GDB offers a comprehensive Python interface [1] that lets you add breakpoints, watchpoints and catchpoints to inspect what's going on during the execution, and you decide whether to suspend the execution on conditions you evaluate. In our cases, the conditions are the runtime verification properties. See this like conditional breakpoints on steroids.
For instance, take a program that manipulates a queue. One property you don't want to break is "the program never remove an element from an empty list". Another one is "the program never pushes elements to an already full list". To evaluate these properties, you describe the property in terms of parameterized calls to functions new_list(n), push() and pop().
In a C program, the calls could "succeed", the execution continues but with a memory corruption. Which could be hard to detect. So instead, you have this runtime verification stop the execution for you at the point where the bug happens, instead of the likely crash.
So we implemented this idea, with features like checkpointing (thanks to the (limited) native experimental GDB checkpointing feature, or CRIU (Checkpoint and Restore in Userspace - the thing behind Docker container checkpointing and migration) [2], which does this very well) as a Python extension to GDB. This implementation theoretically supported any language supported by GDB, including C and C++.
Building on this implementation, we made a second version that supported distributed programs, and also supported Java programs. The debugging capabilities of the JVM are awesome / endless.
These implementations allowed benchmarking. Unfortunately, we focused on benchmarking the performance of the instrumentation, but what would have been very useful is to validate the method itself with human studies. This PhD should have been at the edge between computer science and human studies. It's not. Instead, it's very theoretical, with some formalism trying to define an interactively verified execution, and doing proofs that the instrumentation does not affect the execution.
Sounds amazing? What's the catch? Finding actual properties that relate to day to day bugs is hard. When developing a program, specifications are not given as LTL properties by the client, it's more like "I need this, be creative", and it's team work, and more often than not bugs are created by misunderstandings, moving targets, not having the full context when making changes, unforeseen interaction between more or less complex, more or less supposedly unrelated stuff, etc. Those can probably be seen as formal property violations but that's probably a bit far fetched. I guess a bunch of researchers loving formalism or performance evaluation having no clue about software development were not going to go very far in this. Still, it's a topic probably worth researching nonetheless.
See:
- the git repository of the implementation (it's free software) [3]
- the first "serious" paper presenting the idea [4]
- the PhD manuscript if you like verbosity. It's also the only place where we speak about the distributed version, I could not manage to publish this part [5]
Though when doing a PhD, it's a worthy goal to be able do give a quick description. It also forces you to think about the goal / meaning of your work. Some topics are more easily summarized, but still.
We do science for people, it's only fair to be able to present them your work more or less roughly.
I had something for people not into computers, like: "I work on a method to find and understand computer bugs quicker and better." (Familiar with bugs? you don't like them? So you know it's useful!)
And then I could develop for the curious.
"Programs are written with code that tells the computer what to do, step by step. Like a cooking recipe. There are tools to see programs do things step by step so you can notice some step is wrong. On big programs this gets tedious. My approach helps starting this step by step investigation closer to the problematic step."
If still curious: "How? There's another method that looks at the step that looks at these steps and check they are correct with respect to some given rule. For instance, if you have a bag of objects, no step should try to remove an object if the bag is empty. This technique usually tells you something is wrong but does not tell you why it happen. I combine the first method with the second one: when some rule is broken, you are left exploring the program step by step at the point the rule broke, which is way better than doing it from the beginning". And go further / present the caveats if I feel whoever is listening is still curious.
For the people who already actually interacted with some code, I would also drop the technical words that are probably familiar to them. If you don't know whether they already actually know some stuff, they usually say the technical words themselves, to clarify.
For people who asked politely, they would receive the one sentence summary but often they want to know more if you piqued their curiosity. I had something like a progressive image of the thing that gets more and more precise to stop at the right time.
By the way you probably started skipping paragraphs in my comment at the point yours was satisfied. I made several paragraphs to allow you to do so.