"I made some changes in my several thousand lines of VB code and now finding it a bitch to isolate a bug." - Christopher
I've been pretty lucky with the Hive simulator code, but I did some floor planning up-front. Structures that encapsulate functionality and data together are C++ objects. The main memory is an obvious object, with private and public functions that read and write, copy sections, parse hal and mif files, etc. There are 8 threads so I decided to make them objects as well, which drastically reduced redundant coding. The core creates the memory and threads and is itself an object, so I could instantiate a multi-processor sim pretty easily. I'm comfortable with the OO approach because it is very similar to the component approach hardware description languages employ.
But, yes, I sit around writing out small critical snippets until I feel they're pretty well nailed down before actually coding. That makes me a slow coder, but I think I spend a lot less time tracking down bugs. The sim code is getting a bit ungainly at this point, but I don't think I'll be adding much more to it.
VB is one of the worst languages I've used, but you're kind of forced to if you want to do anything fancy in Excel. It's clunky, overly verbose, slow as a snail, and not very readable. I pretty much loathe it. C and to some extent C++ make a lot of sense to me, but some of this may be my familiarity with them. C very clearly targets real processor hardware, and that's the best starting point for a language IMO. C++ would benefit from a whole lot of stuff being removed, particularly most of the class and inheritance crap. And pointers in both drive me crazy, I hate pointers and I hate the lame syntax they picked. Pointer arithmetic is just asking for it IMO, and I think that's what makes these languages so unsafe. If you want to indirectly reference a bunch of items instantiate them as an array.