[gameprogrammer] Re: Blue Collar Coding

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. 

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.

> 
> > 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

Other related posts: