Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Taking the Pain Out of Debugging With Live Programming

samzenpus posted about a year ago | from the we'll-do-it-live dept.

Programming 254

angry tapir writes "'Everyone knows that debugging is twice as hard as writing a program in the first place,' Brian Kernighan once wrote (adding: 'So if you're as clever as you can be when you write it, how will you ever debug it?') However, Sean McDirmid, a researcher at Microsoft, has been working to remove some of the pain from debugging. McDirmid, based at Microsoft Research Asia, has been studying ways of implementing usable live programming environments: a solution that is less intrusive than classical debuggers. The idea is to essentially provide a programming environment in which editing of code and the execution of code occur simultaneously — and in the same interface as code editing — with tools to track the state of variables in a more or less live manner."

cancel ×


Visual Studio (-1, Troll)

John Wagger (2693019) | about a year ago | (#43451773)

I've personally fallen in love with Visual Studio. It's definitely the planets most feature-rich and capable IDE. It supports wide array of languages, has great debugging options and performs really well. The best thing is that Visual Studio Express [] is completely free.

It's also great to see Microsoft Research's latest offerings. They have always been the monolith research club of the industry. It's nice to see that Microsoft is really dedicated to support research.

That being said, I'm quite sure we will see the fruits of this research in an even better Visual Studio based product. Microsoft really cares about programmers and developers and helps all of them write efficient and clean code. Helping the debugging process is just second part of it.

I would, however, also love to see better support for debuggers like OllyDbg [] . It's basically assembler level debugger for programs that have been already compiled. It's binary code analysis is unmatched in the industry. Compiling these two will lead to synergies.

All in all, Microsoft Visual Studio keeps getting better!

Re:Visual Studio (1)

Anonymous Coward | about a year ago | (#43451823)

Compiling these two will lead to synergies.

Obvious troll is obvious.

Re:Visual Studio (2)

Chrisq (894406) | about a year ago | (#43452189)

Compiling these two will lead to synergies.

Obvious troll is obvious.

Do you mean shill? If so I agree.

Re:Visual Studio (1)

Anonymous Coward | about a year ago | (#43451829)

Hah, beautiful.

Well done, love your work!

Re:Visual Studio (4, Interesting)

gabereiser (1662967) | about a year ago | (#43451831)

seriously? Now I admit that Visual Studio is feature rich, only on windows, only with microsoft stacks, and doesn't compile things in a normal fashion (see #pragma) this above comment just oozes microsoft troll...

Re:Visual Studio (2, Insightful)

Anonymous Coward | about a year ago | (#43451907)

seriously? Now I admit that Visual Studio is feature rich, only on windows, only with microsoft stacks, and doesn't compile things in a normal fashion (see #pragma) this above comment just oozes microsoft troll...

It's a troll alright, pretending to be over-the-top-Microsoft shill and still getting some Slashdotters riled up, even though this has been going on for a long while and obvious troll is obvious.

Re:Visual Studio (0)

Anonymous Coward | about a year ago | (#43451927)

I saw #pragma. What's the problem?

Re:Visual Studio (1)

ByOhTek (1181381) | about a year ago | (#43452183)

From my understanding, I thought that was exactly the purpose of #pragma - nonstandard stuff.

As for windows-only stacks... That's BS, at least for .NET.

However, yeah, the compiler is stuck to Windows, and their C++ interpretation (not including pragmas, which are for non-standards), is... at best "wonky"

Re:Visual Studio (1)

gabereiser (1662967) | about a year ago | (#43452417)

Sure you can compile mono code with vs. But it's still a windows stack just ported to *nix. I love mono, don't get me wrong. I also love C# even though I'm a more java guy than anything. But for this guy to oogle over visual studio with such fanboi-ism as to neglect the fact that TFA talks about live programming and how awesome it would be for direct feedback of variables and scope and the like to preach the microsoft kool-aid to us /.'s is ridiculous.

Re:Visual Studio (5, Funny)

DJ Jones (997846) | about a year ago | (#43451887)

Have you tried the new VS2012? They took a shotgun to the UI and the file menu is still screaming from the trauma.

Re:Visual Studio (3, Insightful)

ByOhTek (1181381) | about a year ago | (#43452201)

You must have closed your eyes and plugged your ears at the shotgun. I admit it was pretty gruesome. However, after wards they brought out the chainsaw, boiling acid and a couple of fighter jets for good measure... It was horrible.

The sad thing is... They already did that once before to get to the UI that was in 2010... The UI does seem to be getting worse and worse... Just like with their OS and Office products (and it seems, many others to a lesser degree).

Re:Visual Studio (0)

Anonymous Coward | about a year ago | (#43452669)

Have you tried the new VS2012? They took a shotgun to the UI and the file menu is still screaming from the trauma

Hell no, I'm sticking with older versions forever or until MS pulls its head out of its ass. Whichever comes first. At least the compiler can be upgraded separatly.

Re:Visual Studio (0)

Anonymous Coward | about a year ago | (#43451893)

*golf clap*

Re:Visual Studio (-1)

Anonymous Coward | about a year ago | (#43451981)

*golf clap*


Re:Visual Studio (1, Interesting)

Anonymous Coward | about a year ago | (#43451929)

Visual Studio is by far the best debugger in the industry, and one of the reasons I've decided to stay out of Windows development from now on. It attracts crowds of people who rely extensively on code wizards and the debugger for all phases of development including initial coding, and if you're on that team you'll be stuck maintaining their code.

Torvalds has said some characteristically blunt words on the subject of relying on the debugger for development (not Visual Studio per se). I don't think I'd go that far.

Re:Visual Studio (4, Interesting)

neminem (561346) | about a year ago | (#43451951)

Apparently you're a troll? A weird one, because I kind of agree with you (except about Express: yes, it's free, but it's also so limited as to be basically crap.) VS *is* really the greatest IDE I've ever used. It's not perfect, but it is the best I've used. I obviously have not used every IDE ever, and I will also admit that it's much better at debugging .net code than unmanaged c++ code, but still. Microsoft has pushed a lot of crappy, worthless software, but VS 2008 was quality, and 2010 even better (apart from a couple minor UI mistakes, easily fixable with free extensions). Notably, at least far as the summary went, it's done everything this guy is claiming he invented, since basically forever. (Though I personally leave the "recompile on the fly" option turned off; I think it's more trouble than it's worth.)

Re:Visual Studio (-1)

Anonymous Coward | about a year ago | (#43451987)

Visual Studio Ultimate 2012, only $16,623.99 with Free Shipping! []

There are reasons to use open source.
This is one of them.

Re:Visual Studio (1)

ByOhTek (1181381) | about a year ago | (#43452287)

Heh. That is most certainly not the product most people would go for. And honestly, I'd just as soon go with Professional or Express & use Mercurial to make up the difference.

Ultimate has features you only need if you are in a huge corporation/project setting

A more normal user might go for this ($500) []

Which, I admit, is a bit high for most, but if you don't need a lot of the code sharing or installer building tools, (and why should you, there's Mercurial for the former, and the latter isn't so hard to roll your own), you can always go for the Express edition, which is free/

Re:Visual Studio (1)

war4peace (1628283) | about a year ago | (#43452677)

I used VBA in Excel to put together a small application (basically, some reporting automation with a GUI) for a small company and sold it, with the source code, for $750. Took me about 20 hours of work. Didn't cost me a dime (the Office license was paid for by my employer). Point is: if you can code (not even professionally) and have some sales skills (not even professionally) you can make a pretty good buck off those $500 Visual Studio Pro costs.
Furthermore, there's a pretty large amount of companies who have that, how is it called? Some sort of contract with MS where they pay a monthly fee of 200 USD or something and they get CDs and DVDs with all Microsoft products for free. Or something like that. That's how I got a whole box of licensed MS products (including Visual Studio 2005) from my former employer.

Re:Visual Studio (1)

CastrTroy (595695) | about a year ago | (#43452711)

I agree. While $500 is a bit expensive if you want to use it for coding as a hobby, it's almost inconsequential if you're going to be using it for creating a product to sell. Most coders would probably make that amount of money in a day or two.Even as hobby, it's not that expensive. People spent more on the PS3 on release day. Pick most other hobbies, and it's easy to drop $500 on them.

Re:Visual Studio (2)

ByOhTek (1181381) | about a year ago | (#43452007)

OK. I've yet to find a better overall environment (though Eclipse + Java beats VS in some aspects of debugging, neither seems better at every aspect). However, I don't see the point of your post. In reality "care" would have been implementing this YEARS ago. I mean, I've used Python for a long time, and all I can think is "I have this in Python. WTF is novel or research about this? Just %$#@ing do it.

Re:Visual Studio (1)

LordThyGod (1465887) | about a year ago | (#43452015)

All in all, Microsoft Visual Studio keeps getting better!

Yea, but its from Microsoft.

Re:Visual Studio (3, Informative)

progician (2451300) | about a year ago | (#43452031)

You must be very unbiased guy in general. No MS partisanship, whatsoever.

While I agree that the MS Visual Studio is a good IDE over all, there are better alternatives out there. The first real problem with it is that it's single-platform. You can't use it anywhere.
The extensibility is a bitch in VS. It takes too much time and effort to figure out it's API, and it's quirks. Not to mention the support for these retarded languages that VS supports, apart from C++ and C#. That is the only two that worth even to look at.
The debugger is great... except that the whole IDE is based around their own debugger, and you making a debugging interface in VS takes more time than any other IDE out there.
Visual Studio also very rigid on your project structure, and if you don't subscribe to their project file model, you are basically screwed.
Not to mention, that Visual Studio is a resource hog only running on very beefy configuration. Oh, and don't get me started with the useless packages that installs on your system for no apparent reason. Finally, if you want to do refactoring, you have to purchase an external tools, like VAX.

So, while it has some good features for which MS deserves a candy, overall it isn't that good, no need for jumping up and down like a puppy dog.

Re:Visual Studio (1)

RoboJ1M (992925) | about a year ago | (#43452527)

What are the better alternatives?
Honest question, I love VS (inc C# and Linq) but I hate Windows.
It would be great to have something as good as VS for Ubuntu.

Re:Visual Studio (4, Interesting)

TechyImmigrant (175943) | about a year ago | (#43452577)

>What are the better alternatives?

Instrumented code.
Unit testing.
Live testing.
Rapid build - test turnaround.

If you're looking for a better debugger, you're doing it wrong.
You need to instrument your code with the features to make it testable from within the running code base.

Greenspun's Tenth Rule (2, Insightful)

White Flame (1074973) | about a year ago | (#43451817)

This will no doubt become an ad hoc, informally-specified, bug-ridden, slow implementation of half of a REPL.

Microsoft Foundation Classes (2, Interesting)

Latent Heat (558884) | about a year ago | (#43451875)

Yeah, yeah, reinventing LISP.

Forget that, will this be reinventing, dunno, "MFC .NET", where software is effortlessly implemented, tested, and documented using a mix of object classes, C++ templates, custom extensions to C++ that break portability, "wizard" (i.e. obscure template) generated code, a virtual machine, and calls between "managed code" on the virtual machine and native code that break security and prompt stern security scoldings when your code is on a virtual drive or "network share"?

Re:Greenspun's Tenth Rule (0)

Anonymous Coward | about a year ago | (#43451897)

I rather think that read-eval-print is the thing that is informal and half-specified, myself. It was a great technique in the days of QBASIC and the TI-85, but VS breakpoints are POWERFUL. Trying to do the same thing with read-eval-print would quickly turn in to a game of Dwarf Fortress.

Re:Greenspun's Tenth Rule (5, Insightful)

Charles Duffy (2856687) | about a year ago | (#43452011)

I suspect you haven't seen a Common LISP debugging environment. Yes, they allow breakpoints, as well as live code modification. (And if you were lucky enough to have a LISP machine, you could dive into the code behind your libraries, your operating system, etc. -- updating state on the fly, all the way back to tweaking a driver on a running machine... on the fly, in LISP).

What we have these days (say, Clojure's nrepl) isn't as powerful as that, but it's pretty damned powerful even so. Want to tie into your production system and see what a new version of a function would do against currently live production data, without actually changing the production system's behavior? If you're writing purely functional code, you can do that trivially... and the language strongly encourages pure functional code (as opposed to many "modern" languages where trying to write things to be side-effect-free is working against the grain).

If the best example you can think of is QBasic, you have no idea what a REPL can do.

Re:Greenspun's Tenth Rule (1)

TechyImmigrant (175943) | about a year ago | (#43452229)

If you're writing purely functional code, you can do that trivially...

But if you're writing purely functional code, you can't have any output, because that would be a 'side effect'.

Functional programming is an unnatural act.

Re:Greenspun's Tenth Rule (2)

sourcerror (1718066) | about a year ago | (#43452633)

That's why they have monads. But LISP isn't a purely functional language anyway.

Re:Greenspun's Tenth Rule (4, Informative)

TheRaven64 (641858) | about a year ago | (#43452715)

Smalltalk-80 (or even Smalltalk-76) is more akin to what they seem to be describing than most lisp implementations. In Smalltalk-80, you can inspect every object in the system, visually, including the objects that comprise the inspector for whatever you're looking at, and you can modify any value on the stack, at any depth, unwind it and so on.

Re:Greenspun's Tenth Rule (1)

ByOhTek (1181381) | about a year ago | (#43452053)

I'm thinking more like the Python interpereter, but with your code being stored in your source files automatically. You can then open the files and add breakpoints as you like. If a function isn't defined, it'll request you build it on call.

Note: for particularly lazy programmers, this could add more issues, especially with functions that are only called on rare cases.

It'll be a nice feature I'm sure. I just think the suggestion of the TFS, as if it is something revolutionary... is a few decades out of date.

And Stroustroup said... (1)

Anonymous Coward | about a year ago | (#43451849)

"'Everyone knows that debugging is twice as hard as writing a program in the first place,' Brian Kernighan once wrote (adding: 'So if you're as clever as you can be when you write it, how will you ever debug it?')

And Stroustroup said, "sounds like weakness! Here, have some templates!"

Eclipse (2)

roman_mir (125474) | about a year ago | (#43451851)

I've been using this amazing technique for a long time now, IDEs like Eclipse make it fairly easy to do that. TFS doesn't explain what is it that he is doing differently.

Re:Eclipse (2)

rwise2112 (648849) | about a year ago | (#43451943)

Yeah. This sounds just like a profiler, which has been around forever. Is there something new here, or am I totally off base here?

Re:Eclipse (1)

ByOhTek (1181381) | about a year ago | (#43452075)

OK, in Eclipse, how do I code & run at the same time.

I can alter things in the debugger and push them back to the live application, but I can do that in VS too. This is reading more like Python/Lisp, where you can edit as you run, and (as with some of their IDEs) the code gets saved to source files for later use.

Re:Eclipse (1)

H0p313ss (811249) | about a year ago | (#43452219)

OK, in Eclipse, how do I code & run at the same time.

Type and save it?

Re:Eclipse (1)

roman_mir (125474) | about a year ago | (#43452317)

What do you mean, everybody knows that's not how you program. You have to create a GUI interface using Visual Basic that's how you track an IP address and incidentally that's how all modern applications are written.

Re:Eclipse (1)

ByOhTek (1181381) | about a year ago | (#43452675)

Umm... You can do that in Visual Studio also.

My suspicion is it's something slightly more integrated, like you can see with a CLI interpereter in Python or Lisp. Particularly the latter, where you just code, and when you are done, you have have it save the most recent version of ever function into a file.

my old pascal compiler from 1996 had this (1)

Anonymous Coward | about a year ago | (#43451859)

Old pascal compilers had a crude version of this baked right in. You could watch lines of code blink and change color as they ran.

OO makes this kind of idea almost infinitely more complex, however. It was a nice feature for procedural programming, saved me a lot of time.

Re:my old pascal compiler from 1996 had this (1)

progician (2451300) | about a year ago | (#43452057)

I wonder how would work that code colouring in a multi-thread environment too.

Good, but... (3, Insightful)

ControlFreal (661231) | about a year ago | (#43451871)

... this should be in addition to good coding/style standards, proper design, proper source revision control, proper code reviews, and continuous testing/integration. Without any of the former, using this tool does not provide that much information: You first want to know whether your code does what you think it should do, whether it is thread safe, whether it is leaking memory, etc., etc., etc.

If it uses .NET then I'll pass (0)

RogueWarrior65 (678876) | about a year ago | (#43451877)

Nothing pisses me off more than programs written dependent on .NET except perhaps every government website that requires you to use IE instead of pretty much every other browser. On further thought, the fact that government websites require you to use effing Lotus to submit forms instead of PDF also sucks.

Prograph (1)

MrLizard (95131) | about a year ago | (#43451895)

Prograph did this in the early 1990s. Way to innovate, Microsoft!

Wow (5, Funny)

LizardKing (5245) | about a year ago | (#43451913)

They've reinvented Smalltalk. Let's party like it's 1980.

Re:Wow (0)

Anonymous Coward | about a year ago | (#43451933)

Why is the computer industry hell bent on constantly reinventing the wheel?

Re:Wow (3, Informative)

Spudley (171066) | about a year ago | (#43452329)

Why is the computer industry hell bent on constantly reinventing the wheel?

Because the computer industry (and certainly the louder and more vocal parts of it) has a heavy bias of young excitable developers who are talented enough to create these things from scratch, and not experienced enough to think that others might have done similar things in the past.

Re:Wow (2)

FalcDot (1224920) | about a year ago | (#43452033)

Sounds more like they reinvented the Python console...

Or, you know, bash.

Any shell, reallly.

Re:Wow (1)

JackPepper (1603563) | about a year ago | (#43452323)

I was going to type FORTH. Or colorFORTH because it has that wonderful colored interface.

Live Syntax checking. (1)

cant_get_a_good_nick (172131) | about a year ago | (#43451915)

Though not quite the same I like an IDE (like Eclipse) for Live Syntax Checking. What makes it better than a text editor is that It can check syntax on the fly, and remove some of the edit/compile/broken-compile/swear/re-edit/recompile loop.

No, it's not as cool as potential Live Running, but it helps a lot to keep your mind on code flow rather than language syntax.

Re:Live Syntax checking. (5, Interesting)

CastrTroy (595695) | about a year ago | (#43452355)

Welcome to VB.Net. It's been there for ages. Mind you you have to pause the debugger to edit the code, but that's probably a good idea anyway. VB.Net also has some of the best pre-compile (it has a background compiler) syntax checking of any language I've ever seen. The only time you actually have to compile the program is when you want to run it, you never have to compile to make changes show up for auto-complete. And once you're running in the debugger you can edit the code anytime the code is stopped. There's a few limitations. I'm not sure if you can add a whole class while it's running, but you can definitely fix all those little off-by-one errors and continue running the program.

Little more than eye candy (0)

Anonymous Coward | about a year ago | (#43451919)

An approach to address debugging of defects that are easily addressable by other means, albeit with less in the way of eye candy. Wake me up when this approach effectively addresses timing issues.

Spreadsheet (1)

vgerclover (1186893) | about a year ago | (#43451921)

So, it's a spreadsheet, basically? It isn't a bad idea at all.

Re:Spreadsheet (2)

SJHillman (1966756) | about a year ago | (#43451995)

Reminds me of batch files, personally. As long as the script runs in a loop of some sort, you can have Notepad open to edit the script while it's still running. I think shell scripts are the same way, although I haven't done much with shell scripts in years.

borland Turbo Pascal 2.0 ! (0)

Anonymous Coward | about a year ago | (#43451961)

Still a dream today .....

1990s style version of this (1)

concealment (2447304) | about a year ago | (#43451975)

VIM editing Perl code in one window, another for an execution trace, and a third to run the program. Ugly and basic but it gets the job done.

input? (1)

schlachter (862210) | about a year ago | (#43452017)

how would it integrate data/network/user input?

how does it know when to start live testing, as pieces of interdependent code are being written?

they have a word for this (4, Informative)

waddgodd (34934) | about a year ago | (#43452045)

"a programming environment in which editing of code and the execution of code occur simultaneously" is commonly called an interpreter, welcome to 1975

Re:they have a word for this (1)

gmcclel (43020) | about a year ago | (#43452143)

As I work daily in BBx (still), a Business Basic interpreter, I too wonder what the big deal is.

Finally, A Silver Bullet (1)

dcollins (135727) | about a year ago | (#43452047)

For I have been looking for one, lo, these past 27 years.

Good Testing helps debugging (1)

realsilly (186931) | about a year ago | (#43452063)

I do not code or develop code any more, but I'm great for finding bugs in code which irks my developers to no end. But conversely, they really like when I test their code, especially when they want to have bugs found. I know how to recall what I did when creating my bug report. I almost never report something as a bug until I can repeat the issue and then I usually re-create the issue two more times to ensure I recall just how I got to that bugged state. I document step by step instructions and follow it up with screen shots. If weird occurrences are also observed, I note those as well. I also try to note down what version of software I am running, because that also helps to narrow down an issue.

While all of the info I provide doesn't always help in debugging all code, it certainly simplifies the process by the developer to figure out what's wrong and where it's taking place. In essence, my good testing and regurgitation of information help cut down debugging efforts by a large percent.

God knows it's better than "I clicked a button and the program blew up".

Re:Good Testing helps debugging (0)

Anonymous Coward | about a year ago | (#43452353)

We call this delivering 'Bugs on a sliver platter'.

Getting a bug like this, especially an obscure one is to be treasured.

Will this work for large projects? (0)

Anonymous Coward | about a year ago | (#43452067)

How is the implementation going to dynamically show me the output of my 1million LOC 3D game? This sort of stuff is useful when scripting for games in Lua, Python or JS but a fibonacci example is not really proving a thing.

Good to do the debug thinking while writing code (1)

Anonymous Coward | about a year ago | (#43452099)

While I'm writing code is the easiest time to think about how it might misbehave.
      I put in debugging in the form of asserts.

Debugging often consists of just making a strongly typed, picky compiler happy and then clearing the asserts.

Sometimes it takes a week or so before there is enough surrounding code to actually debug anything.
      Without the asserts, I have get back to the frame of mind I had early in the week.
          With the asserts, I don't.
              As a bonus, the asserts are still around for regression testing for later code mods.

The model they propose (simultaneous coding and debugging) doesn't work until you have a 'quorum' of code to do incremental improvements on.
    If you want to stop an spend a week restructuring, same story.

But for incremental improvements, sounds great.
      Again, you are in the best possible frame of mind to think about how code can misbehave while you are writing it.

Bret Victor (0)

Anonymous Coward | about a year ago | (#43452103)

Already done, much better, by Bret Victor. See at time 3:36.

nice but limited, what would be cooler... (1)

Anonymous Coward | about a year ago | (#43452107)

Very nice, but its usefulness is really limited to functions where the parameters are simple objects or native types. Complex objects would require too much initialization to make the unit test worthy.

Here's what would be more useful for anyone out there working on debuggers to consider:

Typical step debugging has a really pathetic interface with the following interface:

- break
- step
- step over
- step out
- resume

I've been using that now for 20 years. What would be nice would be to add the following:

A resume with a reduced speed option. In other words, start stepping with a slight delay, with visual feedback, so the developer can see the code as it is stepped through. Allow the developer to control the speed of the stepping (mouse-wheel or some dial) as well as dynamically prompt the debugger to step out (climb back up the stack) when the debugger gets too far down into weeds.

Replay. Vmware is making this happen with their tools, but it would be nice if this were more ubiquitous. The developer should be able to start "recording", and every memory/register change from then on is tracked, such that the developer can rewind instead of only being able to move forward.

And for anyone working on language development, my 20 years experience has shown that the null-pointer exception is the most common problem that people run into. It would be nice if coding languages enforced natively the concept of a object reference/pointer parameter not being null at compile time. The C/C++ reference (&) comes close, but you can still circumvent it by simply de-referencing the pointer. You can get around this with templates/generics/etc but it is a hassle.

Please implement.

Re:nice but limited, what would be cooler... (1)

CrackHappy (625183) | about a year ago | (#43452593)

OMG - rewind/replay. That would make my day. Then I could record the output to that and make a scratch mix of code going backwards and forwards.

No silver bullet (1)

dkleinsc (563838) | about a year ago | (#43452133)

Fred Brooks noted this one years ago, and it's still true: The reason programming is complicated is frequently because the real-world problem you're trying to model in software is complicated. The reason debugging is even more complicated is that not only do you need to understand what you're trying to model, you also need to understand exactly how the existing software modeled the real-world problem.

Re:No silver bullet (1)

H0p313ss (811249) | about a year ago | (#43452245)

... you also need to understand exactly how the existing software modeled the real-world problem.

Well... usually how the existing software failed to model the real-world problem. (That and understanding the difference between the code and the comments, never trust the comments.)

Re:No silver bullet (1)

gweihir (88907) | about a year ago | (#43452307)

Very true. All this tool does is to suggest to people of even lower skill level that they can be programmers.Writing good code is hard and one way to learn avoiding making mistakes is if mistakes have consequences. With this tool, even more people will start to use an experimental approach to coding, where thinking about what they want to do beforehand is not part of the process anymore. That can only lead to disaster.

This should be fun (0)

Anonymous Coward | about a year ago | (#43452141)



Modern projects make it more complex (1)

unfortunateson (527551) | about a year ago | (#43452163)

At first glance, I just want to say, "Hey, Basic Interpreter from the 70's, you're finally getting some respect!"
But there are some deep issues that are, even with these techniques, going to be very hard to debug:
1) Large I/O situations -- real time data collection and display. Weather reporting, gaming, etc. How is debugging on the GPU going to be helped by this, would be one of my first questions.
2) Networked, distributed code -- with clients on multiple platforms (CPU, browser, Java version, etc.), and clustered virtual servers, where do you debug? Just locating which side is in error (wrong message being sent, wrong message being heard, wrong result being stored/displayed) is a challenge, and real-time transactions (for instance, race conditions on a resource that could be anything from an interrupt bit to a piano in inventory) further complicate this.

If they ever come up with a debugger that will let me hook into both the client and the server at the same time, that would be brilliant.

Like a Lisp REPL then? (1)

CptPicard (680154) | about a year ago | (#43452167)

Cool, I knew this would make a comeback from the 60s or something.

VB6 (1)

MNNorske (2651341) | about a year ago | (#43452205)

Pretty sure these were features of VB6. I remember hacking out code, using the immediate window to trace values, setting break points, stepping through the code, modifying in the middle of execution, and then resuming execution. The language itself may have had a lot of issues and performance issues, but the IDE and development environment had some very nice features.

Re:VB6 (0)

Anonymous Coward | about a year ago | (#43452237)

Yes, I was thinking the same thing. I think an early version of .Net had it as an option as well.

Re:VB6 (1)

DarkOx (621550) | about a year ago | (#43452429)

Your memory is a bit off. You could modify variables, call subs, functions, that might change values from immediate while stepping or stopped on a break point. You could not change code; though.

No, you're completely wrong (0)

Anonymous Coward | about a year ago | (#43452515)

VB6 had very functional edit-and-continue - it took MS a lot of versions of .NET to get back up to the same general functionality.

Why not check if you're right before randomly gainsaying someone?

Re:VB6 (0)

Anonymous Coward | about a year ago | (#43452581)

And that functionality was available as early as in QuickBasic which came out in 1985.
TFA itself is almost completely content-free; the only kernel of information is the video ( which didn't leave a positive impression with me.

Does not solve the problem, may make it worse (1)

gweihir (88907) | about a year ago | (#43452259)

The problem is that so many programmers need debuggers in the first place. That is a sign of low competency levels. I found that using methods from design by contract basically eliminate the need for debuggers as they lead to much, much better code and give you errors that are directly meaningful. Of course, this requires thinking about what you want to program before doing so, as you are actually implementing a check of its implementation before you implement the actual code. And it can be done in any language once you have understood the concept. The only time I use a debugger is when diagnosing obscure problems, but that requires a lot of thinking about the state I see anyways, and DDD is perfectly fine for it.

This tool does nothing than making programming seemingly accessible to programmers of even lower skill. Writing code that does what you want is easy, but writing it as simply as possible (maintainability), with clear and clean interfaces, robust, aware of special cases, fast, etc. is not. Hence the only thing this tool will is to decrease code quality overall.

Re:Does not solve the problem, may make it worse (0)

Anonymous Coward | about a year ago | (#43452565)

Debugging is not just about finding errors, it can be an interactive tool to help you understand a problem. If you don't need debugging, perhaps you're working on problems below your pay grade? Personally, I don't use debugging much for my "work" code - but I debug all the time when doing more complicated problems on personal projects or TopCoder (particularly in marathons).

Re:Does not solve the problem, may make it worse (0)

Anonymous Coward | about a year ago | (#43452607)

way to sound like an elite asshole.

ps -fuck you.

give me the ability to reverse system time (2)

Chirs (87576) | about a year ago | (#43452311)

I just want the ability to detect a fault and then run my entire system backwards to figure out where the problem came in. Wind River Simics can do this, but it's expensive and time-consuming to get a model of your hardware unless it happens to be something they already support. It's also slow to run (as you'd expect).

slowpoke (1)

equex (747231) | about a year ago | (#43452313)

Hah, this techinque is called PHP+println() and is not new by any means. I programmed PHP live with 50-100 clients ready to kill me if i clicked Ctrl-S a bit too early. Noobs.

Welcome to smalltalk, circa 1980's... (2)

zaroastra (676615) | about a year ago | (#43452315)

This looks soooo much like the way smalltalk engines where implemented in the 80's it's boring.
One can always count on MS to bring the latest in software innovation

Re:Welcome to smalltalk, circa 1980's... (2)

turkeyfeathers (843622) | about a year ago | (#43452365)

They've brought smalltalk into the 21st century... by adding Clippy!

Heisenbugs (0)

Anonymous Coward | about a year ago | (#43452339)

I need to read up on this but my first reaction is that you wouldn't run production code in this new debug environment, so how do you know code that works in this new debug environment will work after being compiled (to .NET or native code - remember MS is pushing C++ native code again, and this new debug environment sure wouldn't do much with C++!) and put into production?

I am sure it is not totally useless. (1)

140Mandak262Jamuna (970587) | about a year ago | (#43452357)

Just as I am crunching down on my last bunch of some 40 odd bugs to make it for the release such news stories come as a welcome day dream. I am sure there are products where you could edit source code while running and the running code dynamically responds to code changes.

But the most difficult bugs are not the crashes or randomization introduced by the thread completion order. What is difficult is the bug that happens after several hours of computation. Longer it takes for the bug to manifest itself, harder it is to debug. Of course it is my luck I end up with coding for such products. Not that I am complaining. It needs a special skill have such products humming along, and it takes a long time on the job to develop it. The pay, benefits and job security are good. So I am not threatened ...


What Bob? Boss wants to see me? Why is she having these gentlemen from security and the HR blond boy with her?

Oh good. You have discovered the interpreter. (0)

Anonymous Coward | about a year ago | (#43452369)

Good work. Great to see R&D money is not going to waste.
Might want to talk to the VB6 guys if there are any left.

Sigh (0)

Anonymous Coward | about a year ago | (#43452415)

My first reaction was:
    I've been doing this in python for at least 5 years, and it's probably been around longer.

Then I thought for a second about a CS prof I had who had a MIPS course where they did this in emacs back about 2000...

Then I thought about EMACS.... oh yeah... LISP, SCHEME, rep loops...

Then I thought on LISP -- oh yeah, MIT built fucking hardware and o/s that did this shit in the 70's.

I may find the idea of LISP fairly distasteful... but this idea is nothing new under the sun. It's in fact older than I am, and older than some of my friends that have kids...

Limitations. (1)

QilessQi (2044624) | about a year ago | (#43452419)

McDirmid notes that there are limitations to his prototype. For example, the approach used by LPX won't work for "interactive programs whose inputs consist of time-ordered events and whose outputs can vary over time

You mean, such as programs which offer a user interface, and which both write to and read from some kind of persistence layer or document storage on the backend?

Well, at least there can't be too many of those....

A better method... Incremental (0)

Anonymous Coward | about a year ago | (#43452425)

Why would anyone try to write a program all at once, then debug? I've always written software in pieces, and each piece gets compiled and tested before moving further along. That irons out 99% of the bugs, and using an actual debugger is unnecessary (printed messages from testing can reveal any bug). The remaining 1% of bugs jump out along the way (or after finishing), and looking at the code with a problem in mind is all it takes to find and fix them.

No debugger or elaborate runtime compiler necessary.

Apple quote in article (4, Informative)

CODiNE (27417) | about a year ago | (#43452463)

What's funny about this article is it's focused on a very limited text based debugging system where the author is already apologizing for bugs while demo'ing it.

It mentions a quote from an Apple guy on the same topic. Wait a minute... Apple is working on this too? So you click the link and find a much better article with a similar system that's way more advanced and live connects the graphics with the code.

Just kind of sad, I RTFA and think "Huh, that's interesting, someday" then check out the link inside the article and find a much more informative and interesting story that I'm still reading. Read THAT article instead. Looking forward to seeing this creep into Xcode updates.

Light Table? (0)

Anonymous Coward | about a year ago | (#43452485)

This sounds like Light Table for Clojure:

It's supposed to help you see the flow of data through your program, as you're coding, by executing things and showing you the results in the IDE.

Write-compile-test-fix cycle (0)

Anonymous Coward | about a year ago | (#43452489)

What's wrong with very short write-compile-test-fix work patterns? Instead of writing code for weeks on end, do very short write-save-compile cycles, to make sure your code at least compiles most of the time, then, when you think your subfeature is testable, take a break from spilling code and test that what you wrote does what you think it does, then fix it until it actually does what you meant it to do. While at it, you'll also notice that you can take some the code you just wrote and move it into its own reusable module.

Oh, right... you need to understand what the hell you are doing :)

WinDbg Help (1)

deKernel (65640) | about a year ago | (#43452553)

My first suggestion would be is for them to implement WinDbg in an actual usable way. The cryptic commands and setting up the directories for the source and .pdb files.....sheesh.

Inventing on principle (2)

jeroenrijckaert (2897497) | about a year ago | (#43452621)

The idea is good, but not new : [] (Bret Victor's Inventing On Principle)

Sounds like ... Light Table? (0)

Anonymous Coward | about a year ago | (#43452651)

I'm not sure who remembers the still somewhat LISP-centric Light Table [] IDE by Chris Granger, who was looking for kickstarter funding last year. One of the selling points of his IDE was that it's all real-time execution/evaulation, so you see your output in real time.

I'm not entirely familiar with it, but they've got Python and Javascript integration as well, and as Chris stated, any language with a dynamic runtime is a viable option.

Funny enough, he was in charge of some parts of the Visual Studio IDE, like the C# and Visual Basic 'experience', as well as managing?contributing? other bits. I wonder if this is just 3-years-later trickle down of his ideas?

LightTable (1)

gnosis9 (1432997) | about a year ago | (#43452695)

From Light Table is a new interactive IDE that lets you modify running programs and embed anything from websites to games. It provides the real time feedback we need to not only answer questions about our code, but to understand how our programs really work.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account