Robb Ryniak wrote:I've been programming now for over 30 years, and have used a huge variety of languages - everything from GW-BASIC to Assembler to C++ to VB to C#, and everything in between.
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.
Robb Ryniak wrote:and the singular most important lesson I've learned throughout all of this is as follows:
You failed to mention maintenance costs and total life cycle costs in anything you said.
Robb Ryniak wrote:Why make the computer perform a CALL instruction (with all the associated stack management for proc address and arguments, etc.) when it doesn't need to? What for? To make it allegedly more readable?? I honestly don't understand the logic behind such refactorings or design methodologies. It seems so wasteful to design so many layers into a project just because some people have a hard time reading longer segments of code.
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.
Software development is not a rigorous discipline and practices are acquired based on many factors but because the community is so broad practices that work become the norm over time.
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.
Robb Ryniak wrote:When I was coding on XT machines with a scant couple of Mhz at my disposal, every single instruction mattered... ALOT.
And when I used punch cards every single key press mattered since it could take a half an hour turnaround to find even syntax errors.
But those days are past and are irrelevant for most business domains. The most relevant business domain that is even close to that these days is embedded programming and even those are getting away from small space constraints (over the entire field, some areas still require it.)
Robb Ryniak wrote:like trying to make programmer's jobs as easy as possible?
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.
Robb Ryniak wrote: I guess I'd like to understand why the quest for performance seems to have been nearly completely abandonded in favor of making code as readable as possible..
Because performance is most significantly impacted by requirements and design. Not implementation. Excluding implementation design errors, which are still design errors, performance improvements at the implementation lever are almost always in the small percentages. Whereas design/requirements problems can result in order of magnitudes difference.