Greetings all! It is I, your egotistical person you don't know creating a topic that's not a horribly unfunny game review! This instead is a horribly unfunny query of opinions!

Allow me to elaborate. During my offices Christmas celebration, as I had no one else I wanted to speak with, I spent a good hour chatting with the Associate Dean of Research (I work at a University), a man who earned his PHD some 30 years ago and apparently never left the academic field.

One of the topics that came up (As we were both programmers, myself a fake one and him a real one in the 70's) was what I termed "Lazy programming". The entire point of this blathering post is to get some other, hopefully more experienced opinions on this.

 Now, allow me to elaborate. During the early days of computing, memory was ludicrously limited. While it seemed  that everything was possible, and advances in programming were made at every turn, the limitations were the hardware. Your algorithms had to be precise, well implimented and planned. Everything had to work well. Your imagination had to wait.

Then time passes, hardware and the effects of the software improve around the same rate, and then suddenly, processing power and memory... become non factors. You no longer had these arbitrary limits, and could obtain the same performance with less and less compact code. Other aspects of the system increase as well, lending helping caches to improve performance in other ways. Disappearing are the little tricks that had to be coded to make your code run more effeciently, make an object appear as it did not, make loading times minimal. Replacing them appears to be a reliance on brute force of processing power.

This was also mentioned by that guy at Bioware, or Epic. I should fact check more. He was noting that crappy coding was affecting the PS3 because the cell demanded good code. That appears to me to be a confirmation of certain problems. From what I have observed, programmers seem to be more and more using the brute force of a console rather than their own ingenuity, and calling things failures when the brute force wasn't delivering (See Lair developers Factor 5).  While this mostly applies to computer programs in general (Considering the processing and memory we have now, it's shocking the wait required for some applications), video gaming as a whole seems to be facing this problem right now, and taking shortcuts out (Hello Capcom and your huge manditory installs!) while coding instead of using the old method of working the hardware to the max, then tweaking it to perform better than expected.

I actually like the 360 a bit for forcing programmers to work their best without a harddrive as extra memory, make them maximize their code, even if the system still may power through on other fronts.

Now the opinion call. Am I totally off base with this, is this far too early into programming where the tips and shortcuts available through wise programming  just havn't been discovered, that the programmers will begin to put effort into maximizing output with minimal input over time? Or is this trend worrying anyone else? That reliance on power is taking over reliance on effeciency?

Oh, and if anyone cares about the opinion of a man with an awful lot of published papers relating to research in Medicine and Physics, he was of the opinion programmers are taking things far too easily with the powerful hardware, and enjoyed Macintosh's as he felt they were often programmed more efficiently. He had no comment on the gaming scene.

Without being able to look through code its sort of hard to say one way or the other how efficient of a job they do. Further complicating matter is that some devs code the engine at one level and then the engine is used to build the game through an editor interface on a high level. There are seriously way too many factors to just guess at this.

I can tell you I know I wouldn't want to build an engine at an Assembly level, but it would be damn efficient if done right.  I'm pretty sure a lot of engine work is actually done on this Assembly Language level as it tends to need that kind of efficiency.

I really don't think anyone programs in assembly any more unless it is for a micro controller that doesn't have a C compiler.

You can always inject Assembly into your C code to optimize things that C does poorly. I would imagine that the best way to program would be to write it in C, check for bottlenecks, and then go back and convert to Assembly only the code that can not be improved by better C code.

There is just way to much code needed in an engine capable of today's games to ever be able to code it in assembly.

Anyways, back onto the main topic. There probably is some of what you call "lazy programming" going on, but I would imagine it is more due to programmers not knowing a better way to do it with the hardware given. If you can say the same thing about the games 2-3 years from now, as those released today, then I would say programmers are getting lazy.

I would write a longer reply, but unfortunately have to get some work done (C and assembly btw). For now, I leave you with this link about Wirth's law:

http://en.wikipedia.org/wiki/Wirth's_law

I'm kinda tired atm (heading to bed shortly) so if this comes off wrong, I apologise.  But you kind of missed what I was saying and then restated it as your position.  

I don't think you have a problem with my first paragraph so I'll skip it since the WYSIWYG editors many "Level Designers", "Scripters", etc.. use now days is most certainly classified as a very high level, above C.

In my second paragraph I say almost verbatim that I wouldn't want to build an engine in Assembly (for the exact reason you mention) and then I go on to say that a lot of engine work is done in assembly.  Which is true, major optimizations are absolutely made at this level because its where you have the most control over the hardware.  And optimization is a massive part of engine building.  Also I think you might be a bit mistaken in your impression of how big an engine really is these days in terms of code length...they aren't short by any means but they aren't insanely large either.  Its definitely feasible to build one entirely in Assembly but like you said, its uneccessary to do so with the right tools.

 I agree with you, that I wouldn't want to write one. I just took it that you thought a large portion was written in assembly, which I would say only a very small portion (a few lines here, few there, but hardly any at all) is written in assembly.

As to the point of being able to write one completely in assembly, I agree, but of course it would be hugely unmanagable. I've worked on a 3D engine before that mapped real time position of objects on a 3D map, with a goal of 1000ks of objects at a time. I mostly built in the ray tracing and bounding box code along with a few other things, but the project was fairly large compared to the engineering tools I typically write.