[gameprogrammer] "Mission Efficiency" - Blue Collar coding

At 03:07 PM 03-05-04 -0500, you wrote:
>On Sun, 2004-05-02 at 03:54, grant hallman wrote:
>
>Grant, don't take anything I say in this message overly seriously. I
>agree with you 100%. But, man, did you leave me a lot of places where I
>can pick nits :-)

I did say, 'fire away' ;)

[snip]

>> I'm gonna go long with this very interesting question, and take it in the
>> context of programming generally, not just game programming. I'm also gonna
>> recognize that the line between language and o/s can get pretty blurry, as
>> anyone who tries to write a Windows app in C, or a Unix app in Fortran,
>> quickly finds out, so i'm gonna treat the language and the o/s as the
>> single thing they are, called the Development Environment. 
>> 
>> I invite uall to think about the kinds of things that go into a program, as
>
>Bein' a convert to the southern way of speakin' Ah must say that the
>word is spelled "y'all" and pronounced "yaaal" with heavy drawl.
>Seein'it spelled "uall" (surely pronounced "you all") makes m'eyes itch.
>:-)

Ah knooows how it's spelt, bro', i consider "uall" a sort of amalgam or
compromise between the e-contraction "u" and the very useful illicit plural
"youse". Just take it as an idiotsynchrony of email.

>> a mission-specific heirarchy. When u sit down in front of a blank screen
>> with a programming job, u already have an idea of how to write the code
>> that will accomplish the core mission. To pick a simple illustration,
>> suppose you're writing a word processor app, and you're working on the
>> "find and replace" function.
>> 
>> U were born knowing how to write code that scans a block of bytes looking
>> for a string, and replaces is with another string. That's the core mission,
>> call the code that does that, the "A"-level code.
>> 
>> But wait, u hafta let the user tell u what the "before" and "after" strings
>> are. (I assume that since we're working on the find/replace function, the
>> code that gets us to this module is handled elsewhere.) Ok, we'll need a
>> piece of screen (i'm deliberately avoiding the language of any specific dev
>> environment) that asks the user what string to look for, and inputs the
>> keystrokes that give u that string. Same for the replacement string. Call
>> that code - that prompts the user and gets his reply - the "B"-level code.
>> It's not the main job, but u need it, and u can't expect any other module
>> to know how to do it for u. Other B-level code would be tasks like getting
>> the document text from the HD, or telling the o/s what font u want. Things
>> that have to be there no matter how the o/s is written.
>> 
>> Everything else, every single line of code that is not directly related to
>> the problem the coder is trying to solve, is "C"-level code. That means all
>> the includes, all the constructors & destructors, all the "redraw your
>> screen because the o/s just erased it", all the "initialize the graphics
>> library" and "ask the o/s for the resources u want" and "see of the o/s
>> wants u to respond to something now", and everything like that. All
C-level.
>> 
>> I'm not saying there shouldn't be /any/ C-level code. Every program of
>> course needs some of all 3 levels. What i'm asking is that u notice how
>> much or how little of it, there is. Because the problem i've watched
>> develop with the whole software industry, is that the "C-level" code has
>> grown out of all reasonable proportion. Almost without exception, every new
>> dev environment i've worked in, has demanded more C-level code than the
>> previous one, all the way back to WATFOR running on an IBM 360/68, with
>> (shudder) JCL.
>> 
>> Notice i'm not saying any one of the C-level tasks is a Bad Thing, in and
>> of itself. I'm saying that more is always worse, and that the most common
>> dev environment we have today - Windows and C++ - has pushed that ratio to
>> mebby 80% or higher of C-level code.
>
>C/C++ were really designed as system programming languages first, and
>general purpose languages second. In you example they are being used in
>a problem domain they were not designed for. Hence the problem that
>almost all the code you write is C level code. The language doesn't
>support what you are trying to do so you have to code all around the
>problem to get anything to work at all.

But notice, my comment is not about C, i could have given the same example
in Fortran. I rise above these petty nits ;)

>> Try this test: take a finished module u either wrote, or know very well
>> what it does. Analyse the code as follows. Look at how much of it is
>> dedicated to the actual, core thing the user wants the computer to do - the
>> "A" code. Count the lines. Next look at how much of it is "B-level" code -
>> places where there really is no reasonable choice except the programmer
>> tells the o/s what he needs. Count those lines. Everything else is
>> "C-level". Mark each line, count the lines, figure the percentage of each.
>> (Comment lines don't count).
>> 
>> How much of each have u got? I say, if the C-level chaff is over about 20%,
>> u have a marginal dev environment. If it's 40% or over, you need a new one.
>> If it's over 80%, u must be operating in a weird world where some very poor
>> designers have somehow gotten in charge of things they don't know how to
>> do, and for some unfathomable reason, your entire industry is letting them
>> get away with it.
>> 
>> How badly would u like a dev environment where u can write (letters show
>> code level for illustration):
>> 
>> begin main                                 C
>>     move_cursor_to(50,20)                  B
>>     set_font(face="arial",point=10)        B    
>>     print("Hello World/n")                 A
>> end main                                   C
>> 
>> ...and behold, the words appear, in 10-point arial, at pixel (50,20). No
>> muss, no fuss, if the o/s needs your screen space it takes it, and then it
>> puts it back, like a good servant, and u never feel a thing. The compiler
>> is smart enuf to realize that because u said "print(", you needed <stdio>,
>> and just handled it. And all those 1000's of li'l anklebiters that make
>> "hello world" run to 1000's of lines of code in Borland 4.52, ghod knows
>> what in VCC, just get handled in sensible ways.
>
>Yep, this could be made to work. With a little lazy evaluation you can
>put off the creation of the window until it is actually needed to
>display something, and using the current cursor location and the size of
>the string being printed you can determine the size of the window that
>is needed to display the text. 
>
>The nits are in the details. 

Of course they are, which is why i haven't provided any. The above is not
an illustration of how to program, or even what a program would look like
in a good dev env. It's there only to illustrate the A-B-C's of a good dev
env. From the comments of a few others, new-gen (Windows/OO) programmers
are not used to thinking in these terms at all, which IMO is a great
oversight on the part of whoever trained them.

>You don't really know where (50,20) is
>until you know what the font and its size is. (Are those pixel or
>characters coordinates?) And then, you need to know whether it is a
>fixed width font or a variable width font and if it is a fixed with font
>you need to know how to determine where the 20th column is. How wide is
>the default character? Do you use the width of blank, or of capital M?
>What about non-latin alphabets? Oh and lets not even mention the
>problems caused by right to left and top to bottom languages. Oh, yeah,
>what if the arial 10 font on the customers machine is mapped to a
>different font with different font metrics than your arial font. And,
>what happens if they don't have an arial font at all?
>
>Would you even see the output? The program terminates immediately after
>displaying the text. Wouldn't the OS clean up the window after the
>program terminates? So, on a slow computer you might see a flash as a
>window appears and then disappears. On a fast computer, or if you
>blinked, you wouldn't see anything at all.
>
>Also, all of the commands assume a single window. If the language/OS
>supports multiple windows in an application you must designate which
>window's cursor is being moved, whose font is being set, and where the
>text is to be draw.

If i'd been talking about the above as a program and not an illustration of
A-B-C, i'd consider myself just about "nitless" by now ;-D

Of course all the points u raise would need to be addressed in any dev env.
One would hope reasonable defaults would apply. But as important as these
issues are to get right, i'm talking about a more fundamental criterion for
a dev env, one which IMO is directly related to both coding efficiency and
program reliability, and one which has been stunningly ignored the last 10
years or more. Call it "Mission Efficiency" - ME - the ratio of A plus B
level code to total code. Programmers are now wallowing in environments
with a Mission Efficiency hovering around 5 to 10%, and wondering why
everything takes so long and is so hard to learn.

And development time (aka "cost") and learning curve are far from the only
negative effects. Programs have bugs. The bigger the program, the more
bugs. The relationship is not that far from linear, other things being
equal. So compare an app written in a dev env with a ME of 10%, with one
done at 25%. Let's say the mission-critical A and B level code is 100
lines. The first case, the app will run to 1000 lines, the second case, 400
lines. That makes the first case 2.5x more likely than the second, to have
a bug.

But of course "other" things aren't anywhere near "equal". More complex
environments require more complex handling of the C-level code. How many
hours have any of us spent, trying to break thru the wall to get the
!@#$%ing (insert name of graphics library) to just put the !@#$%ing square
on the !@#$%ing screen, when the real problem turns out to be some dinky
little underdocumented control call not made, and in fact if the library
had been designed right, u wouldn't even need to handle the control at all.

>Lets try the same example in a different flavor of language. A gold star
>to person who identifies it. 
>
>make joe a new window     C
>joe font "arial"          B
>joe metric "M"            B
>joe size 80, 40           B
>joe cursor 50, 20         B
>joe print "Hello world"   A
>joe display               C
>await joe close           C
>exit                      C

A=1, B=4, C=4. ME = (A+B) / (A+B+C) = 56%, not too shabby at all.

>Same basic idea, slightly more C and B code. More verbose. It does
>handle the issues I raised. And, it is object oriented (which will score
>no points with Grant!)

Hey, i don't have anything against OO as an optional programming technique.
I _strongly_ protest it as a religion, especially as an _obligatory_
religion. What no one seems to be asking is, for any given app, are the
benefits of OO worth the cost? No point asking - if u wanna write code for
a PC today, u use OO.

It is my sordid, heretical little secret (Bob already knows - others, cover
your eyes!) that IMO OO, as implemented in any of the popular Windows dev
envs, is by and large counterproductive. By that i mean, its cost is not
often larger than its benefits. 

And before everyone crawls all over me on this, have a good hard look at
what you've been told the "benefits" of OO are. There's not many of them
that i haven't enjoyed as a matter of programming style for the last 35
years, and i never touched an OO environment until, oh, '97. But, i digress...

>What should be worrying you is the line "joe display" should it be
>before or after 'joe print "Hello World"'? Should it be there at all?

My vote is it shouldn't be there at all, because if i say something as
basic as "print", it's pretty safe assumption i want it to hit the screen.
Of course i also want a way to build a frame and flip to it when it's
ready, but that should be handled by a different output protocol.

>> Because, boys'n'gals, _everything_ that's not part of the module's mission,
>> is a distraction and a dilution of the programmer's effort. 
>> 
>> Yeah, well, i'm already in high rant, and i haven't even gotten to the
>> question Bob asked. I will, but first, think about this: how much of your
>> work as programmers is spent writing the program _u_ need to write, and how
>> much is spent dicking around dealing with things that have little or no
>> relationship to it? I think that ratio - (C-level / total) is critical in
>> evaluating your dev env. Blue Collar Coders like it reeeeal low.
>> 
>> fire away - grant :)
>
>You got it! I like the way you think. 

Thank u, sir, u ain't too shabby yerself! :)  

Assumptions need a periodic rattling, and on the issue of ME, it's well
past time. Besides, sacred cows make the best hamburger ;)

cheers - grant

Other related posts: