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

31–40 of 89 posts

Re: Programming in the Debugger

#31

Post by badcede »

wcrichton wrote: post #11
Guthur wrote: post #6

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

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 [2] https://news.ycombinator.com/item?id=12221818

It seems more embarrassing than entertaining.

Re: Programming in the Debugger

#32

Post by wcrichton »

badcede wrote: post #31
wcrichton wrote: post #11

Earlier quoted context omitted.

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 [2] https://news.ycombinator.com/item?id=12221818

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 gradual typing since the concept didn't exist until the last 10 years (distinct from optional static typing). Yet that does not stop the commenter from asserting "oh Lisp has had this for forever" without any further discussion or nuance.

Re: Programming in the Debugger

#33

Post by fantispug »

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?

Yeah, just comint with elpy. There are some rough edges; I can't input multiline in the comint buffer (but can send it), and gives an error on the very first command, but otherwise works well.

Re: Programming in the Debugger

#34

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

Re: Programming in the Debugger

#35

Post by pjmlp »

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 think the point isn't asserting that it isn't new, rather it is a sad state of affairs that many tools are still playing catchup with developer tools of the 80's.

For example, every time we discuss Lisp on HN, many talk about SLIME, SBCL and such.

Yet, the actual modern experience of what it meant to use Lisp on its glory days lives on Allegro Common Lisp and Lispworks.

Reading papers from Xerox PARC research always makes me sad that many think replicating a PDP-11 is the ultimate developer experience.

Re: Programming in the Debugger

#36

Post by pjmlp »

SteveJS wrote: post #22
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…

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

> Edit and Continue is not for professional programmers

Then I prefer to be called an amateur, as I really like using that feature, instead of loosing my debugging context and starting everything from scratch, some times spending several minutes trying to replicate the issue that landed me there.

Re: Programming in the Debugger

#37

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

Re: Programming in the Debugger

#38

Post by 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) 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), this is the best I've managed to come up with in terms of minimizing the "penalty for abstraction" while maintaining interactivity.

Re: Programming in the Debugger

#39

Post by LoSboccacc »

pjmlp wrote: post #34

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.

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.

Re: Programming in the Debugger

#40

Post by shakna »

nn3 wrote: post #7
fizixer wrote: post #4

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…

You should check out ups http://ups.sourceforge.net/ 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

Similarly, Cling, from CERN [0], not the easiest thing to set up, but interactive C++ programming using a JIT interpreter.

And I can't mention Cling without what they're trying to replace CINT [1], which gives you C and C++ programming, but with a rather slow interpreter.

[0] https://root.cern.ch/cling

[1] https://root.cern.ch/cint

Post reply on HN