
Programming in the Debugger - wcrichton
http://willcrichton.net/notes/programming-in-the-debugger/
======
SteveJS
In VB the feature requested here was called Edit and Continue. VB users loved
it.

The original release of VB.net did not have it, and was the highest priority
feature to add back. When we added it back into Visual Studio, C# got it as
well because it’s users demanded it. Anders was trying to ensure genetics made
it into .net 2.0 and did not want the feature. I know he wrote some critiques
that it encourages producing bad code.

I added it in the debugger, while each language team had work, and there was a
massive work for the CLR.

Changing the current function is actually pretty easy .. it’s when you need to
remap the instruction pointer in functions that have been edited multiple
times and have frames trapped on a callstack across multiple threads.

~~~
pierrec
Edit and Continue also works in VS C++ and has been a godsend for me when
tweaking DSP code. This particular feature has remained unmatched by other
IDEs/toolchains for what, 15 years? That's pretty impressive stuff you've
worked on.

It's certainly not adapted to all domains, but in DSP applications where
you're looking at immediate audio/video feedback (in my case, audio synths and
effects) it makes a lot of sense to regularly switch into "tweaking mode" \-
not only in order to refine the code, but also to get a better understanding
of how small variations in each part of the code can affect the live output,
which can be a large portion of the work you'll do in DSP applications. It's
just awesome, you're working on a full-fledged application and you can turn it
into a live editor at any moment.

~~~
DannyBee
"Edit and Continue also works in VS C++ and has been a godsend for me when
tweaking DSP code. This particular feature has remained unmatched by other
IDEs/toolchains for what, 15 years?"

Edit and continue has worked in C++ toolchains and editors before VS, and
continues to work now :)

Fix and continue support, for example, existed in GDB way back in 2003 (see,
e.g.,
[http://www.sourceware.org/ml/gdb/2003-06/msg00500.html](http://www.sourceware.org/ml/gdb/2003-06/msg00500.html))
and in forks of gdb well before, which others used for C++ (hence the
"implemented again" headline).

The message covers some of the other places this was implemented.

IIRC (it's been a while), HP WDB support for this goes back to the very late
90's.

Now, i'm certainly not going to claim these IDE's were as good as VS, but they
definitely had edit and continue for C++. It's definitely a technical
accomplishment, but it's not unique.

------
Guthur
Not 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

~~~
wcrichton
Not related to your point, but I do think it's entertaining that every time I
post something about programming languages, there is always at least one
person who says "Lisp already solved it!" [1] [2]

[1]
[https://news.ycombinator.com/item?id=16726379](https://news.ycombinator.com/item?id=16726379)

[2]
[https://news.ycombinator.com/item?id=12221818](https://news.ycombinator.com/item?id=12221818)

~~~
lispm
Maybe it's because you sound like you detected new and unique (!) stuff or
that it is actually like you describe. For example:

> Jupyter presents a unique programming style

UNIQUE (!)

> But the difference between Jupyter and a REPL is that Jupyter is persistent.
> Code which I write in a REPL disappears along with my data when the REPL
> exits, but Jupyter notebooks hang around.

Sounds like a typical Mathematica notebook to me.

Macsyma (a Computer Algebra system written in Lisp) has had also Notebooks
like that:
[https://people.eecs.berkeley.edu/~fateman/macsyma/docs/intro...](https://people.eecs.berkeley.edu/~fateman/macsyma/docs/intro.pdf)

REPLs on Lisp systems have been persistent in Lisp images (not in notebook
files and not transferable) since a very long time and some display
text/graphics inline.

~~~
wcrichton
I'll grant "unique" is not an ideal world choice. I meant it not as much as
"you literally can't find this anywhere else" so much as "it's something you
don't find much these days."

And I think it's a little uncharitable to think I was claiming that wholesale,
since I explicitly reference other implementations of the same idea at the
end.

~~~
alpos
> it's something you don't find much these days

This is approach is available with all of the JVM languages too. Putting that
with what others have noted about the CLR, C, and LISP implementations, this
may be more common than rare.

[https://zeroturnaround.com/rebellabs/reloading_java_classes_...](https://zeroturnaround.com/rebellabs/reloading_java_classes_401_hotswap_jrebel/)

[https://www.jetbrains.com/help/idea/2018.1/debugger-
hotswap....](https://www.jetbrains.com/help/idea/2018.1/debugger-hotswap.html)

It may not be so much the case the people are being uncharitable as that there
really isn't much that is new or unique in software.

For my own part, I have hit that wall so many times that I now begin with the
assumption "if I can imagine how it might work, someone has probably already
done it".

That is actually nice in the sense that I nearly always have a starting
foundation when solving problems these days but also frustrating to the point
of cynicism when discoveries or inventions I put a lot of time in to turn out
to be minor variations on something 1k+ people already knew about.

------
scraft
Sometimes I look at the bug database, pick up the next highest priority bug,
have zero idea what the problem may be, sometimes there isn't any screenshots
and the description is worded so poorly it is hard to make sense of. So I
follow the repro steps, which perhaps take 15 minutes and trigger the issue.

After that I may pause execution and examine some variables and work out what
is wrong. From there I need to work out what has caused this to go wrong,
perhaps a hardware breakpoint and reloading part of the scene will help.

From doing that may be I see what triggers the hardware breakpoint, a for loop
not ending correctly or taking too long to end.

With edit and continue it maybe possible to make the fix, trigger the function
again and close the bug. Without it may require a compile, link and the 15
minutes of repro steps.

So edit and continue can massively cut down the amount of time required to fix
a bug.

It seems really weird it would be described as amateur or not professional. As
usual I suspect it is part of the trend of making everything black and white
rather than looking at things on a case by case basis.

Sure if some maths needs to be solved to fix a collision bug when the use is
drawing a line on the screen, I would work out the maths and make sure the
function is right. But if the maths is right or I don't know what is causing
the issue, edit and continue is just another tool for fast and efficient
debugging.

In my opinion...

~~~
fantispug
But would you be sure you've actually fixed the bug? Perhaps your edit changes
the state that would be reached by the continue (e.g. bug is on first
iteration of a loop, and your edit inadvertantly changes the initialisation).

I think it's useful for fleshing out a bug and could save time if there's
another issue downstream, but I wouldn't count it as solved until it has been
tested on a fresh run.

~~~
scraft
Again there is no need for black and white. Take each case as it comes. Often
edit and continue is enough sometimes you do need to stop and restart to be
sure. Sometimes you are 99% sure and that is enough when you have 4 weeks of
bugs and 1 week to ship a product. Heck sometimes you are trying to repro a
complex but and half way through hit and unrelated issue, I make a sound of
pain and someone else asks what's up, I tell them, they say it is fixed in
latest, but I can edit and continue a fix now to save having to spend ages
reproing. There are loads of times the feature is useful. I would suggest the
people finding it amateur and not useful aren't using it correctly or at
sensible times.

------
fantispug
I use this kind of workflow all the time in Emacs. I write code in one window
and have a Jupyter REPL in the other and send code to the REPL to test things
live as I'm coding.

I'll have "pdb" set up in Jupyter REPL so it drops into a debugger when I have
an error with a function.

In the case of a long running function I want to debug (like the video example
at the end) I'll set local variables with the same names as the variables of
the function and then execute the function line-by-line/chunk-by-chunk.

The only problem is losing track of global state, but the same thing can
happen in Jupyter notebooks.

This type of workflow is really common in Lisp and R.

If I want to integrate documentation and code, I'll use org-babel or R
Markdown (which does work with Python).

~~~
mindB
What do you use for running the jupyter REPL in emacs? I haven't found a great
way of doing so yet. Just running it in a comint buffer?

~~~
meken
If you connect your code buffer to an jupyter notebook via Emacs IPython
Notebook [1] then you can hit C-c C-o (ein:console-open) which will launch a
jupyter REPL.

\- [1] [https://github.com/millejoh/emacs-ipython-
notebook](https://github.com/millejoh/emacs-ipython-notebook)

~~~
mindB
Looks like that just calls make-comint-in-buffer eventually[1] with some fancy
stuff to make sure it connects to the same jupyter server as being used for
ein. Not sure I see a lot of utility there if I'm just wanting to run a
jupyter REPL next to a regular code buffer or e.g. org-mode.

[1] [https://github.com/millejoh/emacs-ipython-
notebook/blob/cfd0...](https://github.com/millejoh/emacs-ipython-
notebook/blob/cfd0e8a3d7edd0f82324568bc80ac92c4bdccf91/lisp/ein-
console.el#L226)

------
userbinator
I've seen others do similar things (including beginners I was trying to
teach), although in languages like C/C++, and I do not think it is a good idea
at all. It leads to "tunnel vision" and concentrating on small pieces at a
time while ignoring the "big picture" as well as mindless fiddling with code
in an attempt to "get it to work", which pretty much leads to worse code
quality overall and a decrease in productivity. I suppose it may _feel_
productive to be making lots of small changes and seeing the results
immediately, and somewhat addictive too, but my experience says that it's not.
I recall helping a coworker who had spent several hours messing around with a
small fragment of code that he was sure was causing a bug; he had made lots of
little changes and yet the problem remained, but was reluctant to look
somewhere else because he was almost addicted to that allure of "just one more
little change... hope this fixes it...!" I told him to stop doing that and
think more about the data coming into that piece of code and going out, which
it turns out in its original unmodified form was perfectly fine --- the
problem was actually somewhere else, and later was fixed in a few minutes
after he made that realisation. If I hadn't intervened I would not be
surprised if he spent another few days of fruitless labour.

The other thing that this sort of interactivity/short-edit-continue-cycling is
heavily promoted for is learning, which IMHO is probably the worst way to do
it; it's essentially encouraging programmers to write code without actually
understanding what they're writing, and when it doesn't work, to try random
things until it does. That's no way to write good software.

It's better to spend more time thinking about the problem, writing, and then
proofreading code before even trying to compile and run it, than try to write
something you vaguely think may work and then spend much more time debugging
and "fixing" it. Those from the latter school of thought are often surprised
when they see me write several hundred lines of code and it works perfectly
the first time. To me, it's the other way around... seeing those who can't
write more than a few words without making blatant syntax or logic errors.

In other words, "reducing the cost of mistakes" may only encourage making
them; and in any case, does not discourage it.

~~~
SteveJS
It’s useful to realize Edit and Continue is not for professional programmers,
and the qualities we’d most want are not appropriate to every problem.

The horrible code you inherited as the programmer brought on is because some
non-professional domain expert made a ‘hairball of extreme utility’ that
unlocked product-market fit on back of a mess of experiments.

VB’s persona was ‘Mort’, _literally_ a scientist trying to get an answer, or a
business person trying to solve a problem, not a programmer trying to build a
system. It’s 99 hairballs of no utility and 1 that wouldn’t have been built
otherwise because no one knew it was useful until it exists.

Some categories of UI experience problems lend themselves to simply making the
trial loop as quick as possible.

It is also true that understanding a dataset has an initial experimental
component. No amount of thinking about code is going to tell you the dataset
has a fatal flaw, until you discover it.

~~~
fantispug
There are lots of interesting problems with interacting with external
underdocumented systems.

I find edit and continue really useful for making something worm with these.

Are these out of the reach of "professional programmers"? Can they only work
on systems with fully specified models, with exacting requirements?

~~~
SteveJS
I agree with you and poorly worded this for a larger audience that doesn’t
have the full context of design decisions on the feature.

As an example ... for a ‘professional programmer’ there is an argument that
allowing E&C to work if you edit in vim or emails is a feature. For what we
needed to accomplish that is an anti-feature.

~~~
SteveJS
I should probably not care, but i do: Emacs, not emails. I should also not
write these on an iphone.

------
gidim
My biggest issue with notebooks is that we're throwing aways years of best
practices. Notebooks often lead to untested code with poor structure, frequent
use of global variables and readability issues. Even using it as debugger is
limited since there's no way to step into functions.

~~~
jonnycomputer
but who builds whole applications in a notebook anyway? most software dev best
practices are really out the window when what you are doing is data analysis,
or explication, or putting together reports.

~~~
meken
I have built several dashboards with nothing but jupyter notebooks + jupyter
widgets [1] with the help of jupyter-dashboards [2]. Granted they were little
more than api calls followed by visualizations.

\- [1] [http://jupyter.org/widgets](http://jupyter.org/widgets)

\- [2]
[https://github.com/jupyter/dashboards](https://github.com/jupyter/dashboards)

------
meken
> 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).

\- [1] [https://github.com/ebanner/pynt](https://github.com/ebanner/pynt)

~~~
fizixer
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.

~~~
wcrichton
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.

~~~
meken
Agreed. Indeed, the original punchline I had for pynt (the tool I linked
above) was "Jupyter notebooks for software engineers". The idea being that
software engineers might look at jupyter notebooks and think "they look cool,
but my code isn't in a jupyter notebook, so it looks like I can't use them".

I'm curious for what ideas you have that you think jupyter notebooks (or other
interactive programming tools) would have the most promise for gaining
adoption amongst software engineers.

One pynt feature I had going facilitated a "debugger-driven development"
workflow where when your code hits an exception it would save the state and
generate a jupyter notebook with your code in it, hence allowing you to fix
the bug faster.

------
fizixer
Programming 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.

~~~
meken
> Programming in the debugger is a massively overlooked paradigm.

I wonder if the tool I mentioned in [1] facilitates the workflow you have in
mind? It promotes a workflow of setting a breakpoint at the beginning of a
function, attach a jupyter notebook to it, dump your code into a jupyter
notebook, edit the code in there, and then paste the result back into the code
buffer (once you've verified everything checks out locally).

One reason I suspect the debugger is not seen as part of the software
engineering process (i.e. to extend or modify code) is because of the editing
capabilities within a debugger CLI are usually very primitive. At least with
pynt, the "debugger" (i.e. the jupyter notebook) is still in emacs so you can
leverage all the strengths of your editor while doing interactive programming.

> let alone making programmability more important than interactivity,
> something I believe in

Can you elaborate on what you mean here? Maybe give an example of a
programmable gdb feature that you think would be useful?

\- [1]
[https://news.ycombinator.com/item?id=16899023](https://news.ycombinator.com/item?id=16899023)

~~~
fizixer
I thought about this idea at a deeper level long time ago and don't remember
all the details (and don't have the notes in front of me) but here are two
points related to that:

\- Programmable debugger would be a massive benefit to compiled langauges like
C, and not as much of a benefit for interpretive systems like Python.
Especially with the REPL mode of programming in Python (you run something,
don't like the results, try something else, then move to next step) is already
a pretty effective way to do exploratory prototyping. A programmable gdb would
allow REPL like workflow for C.

\- As an example, let's say a C program seg-faults at a certain point in code.
If you run your C program inside gdb, gdb will stop there and let you do some
exploration. That exploration is very tedious if you can't programmatically
manipulate your registers and memory areas. In principle, you should be able
to write an arbitrarily complex program to bring the seg-faulted state back
into a functioning state, and then when the code continues, you don't get the
seg-fault again, and you didn't even have to rerun the code.

One use case in which this is massively useful is long running scientific
programs. You start a complex scientific simulation based on a C program and
it is expected to run for, let's say, 48 hours, but it seg-faults in the 46th
hour! If you run it in a programmable gdb you could fix the seg-fault right
then and there, and continue the program instead of trial and error of
multiple runs, each run taking 46 hours before you know if your fix worked or
not.

I think this scenario might require more than just a programmable gdb, e.g.,
it might require a way for the program to be recompiled and put in memory
replacing the older buggy program, before the program has actually finished.
But a programmable gdb would be a big part of that system.

------
_bxg1
Another 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.

------
fogzen
This has been possible for 50 years at least, and the lisp, smalltalk, and
functional programmers have been doing this for a long time now.

After programming my whole life I have to say this industry is surprisingly
math averse, regressive, and led by cargo cults.

What wheel will we reinvent next week!? Stay tuned...

~~~
CogitoCogito
Yeah the article is a little bizarre. E.g.

> This works exactly as intended! We were able to edit our program while it
> was running, and then re-run only the part that needed fixing. In some
> sense, this is an obvious result—a REPL is designed to do exactly this,
> allow you to create new code while inside a long-running programming
> environment. But the difference between Jupyter and a REPL is that Jupyter
> is persistent. Code which I write in a REPL disappears along with my data
> when the REPL exits, but Jupyter notebooks hang around. Jupyter’s structure
> of delimited code cells enables a programming style where each can be
> treated like an atomic unit, where if it completes, then its effects are
> persisted in memory for other code cells to process.

> More generally, we can view this as a form of programming in the debugger.
> Rather than separating code creation and code execution as different phases
> of the programming cycle, they become intertwined. Jupyter performs the many
> functions of a debugger—inspecting the values of variables, setting
> breakpoints (ends of code cells), providing rich visualization of program
> intermediates (e.g. graphs)—except the programmer can react to program’s
> execution by changing the code while it runs.

I just don't understand what's so amazing about this. This is total standard
debugging. In python you can do it with with the built-in debugging module
pdb:

    
    
        import pdb; pdb.set_trace()
    

Or you can run your script with

    
    
        python -m pdb script.py
    

Also the REPL doesn't just exit, it only exits if you allow it. E.g. if you
call the script as

    
    
        python script.py
    

it will exit, but you can also call it as e.g.

    
    
        python -i script.py
    

or do any number of things and it will not exit.

I mean it's great that more people start debugging code, but calling this a
feature of jupyter is a little ridiculous. The exact same feature exists in
the python REPL and that's reflected in jupyter.

~~~
tom_mellior
I think the article's point is that you don't restart script.py again and
again but start it _once_ , then _modify_ it while it's running, and once you
are happy with the final debugged version, the script.py program saved on your
hard disk is that final debugged version.

You can sort of do something like this with REPLs, by copying code around
between an editor window and a REPL window until you are satisfied that it's
what you want. But you have to keep the REPL and the editor in sync manually.
For example, if by experimenting in the REPL or debugger you find a bug that
requires changes to three functions, you must either change them in the editor
and copy all off the changes to the REPL to test the new program state; or you
can redefined them in the REPL's less-than-ideal editor and then make sure to
copy the updated versions to the real editor to save them in the source file.

I've worked with a few systems that were _not_ REPL-based but more notebook-
based, and it's very cool if the system keeps track of stuff for you. In
particular, Coq and Isabelle have such environments.

(I've never worked with Jupyter, but I think I should give it a try.)

------
nikitakit
I'm interested if anyone has good tools for this kind of workflow, especially
for Python.

As others have mentioned in the comments it seems that similar workflows have
existed across a number of languages and IDEs for many years, but it seems
that they haven't really caught mainstream attention (in the sense of there
being common conventions that multiple languages and tools follow).

For my own workflow, I have a debugger-like tool for IPython
([https://github.com/nikitakit/xdbg](https://github.com/nikitakit/xdbg)) that
lets me set a breakpoint anywhere in my code and resume the current Jupyter
session once the breakpoint is reached, making sure that scope is properly
adjusted to provide access to all local variables. When combined with text
editor integration (such as
[https://github.com/nteract/hydrogen](https://github.com/nteract/hydrogen)),
this is the best I've managed to come up with in terms of minimizing the
"penalty for abstraction" while maintaining interactivity.

~~~
meken
Interesting approach. I hadn't thought of using a single notebook to adjust
the scope and enter into functions. I my tool I take a one-function one-
notebook approach because that's how I did it by hand for a long time.

~~~
nikitakit
I'm curious how you handle the issue of scope in pynt.

From what I see in the readme, a lot of the features are about extracting code
snippets from the source file and sending them to the notebook. But when
you're trying to interactively edit a function that's deep in the call stack,
there's a question of how to pause execution right as the function is being
called and set up the execution scope for the REPL/notebook.

I actually think handling scope is perhaps the key issue for interactive
programming. If the global scope is easier to interact with than anything
nested, you continue to have a "penalty for abstraction". This is the case
even if your language is purely functional/reactive/supports reversible
debugging -- in some of his talks about Eve, Chris Granger mentioned how scope
proved to be a real challenge even in a functional programming setting (IIRC).

This is one of the reasons I prefer Hydrogen to Jupyter notebooks. In a
notebook all cells are toplevel, whereas in hydrogen I can select any chunk of
text (or chunk of the AST) and execute it. It's not as good at presenting
computational narratives, but much better for interactively changing an
existing program to do something new. There's still a lot of issues on the UI
front though, so I'm definitely interested in any ideas about that.

~~~
visarga
I thought about this problem - how to have interactivity and a nice editor at
the same time, so I created a solution based on IPython.

I am using an inline ipython shell to interact with the local variables from
any scope. I just drop a call to "DBG()" (how I called it) where I want to
take a peek. In order to write the code, I use a normal program editor and
work remote with SSH. The only drawback is that I have to exit and reload the
program for each change in the source files, but at least I have direct access
to all scopes.

When I start a new program the last instruction is a call to DBG(). I compose
functions in the REPL and move them to the source file, above the DBG call. I
love the interactivity, ability to inspect, compose and test until I get the
code right, while at the same time being able to structure larger source files
in a nice editor.

Here's the library: [https://github.com/horiacristescu/romanian-diacritic-
restora...](https://github.com/horiacristescu/romanian-diacritic-
restoration/blob/master/debug.py)

Pros: lightweight, access all scopes, works remote, you can use your text
editor

Cons: no inline graphics

------
DC-3
> Jupyter presents a unique programming style where the programmer can change
> her code while it's running....

Is the author trying to make some kind of statement by using 'her' as a gender
neutral third person pronoun? Surely, if this is something they care about
(and reasonably so), 'their' would be the logical choice? It's frustrating
that the author chooses to be deliberately obtuse in their use of language -
to the (slight) detriment of readability.

~~~
wcrichton
I understand "their" as a plural, so for lack of it, there are no good gender-
neutral singular third person pronouns. In my writing I've quite often used
"he" in the past, so I try to keep it balanced. I don't consider this
deliberately obtuse, since I find it just as disorienting to see "their" used
in a singular context.

~~~
DC-3
That's interesting, since 'her' in this context causes something equivalent to
a Parse Error in my brain, but 'their' flows completely naturally for me.

~~~
Leszek
Perhaps that's something you should evaluate about yourself then, because I
don't think you'd raise the same ParseError if the profession were "nurse".
Unconscious biases don't have to be malicious to exist, and I catch myself
thinking the way you describe sometimes before realising "wait, this should be
fine though".

~~~
DC-3
It's nothing to do with the fact that it's about software development, I don't
think (or at least hope). I just find it jarring to see 'her' used as an
'abstract' gender neutral pronoun. In my mind, 'his' has two semantically
distinct definitions, and 'her' has just one - and that's just how the English
language works.

~~~
Leszek
Agree to disagree on this being a universal 'abstract' gender neutral pronoun
problem, and not being profession related.

------
pjmlp
I do it all the time since I started using Borland tools in MS-DOS.

Already in Turbo Pascal 5.5, one would loose the context, but the compilation
times were so fast that it hardly mattered.

~~~
LoSboccacc
I used to do it all the time too and hated having to write javascript
precisely because of the toolchain limitations.

Eventually I settled for Chrome Debugger once they added the ability to map
the code to a workspace folder, so I mapped the webstorm project where the
files came from, closing the loop. however webstorm doesn't republish until I
alt+tab to it and doesn't have a local history feature as nice as Eclipse, but
it's close. also any query parameter on the scripts breaks the mapping to the
files - I append a build version tag, for caching, and had to have that
removed in local tests.

------
Noumenon72
I skimmed a bit because this sounds just like how Eclipse debugger will jump
back to the start of a function if you change the code in it, mixed with the
Display tab that lets you write code using all the variables in the current
scope. I don't use it while writing my own code, but it's invaluable for
figuring out surprises in other people's.

------
coliveira
The 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).

------
gunnihinn
I keep thinking I should be more interested in Jupyter than I am.

Maybe someone who knows things can tell me this: Can I use it to develop and
debug larger existing programs? That is, can I take 10k lines (say) of Python,
that are spread across some modules, load them into Jupyter, not get a
horrifying mess, and work on my program?

~~~
meken
I think so and that's the goal of my tool (do a Ctrl-f for pynt on this page -
I don't want to spam the link too many times).

This functionality is also present (somewhat) in pycharm where you can attach
a jupyter console to any region of code. Though, that's just a console and not
a notebook.

------
Tycho
I think it’s good to have all these different approaches at your disposal. I
like having the powerful features of an IDE like PyCharm (including the
debugger) but sometimes hop over to Jupyter to try stuff out in a different
space.

------
nqzero
this 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

