61–70 of 214 posts
Earlier quoted context omitted.
If you can't debug with just print statements, you're doing it wrong :)
"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.
[1] https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
Earlier quoted context omitted.
If you can't debug with just print statements, you're doing it wrong :)
"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.
I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.
Earlier quoted context omitted.
> This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. The problem is that this is a whole lot of cargo cult. It does have the efficient parts, but it also has a lot of accumulated cruft, archaic limitations, arbitrariness…
> The problem is that this is a whole lot of cargo cult. Please do explain. Where do I use symbolic representations of technology to attempt doomed magic rituals? As far as the rest of it, everything accumulates cruft. That's why people write new things. And yes, there have been bad decisions. (Just, IMHO, meaningfully fewer than other OSes.) But perhaps I'm blinded by my cargo-cultish ways, can you point to an archa…
I believe that's the official tagline for GNU Autoconf?
Earlier quoted context omitted.
http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em... "It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of…
xiki
Earlier quoted context omitted.
Back when I was working on embedded, I typically wouldn't even bother looking at the debugger. They never helped. The general workflow, when presented with a new system, was something like: (a) Board would arrive. Admire it for a bit. (b) Look suspiciously at the supplied CD. Gingerly insert it into computer. Oh, look, a Windows install.exe. Insert it into the Windows computer next to mine (with its screen and keyboa…
There there... This is why I have a stash of whiskey at my desk ;) (though honestly I haven't touched it in a while. Impairs debugging, really)
Earlier quoted context omitted.
"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.
There's no shame in it but that doesn't mean that it's the best or most efficient way of doing things. I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.
Same problem happens with other methods too: If you develop solely with unit and integration tests, it might actually be quite difficult to get a step-through debugger set up to debug your application. I worked at a company where I was the only one who used a step-through debugger, and some uses of compile-time metaprogramming would frequently break the debugger.
And if you use multiple techniques as appropriate(unit tests, printf or equivalent, step-through debugging), it's generally easy to use any of them as appropriate.
It lacks the I in IDE. Those different tools are not integrated. In a java IDE the debugger steps through your source in the same editor view that you just used for editing. You can hover over each identifier while you code or debug to get the docs in a floating panel. Editing incrementally computes compilation errors while you type. Content assist has complete knowledge of the types at your caret position and thus c…
If you can't debug with just print statements, you're doing it wrong :)
Earlier quoted context omitted.
"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.
There's no shame in it but that doesn't mean that it's the best or most efficient way of doing things. I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.