Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming in the Debugger

willcrichton.net

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Programming in the Debugger

#61

Post by ndh2 »

userbinator wrote: post #18

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 productivi…

I really, really, really don't understand what it is that you're saying here. Slow compile times make better programmers? And you base that on one anecdote? And somehow your example coworker would transform into a sensible programmer if you add a Sleep(30000) in the compiler? According to you, it is better if the compiler always makes everyone wait for long periods of time than letting the programmer decide when to pause and think? What??? Are you serious?

When I build C++ stuff at home I go to great lengths to shave milliseconds off my compile time, because it is just so much better to have your program built in under 2 s than in 2 minutes.

Re: Programming in the Debugger

#62

Post by userbinator »

ndh2 wrote: post #61
userbinator wrote: post #18

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 productivi…

I really, really, really don't understand what it is that you're saying here. Slow compile times make better programmers? And you base that on one anecdote? And somehow your example coworker would transform into a sensible programmer if you add a Sleep(30000) in the compiler? According to you, it is better if the compiler always makes everyone wait for long periods of time than letting the programmer decide when to p…

Slow compile times make better programmers?

To put it bluntly, yes.

And you base that on one anecdote?

I've seen it many times; I was just giving one example.

And somehow your example coworker would transform into a sensible programmer if you add a Sleep(30000) in the compiler?

If every compile-and-test cycle took minutes instead of seconds, he wouldn't be so inclined to keep trying random changes.

Fast compile-and-test cycles can be good, but I've seen it abused more often than not.

Re: Programming in the Debugger

#63

Post by CogitoCogito »

fogzen wrote: post #37

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

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.

Re: Programming in the Debugger

#64

Post by pjmlp »

SteveJS wrote: post #58
pjmlp wrote: post #45

Earlier quoted context omitted.

I sure noticed that, I just think when we work as professional programmers are worthy of having productivity features like "Edit and Continue". I don't have to "enjoy" doing everything the hard way, just for the sake of being professional. UI/UX and language features designed for productivity, help everyone, not only newbies. What I understood from SteveJS's remark, is that although he took part designing that featur…

I think it is more than fine to use Edit and Continue as a professional. I’m acknowledging the trade offs and making an argument meant to be heard by a resistant audience that is likely to be the ones making the tool. E&C is a useful tool, just like a debugger in general is a useful tool, despite early enthusiasm for unit testing having people claim you shouldn’t use debuggers anymore, but instead write unit tests to…

Thank you very much as well for clarifying your point of view.

I fully agree with your point of view now.

Re: Programming in the Debugger

#65

Post by rurban »

Guthur wrote: post #48
lispm wrote: post #42

Earlier quoted context omitted.

Siek/Taha in http://scheme2006.cs.uchicago.edu/13-siek.pdf say > Common LISP [23] and Dylan [12, 37] include optional type annotations, but the annotations are not used for type checking, they are used to improve performance. Actually, type annotations in Common Lisp have been mostly used for three different purposes: * improving performance (by choosing specialized operations and/or removing runtime type checks/disp…

SBCL is quite good at the static checking even in the imo. Not sure what level of maturity it was at 10 years ago though.

Same. This came from the python compiler in CMUCL, in the 80ies.

Re: Programming in the Debugger

#66

Post by tincholio »

mindB wrote: post #28
fantispug wrote: post #16

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…

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?

ob-ipython works really well.

Re: Programming in the Debugger

#67

Post by alpos »

wcrichton wrote: post #53
lispm wrote: post #51

Earlier quoted context omitted.

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…

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.

> 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://www.jetbrains.com/help/idea/2018.1/debugger-hotswap....

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.

Re: Programming in the Debugger

#68

Post by alpos »

wcrichton wrote: post #32
badcede wrote: post #31

Earlier quoted context omitted.

It seems more embarrassing than entertaining.

I find this comment frustrating, just like many of the Lisp comments. Asserting a condescending statement with zero explanation. These Lisp comments aren't taking the form "oh, Lisp has something like this too, we can learn from it," instead it's, "something like this feature exists in Lisp, therefore these ideas clearly aren't new." For example on the thread about gradual typing, Common Lisp has definitely not had g…

I know that feel :)

It's just as bad in any discussion of graphics techniques, operating system features, and again in security approaches/features. Migrating to devops and security spaces has been like a conceptual "Groundhog Day".

I'm starting to think our industry is actually not so innovative and fast moving as we all like to say it is. It may be that software is merely a new engineering field and new fields begin with a wave of invention followed by reflections of reiteration as boundaries are found and concepts get refined.

Re: Programming in the Debugger

#69

Post by tom_mellior »

CogitoCogito wrote: post #63
fogzen wrote: post #37

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

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.…

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

Re: Programming in the Debugger

#70

Post by jonnycomputer »

fantispug wrote: post #16

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…

i hate actually writing code in Jupyter. part of it is just that my muscle memory is all emacs. but its not just the muscle memory, its all the features missing that I usually use but are common in an IDE or good editor. Does anyone know whether emacs ipython notebook is still viable?
Post reply on HN