Slashdot Mirror
The Programmer's Stone
JeremyNobody writes "The Programmer's Stone is a marvellously insightful essay on the nature of programming. It makes a great distinction between "mappers" and "packers" that sheds a lot of light on hacker culture. It also has a lot to say about the Quality Plateau, Design Patterns, the povery of methodologies and the false goal of deskilling. Not to
mention Who Stole my Vole ? "
I believe very much that solutions emerge from holistic understanding of systems; from knowledge of computers, systems, and people so deep that decisions are more instinctual than conscious. That has been my experience. The "aha!" feeling. The flash of insight.
This appears, in this messy and poorly organized essay, to be the essence of mapping.
What I dislike about this is that this non-linear thinking arises most frequently from the fertile soil of "packer" knoweldge and experience. Every programming "genuis" I have known has not only been capable of this instinctual synthesis, but has also been posessed of encyclopedic knowledge of these nitty-gritty technical details.
The acquisition of knowledge is drudgery. The syenthsis of fact into insight is creativity. All the creativity in the world will not help you, however, if you are writing and operating system and you don't know that the interrupt enable flag is cleared on entry to an interrupt service routine and must be set on exit.
I guess what I am saying is that while modern pedagogy may overemphasize rote learning over synthesis, thought, holisticism, without the facts you have nothing.
I tend to believe that the problem lies not in how education teaches facts, but rather in that we have "dumbed down" the number facts taught. I think the human mind is so hungry for patterns that, if taught enough facts, and allowed the speculate, this facility for insight will develop on its own. When you are not taught enough about anything to see the interconnectedness of things, is it any wonder we are locked in this "packer" mode?
I remember being fascinated by the fact that the mutilples of 9 add up to 9 (for the first few mutltiples:
9x2=18 1+8=9
9x3=27 2+7=9
...
...
You find patterns like this all over the place. How 'bout the fact that you can calculate pi with this little succession:
4 * ((1/1) - (1/3) + (1/5) - (1/7) + (1/9)...
I guess what I'm trying to drive at here is that I think the solution is NOT to push people into the fog, but to expose them to as many FACTS as possible. Their native curiosity will bring out the innovative qualities.
Unfortunately, we dumb everything down and add the "Simpsonsesque":
"Added extra clap: Not college material."
No wonder all the TQM and ISO 9000 and Vision Statements and Mission Statements seem to me to be a pile of crap, and yet genuine "quality" has always been more important to me that to everyone else.
No wonder it's so important for me to gain a real understanding of the problem, while everyone else just dusts off one of their old methodologies.
Suddenly it all becomes clear. I can't wait to read the rest of it!
RP
Yeah, it was an interesting read, but I don't think it contains any deep revelations.
/. readers do work in corporate coding environments where these practices hold sway, but I'd guess we don't need much convincing. Linux and other successful free software projects prove convincingly that traditional "software engineering" principles are not necessary to make high quality code.
Structurally, the piece is a mess. This would seem to be a bad sign when the subject is one as exacting as programming! I realize that it was written mostly as the outline of a course, but still.
The main thesis appears to be that the most important attribute of people's cognitive styles is the one-bit mapper/packer distinction. As far as I could tell, "mapper" is pretty much the same old "think outside the box" philosophy, while packers are a strawman for inside the box thinking. Ok good, now I understand the world a whole lot better.
The piece did have some interesting moments. I liked the section on the quality plateau. There is a clear moral I get from the story:
An ounce of simplicity is better than a pound of abstraction.
A lot of the piece seems to be railing against traditional "software engineering" practices. Probably a lot of
The concepts of programming, especially those specific to larger projects with many people, are very difficult to master. A lot of writers on the subject delight with with oversimplified metaphors that are actually fairly easy to understand. In the best case, these metaphors actually capture an interesting aspect of programming. I'm not sure that this piece really achieves that goal.
LILO boot: linux init=/usr/bin/emacs
I was introduced to Alan Carter's writings (and his concept of mappers and packers) about a year ago by a mutual acquaintance who independently discovered some of the same concepts, not by working with programmers, but by working with ADD diagnosed children. Since then, i have had numerous discussions about this topic and several points usually come up which i thought i would put here:
1. Alan is not simply labeling two categories of people. He believes that *all* people are born with "mapping" abilities and that these abilities are crushed out of children at an early age. He sees "packing" as a correctable condition, and the Programmer's Stone is intended to do just that (for programmers anyway). He says he has achieved remarkable successes, but i, of course, have no idea.
2. It is extremely difficult to talk about this subject logically. One direct consequence of the description of packers is that they cannot understand mapping. Thus, if you and i disagree, i can always claim that you are a packer and just don't get it. This means that the existance of these two different mindsets can't really be proved. However, it clicks with some people and seems very, very *true* to them.
3. Alan does talk about mapper and packers as if they are discrete, exclusive states, but a lot of people i've talked to believe that people exist along a continuum between these extremes. I'm fairly certain that Alan thinks that as well, but he doesn't explictly say so.
Some of my thoughts here are shaped by things i've read in some of Alan's other writings, especially his "Reciprocality Paper". I am not going to post a link to that paper because the site i got it from seems to disappear periodically, and currently seems to be gone. Also that paper contains an odd Cosmology which i find interesting but which i basically think is a load of nonsense.
-- Mike
Although I had programmed a few toy things in my undergrad classes, I didn't really learn how to hack till I went and worked at a software engineering firm for a few months. There's a difference bewteen my sophomore classes (one assignment was to explore inheritence in C++ by creating new character classes in a simple game) and implementing bugs/fixing features in a large system (my first assignment as an intern was to use yacc to create a language for remotely booting machines over a serial line -- I hadn't even learned C or worked with Unix yet. That changed quickly).
Still, I find I use some things I learned in school mixed with some real world experience -- not too surprising. Having a sense of how a program should be structured can affect how easy it is to maintain and how well it runs. But a student who has only learned C may not realize that a slower, interpreted language like Tcl or Perl may be better for web-server code. Coders who only learn Java may not even know how to manage memory correctly or what the machine-level representation of code is. As much as abstraction is a useful tool for programmers, top-to-bottom knowledge is important when designing anything more than a toy system. That means having the formal knowledge of how computer systems work and what designs/data structures are useful and having the practical knowledge of how to actually make your vision work.
P.S. I actually wrote "implementing bugs/fixing features" before I realized what I had just said. Freud? Who's Freud?