[gameprogrammer] Re: Blue Collar Coding

At 04:26 PM 11-05-04 -0500, you wrote:
>On Tue, 2004-05-11 at 12:55, Latimerius wrote:
>> On Tue, May 11, 2004 at 10:09:23AM -0500, Bob Pendleton wrote:
>> 
>> > I didn't get the same things out of it that you did. I thought he was
>> > making a couple of different points. The first being that algorithmic
>> > optimization works better than low level optimization. This is something
>> > that has been shown to be true many times.
>> 
>> Agreed.
>> 
>> > The counter argument, and all the counter examples show that while
>> > algorithmic optimization works best it is hard to do in low level
>> > languages like C.
>> 
>> How exactly?  And in your opinion, is it still hard to do in C++?
>
>It is a matter of how the brain handles details. The human mind has a
>limited short term memory, usually around 7 things can be kept in memory
>at one time. The number of decisions you can make and the speed at which
>you can make them is also limited. The result is that to do the best job
>possible you need to reduce the number of extraneous details you have to
>keep track off and the number extraneous decisions you have to make. An
>example is something like using strings versus using C characters
>arrays. It takes less thinking to code:
>
>answer = "no " + name;
>
>than to code the equivalent strcat() function in C. So, you get more
>code written and it is more likely to be correct in a higher level
>language. 

The principle of distractions interfering with programming applies at both
ends of the language spectrum. If Assembler is too simple, then a language
which is so hi a level it brings its own distractions, is just as much a
problem.

As comparison, when i started work in C++, i found i did slightly better if
i got the actual code (A-level code) working first in C. Then i could carry
a working algorithm into the OOP jungle, and only have to fight the OO
layers, not actual programming bugs. This is the other end of the way you
told us u wrote in Pascal and ported to assembler.

>My example actually was itself and example. I can never remember the
>exact arguments to the C string functions so I have to go look them up.
>(Not hard in emacs) but it is a distraction. It make me look at the man
>page and take in new details that push old details out of short term
>memory.
>
>I read a PhD thesis once where the fellow had developed a high level
>language for doing microcoding. To evaluate it he had a couple of people
>code the same problem. One person had to use the brand new compiler and
>a brand new language that he had never seen before. The other got to use
>an assembler that he had been using for several years. Both programmers
>had equivalent experience with microcoding on the target machine. To
>make the test somewhat reasonable they were given a written
>specification and had a fixed deadline for when the program had to be
>written. Snapshots of their work were taken daily and detailed records
>were kept.
>
>Both guys started coding the solution the same way. At some point both
>guys saw that there was a much better way to solve the problem. The guy
>using the high level code was able to reorganize his existing code and
>rewrite only had to rewrite a small part of it to switch over to the new
>technique. The fellow using assembler realized that he would have to
>through away just about everything and rebuild all of his lower level
>code (what Grant calls C and B level code). Since he didn't have time to
>do that he just made the code work using the first technique.
>
>The result was that the programmer using the high level language
>produced a "better" piece of code. That is, it was faster and smaller
>that the code written in assembler. When people looked at small sections
>of the code they had to admit that the assembly code was better
>optimized at the lowest level. But,the high level code was still smaller
>and faster.
>
>To answer your second question: C++ is kind of half way between a low
>level language and a high level language. If you use it correctly it is
>a high level language with all the advantages of a high level language.
>
>OTOH, it is really easy to get lost in a maze of peculiar details when
>using C++. There temptation to "go low" to save a couple of nanoseconds
>can derail an entire project.
>
>> 
>> Yes, low-level languages can be pain to work with since every small task
>> can take tens of lines of code.  However, exactly because they are
>> low-level (= support just a small (but hopefully orthogonal) set of
>> primitive concepts) they are well suited for expressing a wide range of
>> solutions.  It's up to the programmer to build a set of higher level
>> abstractions upon the primitives supplied by the language and then do
>> his algorithmic optimization in terms of those abstractions.
>
>Yep, but as the layers you have to build can also be a noose around your
>neck.

I think this whole concept is worth a closer look. A programming language
is simply a tool by which a programmer can get a computer to do something
its hardware is capable of doing. The distinction between o/s, library,
language, low-level vs high-level, is in a way entirely artificial. All
that matters is that the right pixels light up, that the right bytes are
sent or saved, ultimately, that the user gets his job done.

I know i'm stating the obvious and ignoring half the world here, but bear
with me a minit while i try to express a subtly different way of looking at
this. 

I think the people and companies who have given us our development
environments have been using a paradigm which is exactly upside down. The
o/s is not the king, it's the servant. Look at is as tho u were watching
software evolve differently than it has. If u started with a chip like the
8086 and a single-user app, u might do everything in assembler the first
time, then u might invent C. Then u might standardize various low-level
tasks like talking to the HD, as "libraries" everyone could use. Then you'd
build a file structure on top of that, every app doing its own thing. Then
someone would standardize the file structures so apps could share data. But
it's still all a library u link when you build your app.

Then other functions would get standardized, and gradually an o/s would
emerge, but it would look like a library which embodied agreed standards of
how to manage the HD, memory allocations etc. That's what an o/s is, at
bottom - and there's no "natural" division between o/s and app, just
conventions.

Let me try an example. Every time i moved to another dev env, e.g. when i
hit DOS and C, i'd have to start over building my own "library". I think
most people do this. At the bottom, i'd have stuff like "put a character on
the screen", and "get the next keystroke" and "open a file". Those would be
as close to hardware and as fast & efficient as i could make them. 

Next add another layer - "output a string", and "parse user keystrokes". 

Then another layer: "issue this prompt, put the user's parsed,
error-checked reply _there_."

Hey, now it's time to build a screen editor, let the app designer make up a
whole screen at a time, defining text, colors, input fields, edit
parameters, into a standard struct. Now the next layer of code looks like
"run this menu, defined by this struct, put the user's replies where the
struct specifies". And a whole page of HI gets handled by a single function
call, might look like:

   if (run_menu(struct page, int page_number, struct user_replies)) [handle
inputs] else [handle errors]

And when i have to move to another environment, i'll rewrite the
lowest-level functions as needed, and everything above that will run fine.
Same thing if i'm building a game engine and the tools are rendering and
3-d modelling.

Now the point of that story is to notice what the programmer is actually
doing. He's building up a set of tools which meet his needs. In effect,
starting with "getch()", he's creating his own higher-level language -
really, a heirarchy of languages, each more powerful and less general than
the last. Thus "run_menu" is more powerful than "getch()", but conversely
it's less general, more specific. It assumes things like "the user now
wants to enter a page of text", which make it more tightly bound to the
kind of app it's used in. All high-level languages are more tightly bound
to a class of apps like that, or they drown in their own infinite generality.

What i'm saying is that at bottom, the job of programming is to organize
tasks in ways that are clear to the programmer - all the way from what the
user sees, down to what the hardware does. All the libraries in the world,
all the APIs, every o/s, are nothing more than tools to get that job done.

And if it's true that task organization is the core job of programming,
then what i want from a language is not "high levelness". Because the
higher the level, the more powerful but less general everthing about it is.
I want the language to make it as easy as possible to do the one task which
all good programmers do well: to define a language - my own language - the
language i decide is the one to do my app. Let me say that again:

If i'm right about this, then this is true: what sets the top 5% "cream" of
programmers apart from the rest of the pack, is their ability to construct
appropriate containers for the tasks they are organizing. The key word is
"appropriate". When u look at a poorly-written program, u see
poorly-defined functions with unclear missions, which may have been tested
and "fixed" until they don't do Bad Things, but which still represent a
dog's breakfast as far as organizing the task. When you look at a
well-written program, it looks "obvious", as tho there was no better way to
get the job done. Everything makes sense. The various parts fit together
sensibly. 

And most important, what the programmer really did between his ears, was to
make up his own language in which he could describe the program's mission
in clear, simple terms, and then develop that language, and then write the
program in a few simple, powerful sentences, and then implement the verbs
and nouns and modifiers of that language, down to the lower level the dev
env offers.

I say again: what i want from a programming language, is the best possible
environment for making my own language to describe the app's mission in a
clear, concise way. Everything else is a tax on my productivity.

cheers - grant


>> > The second point was that computers are now fast enough to allow the use
>> > of high level languages for problems that they were never considered for
>> > in the past because of performance concerns. Which makes algorithmic
>> > optimization easier to do.
>> 
>> Well, yes, the range of problems that can be solved with Python is much
>> wider than a couple of years ago, I gladly agree.  But this range by no
>> means includes all or even most problems, IMHO.  There's still a lot of
>> places that cannot tolerate anything interpreted.
>
>I agree with you. Almost. What I like to see is when someone takes the
>core of code that has to be very fast and makes a nice library out of it
>and then binds that library to an interpreted language. The code that
>uses the library is rarely performance sensitive, and yet the
>performance sensitive parts run at the fastest possible speed. That
>approach gives you both flexibility and performance.
>
>BTW, the distinction between interpreted languages and compiled
>languages it completely artificial. It is possible to compile any
>language and it is possible to interpret any language. I should be able
>to write C++ code and then run it in an interpretor and debug it in
>source code form. Then, when I am working on a different piece of code
>the IDE should just compile it for me while I'm not looking.
>
>> 
>> Anyway, the difference between the lower level (C, C++) and higher level
>> (Python etc.) languages that matters the most to me is not about
>> performance (interpreted languages are getting faster and most of the
>> time, I don't need cutting edge performance anyway) nor is it about
>> their "high/low-levelness" (C++ is considered low level but you can
>> build your high-level abstractions into it very elegantly).  To me, what
>> matters the most is the difference between the static, compile-time
>> nature of C/C++ and the dynamic, run-time, introspective nature of
>> Python.  That's what has the most profound influence on design of the
>> software IMHO, at least in the realm of OOP.
>
>I have to agree with you. I just wish people would write compilers for
>the interpreted languages and interpreters for the compiled languages.
>:-)
>
>BTW, what you said was as true for BASIC versus FORTRAN back in 1974 as
>it is for Python versus C++ in 2004.
>
>> 
>> > Anyway, that is what I thought he was saying.
>> 
>> I might be overreacting.  High-level, interpreted languages seem to be
>> all the rage now and some people seem to enjoy ramming them down
>> everyone's throat.  
>
>It happens every few years... Makes me want to scream.
>
>> I mean, I'm glad to have Python and even if I'm far
>> from being a Python guru, I use it when appropriate.  
>
>You know, I nearly got hives the first time I looked at Python. The
>languages makes me itch. For me, even reading Python code is like
>petting a cactus. I have a serious dislike for Python. I feel kind of
>silly about it. My dislike is more philosophical, almost religious, than
>technical. A language has no right to tell me how to lay out my code.
>
>> But it's just
>> another tool in the toolbox, no new be all end all of programming.
>> Remember when OOP was the Next Big Thing?  The aggresive advocacy
>> alienated a lot of people, some of them haven't even recovered yet. ;)
>
>Yep, you are absolutely right. There are people who jump on every new
>thing (not that Python is all that new) and proclaim it to be the
>solution to all the problem and then try to force every one else to
>follow their new found religion. 
>
>> 
>>      latimerius
>> 
>> P.S.  For us who don't know English very well, what is "Blue Collar
>> Coding" supposed to mean?  I have a clue about the blue/white collar
>> distinction but I'm not sure I understand, anyway.
>
>I think there are three classes of workers being discussed here:
>
>Blue collar - Someone who works with their hands. Not necessarily
>unskilled. Blue collar workers can be very skilled and even have
>advanced college degrees. Engineers are sometimes referred to as the
>blue collar profession. 
>
>White collar - People who work with their minds. Not necessarily well
>educated. White collar workers work with information more than with
>things.
>
>Ivory Tower Types - The college professors and R&D people in
>corporations. 
>
>There are attitudes associated with each of these stereotypes. Blue
>collar tends to think in terms of getting the job done. Does a tool
>work, yes, then use it. Does the tool get the job done on time and
>within budget, then use it.
>
>White collar types are more likely to think about things a little more.
>Often they think about things to much. My dislike of Python is an
>example of a white collar attitude. 
>
>The Ivory Tower types think too much. For example, they may worry more
>about the politics of the company that makes a tool than whether or not
>the tool does the job. 
>
>Compare a commercial potter (blue collar) who goes to a college art
>professor (Ivory Tower) looking for help trying to improve the out put
>of his kiln. Only to find that the professor has carefully crafted a
>perfect replica of a 5th century Chinese kiln and imported Chinese clay
>in his attempts to replicate 5th century Chinese pottery. But, the
>professor knows nothing that can help the poor potter solve his problem.
>The potter will walk away shaking his head in dismay thinking that the
>professor is wasting time and money for no good purpose. 
>
>I think that Grant is talking about coding tools that let you write code
>the same way a commercial potter makes pots, rather than the way the
>college art professor makes pots. The commercial potter needs to walk
>across campus to the engineering college and talk to the write people
>over there. People who understand the needs of production potters.
>
>Write now there is an awful lot of Ivory Tower influence in our
>programming tools. 
>
>Personally, I think it is time to rethink programming languages and
>environments.
>
>                       Bob Pendleton
>
>> 
>> 
>> 
>> ---------------------
>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>> 
>-- 
>+--------------------------------------+
>+ Bob Pendleton: writer and programmer +
>+ email: Bob@xxxxxxxxxxxxx             +
>+ blog:  www.Stonewolf.net             +
>+ web:   www.GameProgrammer.com        +
>+--------------------------------------+
>
>
>
>---------------------
>To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>
>



---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: