Comment by sansnomme | Hacker News Reader

Comment by sansnomme | Hacker News Reader

A lot of debugging UX is editor integration. For top end IDEs, these are available out of the box. Set breakpoint by clicking left margin of any kind of code, another click to run trigger debugging. Similar story for VS Code though a bit more configuration is required. It's only an issue when it comes to lightweights like Sublime Text/Emacs/Vim. The philosophy of things being "loosely coupled" means that you have to be prepared to spend an hour browsing man pages just to figure out how to create a breakpoint. Edit and continue isn't just a fancy gimmick used in Lisp; it's a first class feature in Visual Studio (iirc it originated in the original Visual Basic, got removed during the transition to .NET before being added back again to Visual Studio, someone from MSFT should confirm this) Python is just "rediscovering" how to do this. JavaScript (in Chrome at least) have partial support, mostly because they were forced to do livereloading so frontend development isn't too unpleasant. Rust and Go and all the new age languages never seemed to have heard of it despite proclaiming their commitment to good developer debugging process (Elm might have some support though their blog releases seemed more interested in time traveling functional data structures rather than benefits to developer experience, and no, you do not need fancy stateless functions to add Edit and Continue though I suppose they do make it easier).

How about being able to debug multiple threads and processes? That would be actually useful.

> Rust and Go and all the new age languages never seemed to have heard of it despite proclaiming their commitment

Go rebuild / full rebuild times are fast enough. I don't think edit and continue would be that amazing with 1000 concurrent goroutines.

Rust will hopefully have edit and continue one day. Hopefully compiler will get faster as well... That said, I much prefer Rust compiler catching a significant portion of issues at compilation phase, thus not requiring debugging in the first place.

Pernosco can debug multiple threads and processes and yes it is useful. https://pernos.co/about/multiprocess/

I don't think I've ever seen an IDE for a multithreaded language that couldn't debug multiple threads. Most can also debug multiple processes in a single session, and some can automatically attach to child processes.

I was thinking more about everything timeouting (or otherwise losing relevant state) around debugged thread / process.

rr completely solves this problem.

I both use Windows and deal with software using shared memory. Neither of which rr can deal with.

While rr seems to be very nice, there's still room for improvement. But I guess this kind of tool might be impossible on current hardware, at least without emulation.

Edit and Continue appeared in VS 4, 5 or 6 (can’t remember which one exactly), right before the first VS for .NET which I think was released in 2002. It supported C/C++ out of the box and required quite complex linker plumbing. Second .NET VS was 7.1, releases in 2003, before MS switched to confusing year-versioning in user-facing contexts and number versioning internally (including installation directories, project files, etc), which is made way worse because these days internal versions and years are off by two or three units (ie, Vs2018 is internally version 16 or 17, can never remember). My commercial vi/vim emulator, ViEmu, supported VS.NET 7.1/2003 on its initial release in 2005, and I still maintain that build, as in I build for that target every new ViEmu release and occasionally use it (it’s a much leaner and more stable debugging environment than more recent VS versions).

Note that with the edit and continue appearing in VB he meant the immediate window in VB1, not the C++ feature. Also this didn't really appear with VB1, it most likely "appeared" with the first BASIC Bill Gates wrote (as far as Microsoft is concerned, BASIC had it before MS) as any number-based BASIC was able to both run and edit code at the same time and this was evolved to QuickBASIC/QBASIC's "immediate" pane at the bottom where you could run functions as soon as defined them in the editor and modify the program's code and state by pausing it and then this was passed on to VB1 though a dedicated window that remained there until VB6.

Reply on news.ycombinator.com