Hacker News Reader

Comment by gnaritas | Hacker News Reader

If you've never written code in a live debugger session, moved the execution point back up, and immediately run over the code you just wrote, you have a crappy debugger. VB6 could do this, Smalltalk does this, it's not dangerous, it's damn productive.

View on HN

VB6... got so much hate but folks just don't seem to see how useful it's debug mode was.

Oh sure... VB6 and good OO design and modern practices (unit tests, dependency injection, etc) don't mix. But... if you need to sit down and "hack out" a bunch of working code quickly it was pretty hard to beat.

Python with the VB6 ide/debugger experience would likely take the scientific computing field by storm.

I miss it... especially since I've never been able to get "edit & continue" to work at all in Visual Studio.

You mean like this?

https://www.visualstudio.com/en-us/features/python-vs.aspx

I never got this to work properly.

You can do 'proper' OO, unit tests, and dependency injection with VB6, it's just not as easy as it could be, and most developers didn't, partly because unit tests and dependency injection weren't as popular at the time, but (with 'proper' OO and dependency injection) many apps were simple enough that these things were perceived as of little importance.

When I last wrote some VB6, I was criticised by a colleague for 'over-engineering' because, to build a cancellable progress dialog, I used a (very simple) observer pattern. He didn't understand what it was or how it worked - and would have preferred to simply block the entire UI while a process ran (without the ability to cancel, even). To him, even basic OO ideas were pointless and dangerous over-'designing'.

If your application was crap, it could also remain incredibly simple in terms of design, though inevitably multi-thousand line methods and hacks upon hacks led to completely non-understandable, buggy, and brittle code, so I'm sticking to my 'enough design' principles!

One more aside: This developer complained that there was a bug in the VB6 IDE because it wouldn't let him add any more code to a file - he'd written such a huge code file that he'd actually hit the IDE's limit. I tried talking about modularisation, refactoring, etc... then just gave up.

VS does this and I've used .NET since its start. It's useful now and then, but a REPL is far more useful. Considering the cost of Edit-and-Continue I'm not sure it's worth it. I'd have much prefer MS to have spent the effort on improving language tech or working on REPLs.

REPL is OK, work-spaces are much better, ala Smalltalk. The best analogy is like a SQL editor, you can simply write anything and execute it in place. The notion one needs to enter one line at a time, aka the REPL, is quaint; not something to really be desired except from languages that have neither.

REPLs don't have to be one line at a time. F# interactive and C# interactive work well with Visual Studio. And at worst, it's a simple UI issue. Like various SQL UIs, nothing stops a REPL from being a big textbox then letting you select text and "run".

Do Smalltalk workspaces do something fundamentally different?

Well, in Smalltalk everything everywhere is an execution environment; anywhere you can type, you can highlight and execute code. But it seems we have different definitions of REPL, to me a REPL is a command line; a textbox isn't a REPL, it's a workspace. Sure they're both code executions environments, but working with them is vastly different.

When using common lisp on SLIME you can type your code in the buffer, select it and have have it eval'ed. The result will be printed in the repl buffer instead of next to the cursor, but that's a pro to me.

When I tried out pharo I was pressing backspace all the time because outputs are not valid code and thus would break the highlighting.

Anyway, a repl is just that, a read eval print loop. If you interface with it using a command line or other means is just an implementation detail.

How do you make sure there's no corrupted state and that the data structures in memory fit the new code?

You don't. Worst case is you had wrong assumptions and restart the program, same as if you didn't have the ability to change things.

Best case thought, it's so useful. It's also incredible for editing tunables on the fly(think videogame gameplay values, layout values for UI, etc).

Editing tunables is possible without recompiling new code. It's just setting the variables to new values.

Not if you want to change the formula the the tunable uses.

Worst case is you don't know you broke consistency. Then you can waste hours hunting for ghost bugs that only occur because of the hot-code-reload.

As someone who worked on dynamic updating research projects for years I can attest to the really shitty bugs dynamic updating can cause.

I believe changing data structures gives a "you must restart to make this change" when resuming debugging. It's mainly for code flow type bugs rather than data structure type bugs.

For things that require restarting in Visual Studio, look in the docs for the topic of rude edits.

In Smalltalk, most of the class library, and hopefully your own codebase, is either side-effect free or at least well encapsulated. The classic trip-up in Smalltalk was with Streams. An experienced Smalltalker would make note of where the code was fiddling with Streams, then go down the stack until the debugger has effectively gone back in time before the Stream objects were instantiated. Try that for a few seconds, then restart the app. If your environment was set up intelligently, none of that would take that long.

If the data structures in memory don't fit the new code, I suspect that's a compiler bug.

Reply on news.ycombinator.com