If you aren’t interested in Conjure or the languages it supports I hope you can at least take the ideas of conversational software development with you.
This article, particularly the term he is coining, makes me think of Jupyter. It has similar features, although to goal of a “Computational Narrative” is aimed at conversing with someone else reading the code, instead of strictly conversing with the programmer (although I use it to converse with the programmer for many of the reasons outlined here). This article points out that other languages recompile and run from the start, so Jupyter creates a REPL environment for each of the kernels it supports, giving you the same sort of granular conversation for a specific chunk of code.
I have found the idea of a conversation or narrative of the code is especially helpful for people new to programming to be able to learn how to think about structuring a program and to be able to more quickly modify an existing project for slightly different purposes, increasing their confidence and desire to learn more. To that end, I think tools like Conjure and Jupyter are really important for bringing more ino the fold of programming.
We have no way to question our program, if we want to see a specific value at a point in time we have to insert multiple log statements and restart it each time until we get the information we need.
This is wrong. Debuggers (and in particular, time traveling debuggers such as RR) let you ask such questions to your programs and in a much better way than logs let you. With time traveling, you can break at some point in your program, look at the program state, add watchpoints to variables that are “wrong”, rewind your program to understand what changed the variable… RR turns the art of debugging into a science.
Don’t get me wrong, I still think that repls are nice. But I find that they don’t scale well and quickly become impossible to use on very large (tens of millions of LOC) programs. Meanwhile, debuggers work like a charm.
Mind if you elaborate on repls not scaling well? From what I’ve gathered the whole point of this ‘conversational’ approach is to scale (hot-patching, compared to having to recompile and rerun every incremental change)
Pretty much all Clojure development is done interactively via the REPL by connecting the editor to a running instance of the application, and I use the REPL all the time to develop large scale apps. I think the language plays a role here. Since Clojure defaults to immutability, and most of the code is written using pure functions, you rarely need the kind of debugging you’d use in an imperative language. Vast majority of the time you don’t need to trace state through the application, but you’re looking at a particular function you want to change in some way.
The idea that you’re just using printing to the console is also incorrect. Tools like this allow you to capture local state that you want to debug, and actually work with that state in a separate REPL. It’s a strictly more effective approach than debugging because you can get a program in a particular state, fix the problem within the scope of that state interactively, and keep going. All the debuggers I’ve used either don’t allow you to modify state during debugging, or have a fairly limited scope of what can be changed. So, you can use the debugger to trace, but then you have to restart and rebuild the state when you make any significant code changes completely breaking your workflow.
As a side note, I don’t really see why any application should be structured as a monolith with millions of LOC all coupled together. Any large project can, and should be, broken down into smaller isolated components that can be reasoned about independently. This also has the benefit of making code modular and reusable.
All the debuggers I’ve used either don’t allow you to modify state during debugging, or have a fairly limited scope of what can be changed.
That’s interesting, what are these debuggers? I never tried to use anything else than GDB on large programs and the set and call commands let you modify state.
So, you can use the debugger to trace, but then you have to restart and rebuild the state when you make any significant code changes completely breaking your workflow.
I think this has never been a problem for me, I’ve always been able to create minimal reproducers for the bugs I’ve worked on. But I can imagine this is true for bugs in GUI programs that require lots of interactions to happen.
As a side note, I don’t really see why any application should be structured as a monolith with millions of LOC all coupled together.
Me neither and yet these applications exist and need to be debugged :).
Java debuggers will typically allow limited amount of modification and reloading within the scope of a method. I’m not just talking about modifying state, but changing the code at runtime. If I spot a problem and I want to change the code, I want to be able to reload it and keep going without having to restart the process.
And I’m glad people are putting the work to debug these existing applications, it’s just not my cup of tea. :)
This article, particularly the term he is coining, makes me think of Jupyter. It has similar features, although to goal of a “Computational Narrative” is aimed at conversing with someone else reading the code, instead of strictly conversing with the programmer (although I use it to converse with the programmer for many of the reasons outlined here). This article points out that other languages recompile and run from the start, so Jupyter creates a REPL environment for each of the kernels it supports, giving you the same sort of granular conversation for a specific chunk of code.
I have found the idea of a conversation or narrative of the code is especially helpful for people new to programming to be able to learn how to think about structuring a program and to be able to more quickly modify an existing project for slightly different purposes, increasing their confidence and desire to learn more. To that end, I think tools like Conjure and Jupyter are really important for bringing more ino the fold of programming.
This is wrong. Debuggers (and in particular, time traveling debuggers such as RR) let you ask such questions to your programs and in a much better way than logs let you. With time traveling, you can break at some point in your program, look at the program state, add watchpoints to variables that are “wrong”, rewind your program to understand what changed the variable… RR turns the art of debugging into a science.
Don’t get me wrong, I still think that repls are nice. But I find that they don’t scale well and quickly become impossible to use on very large (tens of millions of LOC) programs. Meanwhile, debuggers work like a charm.
Mind if you elaborate on repls not scaling well? From what I’ve gathered the whole point of this ‘conversational’ approach is to scale (hot-patching, compared to having to recompile and rerun every incremental change)
I’m retracting my claim as I just realized that debuggers are actually just REPLs for binaries.
Pretty much all Clojure development is done interactively via the REPL by connecting the editor to a running instance of the application, and I use the REPL all the time to develop large scale apps. I think the language plays a role here. Since Clojure defaults to immutability, and most of the code is written using pure functions, you rarely need the kind of debugging you’d use in an imperative language. Vast majority of the time you don’t need to trace state through the application, but you’re looking at a particular function you want to change in some way.
The idea that you’re just using printing to the console is also incorrect. Tools like this allow you to capture local state that you want to debug, and actually work with that state in a separate REPL. It’s a strictly more effective approach than debugging because you can get a program in a particular state, fix the problem within the scope of that state interactively, and keep going. All the debuggers I’ve used either don’t allow you to modify state during debugging, or have a fairly limited scope of what can be changed. So, you can use the debugger to trace, but then you have to restart and rebuild the state when you make any significant code changes completely breaking your workflow.
As a side note, I don’t really see why any application should be structured as a monolith with millions of LOC all coupled together. Any large project can, and should be, broken down into smaller isolated components that can be reasoned about independently. This also has the benefit of making code modular and reusable.
I agree.
That’s interesting, what are these debuggers? I never tried to use anything else than GDB on large programs and the
setandcallcommands let you modify state.I think this has never been a problem for me, I’ve always been able to create minimal reproducers for the bugs I’ve worked on. But I can imagine this is true for bugs in GUI programs that require lots of interactions to happen.
Me neither and yet these applications exist and need to be debugged :).
Java debuggers will typically allow limited amount of modification and reloading within the scope of a method. I’m not just talking about modifying state, but changing the code at runtime. If I spot a problem and I want to change the code, I want to be able to reload it and keep going without having to restart the process.
And I’m glad people are putting the work to debug these existing applications, it’s just not my cup of tea. :)