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