To any programmers here about....eh...programming...

[ihamoitc2005]

Explanation

Human brains aren't logical enough to process unambiguous logic.

I would like to understand this statement better for my own learning. Thank you.

 

[Bobbler]

- A proper IDE.

No joke, Im in a situation where even access to a simple debugger would save me hours right now. VI and a command line compiler is the closest thing to a "development environment" I have.

 

[Eleazar]

I would just like to throw in a question. What tools are good examples of tools that cater well to your needs? What are some good examples of things that make your job easier? Btw, great post Greg that was a good idea.

 

[tuna]

No joke, Im in a situation where even access to a simple debugger would save me hours right now. VI and a command line compiler is the closest thing to a "development environment" I have.

You don't even have GDB? That is tough.....

 

[ShootMyMonkey]

You don't even have GDB? That is tough.....

Eh... I'd rather have printf debugging over gdb myself.

As much as I can complain about the standard PSP tools, they're still better than the empty void that was PS2. So what if I can't do more than 15 incremental builds in a row? So what if the debugger doesn't allow you to choose which variables you want to put a watch on? So what if I have to copy this into a dummy void ptr to keep the debugger from BSOD'ing? At least I have something a few notches above printf debugging.

In my case, I think the worst part of bad tools is not just the lack of productivity that's directly related to them, but the fact that it evokes further distrust in them and a tendency for people to do things the hard and tedious way.

 

[BRiT]

Eh... I'd rather have printf debugging over gdb myself.

But modifying the code by inserting printf statements will modify the stack and will mask stack-related and timing-related issues. It's not fun tracking those down w/o a genuine debugger like gdb.

 

[pc999]

Human brains aren't logical enough to process unambiguous logic.

If we learn (only) symbolic logic since babys why we would be capable to do that, the problem is that we only lack in logical memory (ie being able to track a logic reasoning by a long time) and some speed to do that in a convineint way, if we had that we would be completely capable to be as good a CPUs (however we would ever maded CPUs and we wouldnt know that), while we still (and will ever be) capable of much more than CPUs like creation and creativity (and we still have the CPU capabilitys because we do have CPUs), it is a win-win situation IMO.

 

[ERP]

Eh... I'd rather have printf debugging over gdb myself.

As much as I can complain about the standard PSP tools, they're still better than the empty void that was PS2. So what if I can't do more than 15 incremental builds in a row? So what if the debugger doesn't allow you to choose which variables you want to put a watch on? So what if I have to copy this into a dummy void ptr to keep the debugger from BSOD'ing? At least I have something a few notches above printf debugging.

In my case, I think the worst part of bad tools is not just the lack of productivity that's directly related to them, but the fact that it evokes further distrust in them and a tendency for people to do things the hard and tedious way.

Yep when build processes start having rules that equate to basically magic you have a problem. You start getting the word of mouth processes that make zero sense, when X fails do Q then a clean rebuild "always works for me". I've seen programmers loose days trying to get something working again when a tool suddenly stops behaving as expected.

My favorite debugger issue of all time was the N64 one on the SGI's where you could only ever watch a none 32 bit variable once, adding a second watch would hang it and take the devkit with it.

 

[corysama]

My favorite debugger issue of all time was the N64 one on the SGI's where you could only ever watch a none 32 bit variable once, adding a second watch would hang it and take the devkit with it.

My favorite is also on the N64 when the watch window developed an "off-by-one" error in matching types to their structures. Every variable I viewed was displayed as if the pointer was reinterpret-cast as the next type declared in the header. In order to see a variable correctly I had to find where the variable's type was declared so that I could create a watch pointer cast to the previous type to cancel the error. :|

A warning to any devs in training: The cutting edge frequently hurts.

 

[Fafalada]

Yep when build processes start having rules that equate to basically magic you have a problem. You start getting the word of mouth processes that make zero sense, when X fails do Q then a clean rebuild "always works for me". I've seen programmers loose days trying to get something working again when a tool suddenly stops behaving as expected.

Frankly MS tools have trained me to never, ever trust the build process logic (such as dependancy checks). Sure it will tend to work often enough - but for over 5 years MSDev compilers would randomly fail to generate correct code completely out of the blue, and I'd find myself using rebuild all everytime I made changes that felt suspicious, just to be on the safe side.
For all I know .NET fixed all these issues, but after my experience with the previous 4 iterations of the studio I've gotten way to paranoid to trust it.

And don't even get me started on debugers, I could pobably write a book on all the weird little gotchas in SNSystems debuggers...
My favourite with the PS2 tools is still the one where there's an upper limit on the size of files that were compiled with -O0, so when you're debugging you have to always jump around the project changing optimization flags just so you can disable optimizations on the files you actually need to see in debugger...

 

[darkblu]

Frankly MS tools have trained me to never, ever trust the build process logic (such as dependancy checks). Sure it will tend to work often enough - but for over 5 years MSDev compilers would randomly fail to generate correct code completely out of the blue, and I'd find myself using rebuild all everytime I made changes that felt suspicious, just to be on the safe side.

ditto.
and just when you decide that incredibuild is your best friend you discover it's been cheating on you with devstudio's crippled dependencies. so back to good old manual rebuild-all. the worst thing is that with time you develop such a strong paranoia that you cease to distinguish when the tools failed you and when it was your own error.

 

[_xxx_]

I would like to understand this statement better for my own learning. Thank you.

You can't, because human brains aren't logical enough to process unambiguous logic.

 

[_xxx_]

I would just like to throw in a question. What tools are good examples of tools that cater well to your needs? What are some good examples of things that make your job easier? Btw, great post Greg that was a good idea.

Tools in general? IDE-wise, nothing beats MS Visual Studio. I also use EasyCode as an editor sometimes, which makes navigation through code a breeze. And than of course standards like BeyondCompare and UltraEdit.

 

[Nite_Hawk]

Tools in general? IDE-wise, nothing beats MS Visual Studio. I also use EasyCode as an editor sometimes, which makes navigation through code a breeze. And than of course standards like BeyondCompare and UltraEdit.

I'm not as fimiliar with Visual Studio as I am with Eclipse, but based on my experience so far I find Eclipse far superior. Visual Studio has this nasty habit of assuming too much. Eclipse seems to be a lot better about staying out of my way, but still provides a ton of useful functionality. The only downside to Eclipse is that it really is only superior for writing java code. The CDT is still too buggy and unpolished at this point.

Nite_Hawk

 

[ERP]

ditto.
and just when you decide that incredibuild is your best friend you discover it's been cheating on you with devstudio's crippled dependencies. so back to good old manual rebuild-all. the worst thing is that with time you develop such a strong paranoia that you cease to distinguish when the tools failed you and when it was your own error.

incredibuild doesn't co-exist well with MS dependencies at all, if you ever cghange a header file and you've run both build processes, best of luck avoiding a full rebuild.
I have good luck if I don't use it or if I only use it.

 

[ERP]

I'm not as fimiliar with Visual Studio as I am with Eclipse, but based on my experience so far I find Eclipse far superior. Visual Studio has this nasty habit of assuming too much. Eclipse seems to be a lot better about staying out of my way, but still provides a ton of useful functionality. The only downside to Eclipse is that it really is only superior for writing java code. The CDT is still too buggy and unpolished at this point.

Nite_Hawk

I've used eclipse and I prefer Visual Studio, and I have my problems with VS.
VS 2005 is a step in the right direction, but the C++ tools are still second class to the .net languages. It does now correctly color code #if block though which is worth the upgrade

 

[ShootMyMonkey]

My favorite debugger issue of all time was the N64 one on the SGI's where you could only ever watch a none 32 bit variable once, adding a second watch would hang it and take the devkit with it.

My favorite is one that's a bit more esoteric and rare to occur, but repeatable. It happened to me on the PSP while using earlier firmware. Apparently, a good way to crash your PC as well as hard-crashing the devkit was to have a indexed trilist packet where the number of tris was exactly equal to the square of the size in bytes of the vertex format when not padded for alignment (the vertex format had to be more than 24 bytes -- and not a power-of-two size, not that you can render anything at all anyway when the vertex format was power-of-two size).

 

[Nite_Hawk]

I've used eclipse and I prefer Visual Studio, and I have my problems with VS.
VS 2005 is a step in the right direction, but the C++ tools are still second class to the .net languages. It does now correctly color code #if block though which is worth the upgrade

Perhaps it has more to do with which one you started with. I went from straight text editors to eclipse to VS, and I find myself fighting with it a lot more than eclipse. Perhaps it's mostly because I know eclipse better. Still, it seems really clunky in comparison. Things that I don't remember being hard to pick up in eclipse seem downright frustrating in VS.

Nite_Hawk

 

[MrWibble]

I'm not as fimiliar with Visual Studio as I am with Eclipse, but based on my experience so far I find Eclipse far superior. Visual Studio has this nasty habit of assuming too much. Eclipse seems to be a lot better about staying out of my way, but still provides a ton of useful functionality. The only downside to Eclipse is that it really is only superior for writing java code. The CDT is still too buggy and unpolished at this point.

Nite_Hawk

I tried Eclipse a while back. It shattered my nerves, turning me into a shadow of my former self. I still sometimes wake up in the middle of the night in a cold sweat, gasping for breath. I have to load up Visual Studio and hit "new project" just to calm myself enough to get back to sleep...

Even just writing this post has given me flashbacks. I need alcohol. Lots of alcohol.

 

[ERP]

Perhaps it has more to do with which one you started with. I went from straight text editors to eclipse to VS, and I find myself fighting with it a lot more than eclipse. Perhaps it's mostly because I know eclipse better. Still, it seems really clunky in comparison. Things that I don't remember being hard to pick up in eclipse seem downright frustrating in VS.

Nite_Hawk

Possibly.
I hated VS6 for a long time because it's brief emulation was piss poor, not long before I moved to VS7 I stopped using a seperate editor and spent the time to get used to the VS6 standard keys, other than that I don't really remember any pain.

My biggest gripes with it are all "minor", I can't display the same file in two Horizontally adjacent windows for example.

The editor is still the most important part of an IDE for me, the main reason I swapped to the VS6/7 one was because I wanted consistent keys between code editing and editing in the debugger