Programming in the Debugger
willcrichton.net
Programming in the Debugger
1–10 of 89 posts
Re: Programming in the Debugger
#2> Interactive editing and debugging is limited to top-level code.
Very true. When programming in jupyter notebooks I often put off wrapping my code in a function because it becomes harder to interact with and debug. But this obviously becomes problematic when you want to leverage code reuse and abstraction.
In order to tackle this (somewhat) I made a tool [1] which allows you to take code anywhere and get it back into a jupyter notebook and make it top-level (e.g. function function/method and loop bodies).
Re: Programming in the Debugger
#3> Interactive editing and debugging is limited to top-level code. Very true. When programming in jupyter notebooks I often put off wrapping my code in a function because it becomes harder to interact with and debug. But this obviously becomes problematic when you want to leverage code reuse and abstraction. In order to tackle this (somewhat) I made a tool [1] which allows you to take code anywhere and get it back int…
This has been one of my major gripes with ipython/jupyter notebook workflow.
And I realized that, past an intermediate level of expertise in this ecosystem, you could really benefit from dropping down to JSON of your notebook and doing a bit of "metaprogramming" (the way you did). Yet the jupyter development team doesn't appear to be taking that into account, i.e., not making it easy/consistent for users to programmatically manipulate their notebooks.
Re: Programming in the Debugger
#4Programming in the debugger is a massively overlooked paradigm. We use gdb for interactive usage. You could become a super-productive programmer if you can use gdb programmatically. The possibilities are endless. The problem: gdb developers don't think of that kind of usage as a core part of the software (let alone making programmability more important than interactivity, something I believe in). And that's why it's one of my goals to develop a programmable debugger in the future if I get some time.
Re: Programming in the Debugger
#5this was how i wrote matlab - stub out a function, set a breakpoint, run the app, manipulate the variables in the debugger till the algorithm is working, copy and paste back into the editor, save and run again
all without touching the mouse
Re: Programming in the Debugger
#6Not a very unique style as claimed though. Common Lisp implementations often have a very full featured debugger coupled with conditional restarts the experience is awesome and really should be a preresquite for any dynamic language to be called fit for serious application. Unfortunately it is often absent
Re: Programming in the Debugger
#7Programming in the debugger is a massively overlooked paradigm. We use gdb for interactive usage. You could become a super-productive programmer if you can use gdb programmatically. The possibilities are endless. The problem: gdb developers don't think of that kind of usage as a core part of the software (let alone making programmability more important than interactivity, something I believe in). And that's why it's…
You should check out ups
It has a builtin C interpreter which allowed you to dynamically add and change code while debugging.
Unfortunately the code has somewhat bitrotted, so it's hard to use on a modern Linux system
Re: Programming in the Debugger
#8The shortcoming presented by the author is exactly why I don't like Jupiter. It gives you a lot of power for simple things, but when you start to create more complex algorithms it gets into the way of a true debugger, which you could access when using a standard python environment (or any other language for that matter).
Re: Programming in the Debugger
#9Another great example of this is editing CSS in the Chrome inspector. It makes it easy to see where values are derived from, and add/toggle new rules and classes inline. It's a lifesaver when your UI rendering relies on a bunch of JavaScript state that you don't want to recreate each time you tweak a color.
Re: Programming in the Debugger
#10> Interactive editing and debugging is limited to top-level code. Very true. When programming in jupyter notebooks I often put off wrapping my code in a function because it becomes harder to interact with and debug. But this obviously becomes problematic when you want to leverage code reuse and abstraction. In order to tackle this (somewhat) I made a tool [1] which allows you to take code anywhere and get it back int…
This has been one of my major gripes with ipython/jupyter notebook workflow. And I realized that, past an intermediate level of expertise in this ecosystem, you could really benefit from dropping down to JSON of your notebook and doing a bit of "metaprogramming" (the way you did). Yet the jupyter development team doesn't appear to be taking that into account, i.e., not making it easy/consistent for users to programma…
I would love to see "Jupyter for power users." I think the programming language tooling community needs to take a serious look at how interactive programming interfaces could work in the development cycle for all expert programmers, not just novices or data scientists.