jschell wrote:I have been doing it for 40 years and have used Fortran, Basic(various flavors), Pascal, assembly (different flavors), C, C++, C#, Java, Perl, various SQL
dialects and various scripting languages.
Awesome. Same here, pretty much. You just have 8 years on me
jschell wrote:You failed to mention maintenance costs and total life cycle costs in anything you said.
You're right... I didn't say anything about that.
jschell wrote:Which might be because you don't understand maintenance costs an life cycle costs.
The fact that you understand the code means nothing it terms
of whether someone else can understand it. And in the vast majority of professional programming software that actually reaches production will require that someone else besides the original programmer must understand it at some time.
While I didn't mention anything about total cost for maintenance, it doesn't mean I don't understand or value the need for maintainable code from a cost perspective, nor does it mean that I don't value having code that is readable by others. On the contrary, maintainability, TCO and readability are all extremely high on my list of what I value. I didn't mention it in my OP simply because it is... in my opinion... secondary to design and implementation that considers performance (accuracy and stability assumed) as the higher priority. If I am faced with the choice between code that executes twice as fast and code that is twice as readable, I choose performance every time... but then comment appropriately.
For example, I had a project about 10 years ago in C++ that required some software-based imaging processing. Performance was really critical, and the math could have been done step by step, calling various other functions to make the code really, really readable... but putting a particular transformation on ONE LINE helped with compiler optimization to the point where it ran literally 10x faster. So, I wrote it BOTH ways... the "easy to read" way that perfectly expressed the logic of the algorithm, and the ugly but fast-executing way, and left the "easy to read" way as a comment block in order to aid future coders in seeing what was actually going on.
In contrast, there's a fairly popular game out right now that is written (AFAIK) in a highly tiered OO approach, and it's charming 8-bit graphics and blocky environments that are comparable to the technology of the classic DOOM/DOOM II era in the 90's, is so inconsiderate of performance issues that it can bring a Core i7 with dual top-end graphics cards to its knees... that one's a real head-scratcher.
jschell wrote:Your large method idea was one that even structured programmers rejected long ago and that rejection is further demonstrated by the wide and rapid acceptance of Object Oriented programming.
As with all things this is not an absolute mandate in that every thing must be broken into smaller pieces but the vast majority should. And at least in my experience code that fails to do this generally is often obviously not based on an OO design.
I wasn't trying to say that large methods were specifically desirable, only that they shouldn't be shunned as "don't ever ever do this" kind of practices. IMO, a given construct should be used when it's appropriate... always. If a piece of functionality would benefit from a monolithic approach, it should be done that way. If a piece of functionality benefits from an highly tiered OO approach, then it should be done that way. I'm advocating a more liberal approach to design and implementation, not a specifically monolithic approach. The right approach for the right situation. Period.
jschell wrote:Because performance is most significantly impacted by requirements and design. Not implementation.
I don't agree at all. I think any design (good or bad) can be implemented with either fast or slow executing code, and my original point was that it seems the practices being widely adopted in the past 5 to 10 years are definitely not in favor of speed of execution, and I don't understand that.
jschell wrote:Huh? Because it costs money to produce software. It costs money to fix bugs in production. Because it costs money if one losses market share due to long lead times.
Now here, you make a good point that I agree with. I just don't know that a more liberal approach (as I'm advocating) is necessarily the anticedent of time efficiency... though it can be, of course. I just don't think it needs to be that way.
modified 10-Dec-12 8:27am.