Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
News

The Programmer's Stone 114

Posted by Hemos from the interesting-read dept.
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 ? "
This discussion has been archived. No new comments can be posted.

The Programmer's Stone More

The Programmer's Stone

Comments Filter:

  • most people are forgetting... (Score:1)

    by Anonymous Coward
    that the problem domain here is limited to programming. So just click on that little filter
    that says "the world has been abstracted," the same way you turned off your reality filter when dealing with classical economics.

    The initial question was, "why are some programmers a whole lot better than others." Well, they have a theory, and broke the world up a bit. They could just as easily used another break, like "can hook up a stereo/tv system", but that wouldn't be quite as useful.

    The main argument in chapter 1 was "some people are better programmers than others because they think differently." It then describes how/why the better programmers think differently than, for the lack of a better term, worse programmers.

    That's all I've read, unfortunately, since I'm way too busy right now to read the whole thing. But as for chapter 1, I can agree with a lot of the results, if not the specifics, of the interaction between the two modes of thought. In the groups where we cranked killer code fast, it was just like the mapper group: we all pretty much knew what was going on, what everyone was doing, and saw the whole picture. In the mapper/packer group, the lack of shared understanding caused widespread chaos and delays, and eventually turned out a crappy, slow, buggy product that was massively over-engineered and was impossible to understand internally.

    The main difference, from a software point of view, comes down to this: if you want to start a project from scratch, get mappers. If you want continuing work and maintenance, get packers.

    Packers are not so good (and may be incapable) of coming up with a good internal design from scratch, and they tend to steal an inappropriate one and use it. However, in a semi-mature product they won't attempt to rearchitect it and redo everything, and will work within the existing structure to flesh it out.

    Mappers are not so good at this, as they tend to regard bad design as bad design and try and change it. However, mappers can come up with effective stuff from scratch, and are capable/willing to have a holistic view until release, making the product self-consistent internally and behaviorally.

    So much for the soapbox. In the armed forces, the analogy would be Army vs Elite units. You don't send in the Army to grab a beachhead, and you don't send marines in as an occupying force.

    I've digressed, but so far I can't see anything that says the mapper/packer categorization to be invalid. It may be that it's somewhat elitist/anti-egaliterian, but so is software development. After all, it -is- a fact that some people/groups churn out killer software consistently faster than others.
  • The mapper / packer concept sounds interesting, but I wonder if he really knows what he's talking about. I don't know because I've only read the first part of Day 1, where he attacks Edwards Deming.

    He has most of his facts wrong here. Deming was not sent to Japan to straighten out their manufacturing. He was sent to help their census department. He was never a proponent of TQM. He was a mathematician and what he did teach was Statistical Process Control. He got into manufacturing by accident.

    I hope it gets better, but you have to wonder...
  • First for those who are interested, information on the Falklands at http://www.thenews.co.uk/news/falklands/menu.htm

    The British military faced a difficult situation in trying to recover the Falkland Islands because of the distance involved, and the orientation and composition of their forces towards European area (NATO) operations. The were ultimately successful, but they had a lot of problems some of which were not revealed until much later. Its not clear which particlar problem at Port Stanley the author is referring to.

    As for US operations in the Gulf as a by the book only operation, that statement is incorrect. The post Vietnam US Army spent a lot of time in the 80's reorganizing the force, and changing operational doctrine so that smaller units were expected to think and act on their own in face of the actual situation. The Marines have a similiar expectation of their units.

    Of course, even with these changes, military organizations have a lot of rules, procedures, and orders they expect people to follow. The reason of course is that often they do work by providing guidance and consistency between different people doing the same job. On better days with the better procedures they may also someone's life.
  • The whole article is predicated on a false dichotomy, and goes on to draw false conclusions.

    The "mappers" vs "packers" terminology is carefully loaded to promote one mode of operation at the expense of another. This sort of linguistic trick seeks to hide deeper problems - that "mapping" a.k.a goal-focused thinking and "packing" a.k.a process focused thinking are equally important and that people need to employ both modes of thought in completing large problems.

    I do believe that the author is on to something with his explanation of why some individuals consistently attain massively higher levels of performance than others. The best developers can internalise large parts of a problem domain concurrently, and thus develop better abstractions and decomposition stratergies.
  • I very much agree with your comment. Along similar lines, I'm always intrigued by how a person's view of the 'set of righteous' solutions for a problem is affected by their experience. As an example, suppose you've seen some code to recursively traverse a directory tree - this code allows you to pass it an abstract class containing methods that control whether a particular branch is taken and to act on each node as you encounter it. Once you've seen this "trick", it immediately occurs to you as a design option for many similar problems (a web crawler, for example) but if you haven't seen it - you'd likely design your software in an entirely different way. I suppose the point of this post is that there are reasonably well known, elegant designs for a great many types of problems but until you've seen them you'll only use them if you are fortunate enough to independently "invent" them. I'm sure most of us have had the experience of solving a thorny problem in a less-than-optimal way and then later seeing the RightAnswer (tm) and thinking "Oh, so that's how it's done" ;-)
  • The pieces about mental structures (I am still in day 1) remind me of the mutant superchildren in Nacy Kress' "Beggars in Spain" [amazon.com]. This is, I have the same difficulties to map their descriptions to my personal experience.

    I guess I'm a mere packer/sleeper.
    --
  • For some reason when I read the line about PacketStorm being taken under Kroll-O-Gara's wing, I had visions of cybrersleuths and William Gibson plotlines. I know the PacketStrom thing is old news, but I never took an interest in it before. Crackers and security are to me at least like income tax - a pain but something that must be take into account.

    However theis JP character sounds like a very dubious character. Regardless of whether he really has employed crackers to breach sites and provide fuel for his crusade, he is still spreading annoying disinformation.

    I wonder if he'll sue me for saying that ...


    Chris Wareham
  • This should have appeared under the Forbes/AntiOnline article.

    Chris Wareham
  • Great read, reminded me of something i've seen in programming practical classes at uni -- the phenomenon which one of my fellow tutors has aptly labelled "Voodoo programming" in which students cut and paste bits an pieces out of the notes... and then yell and scream when it doesn't work.
  • My dad taught me some math tricks when I was a little kid. Some of them are very obvious when one learns high school math, while others are not so obvious.

    A number is divisible by 4 if the last two digits are divisible by 4. For instance, 1234144 is divisible by 4 since 44 is. This is obviously fairly obvious (unless you are a little kid).

    A number is divisible by 3 if all the digits are divisible by 3. For instance, 146922 is divisible by 3 since 1+4+6+9+2+2=24 is divisible by 3.

    Squares: 15X15. Take the 1st digit and multiply it by 1+1, then tack on 25. Hence 15X15=225. 25X25=625 (2X3, shift the digits, then add 25), 35X35 becomes 12 with 25 tacked on to the end, 1225.

  • While University will get you credentials, you've got to do things... on your own.

    Well, I do agree with that quite a bit - I'm not really at university for the credentials. I'm here because it's a very good opportunity to talk to people in the field, in person anyway. (/. is a good place for that too, but different)
    Mostly I'm interested in university because I like being given assignments, ha.
    As far as "delving" goes, I am doing that - but because I don't have any concrete results (other than a working computer?) I assumed that the effects were not sufficient.

    On reflection, I suspect that this apprehension of mine was inappropriate - perhaps I am more of a geek than I thought I was? That is certainly a flattering thought. (I do have a wearable [orantotang.com] Pilot!)
    Perhaps what I need, in this university mentality (ugh) is some sort of test to see if I can "hack" it as a geek...

    Any suggestions? Maybe this would make a good "Ask Slashdot"

    *N
    and if worst comes to worst, I'd make an excellent, though expensive, reference manual...
  • What a dreadful thought! Let's all pretend I didn't mention that. I don't want to be part of something so easily quantifiable.
    Mismeasure of Geek, I suppose...

    *N
  • At what point am I going to stop just reading about the culture [netmeg.net] and the people [stanford.edu] (else [geekchic.com]) and all the neat toys [pfuca.com] and actually become a geek myself? This sort of work depresses me in a big way - I have nothing to show for all the effort I put into learning the systems and languages. Sure, I'm only 2nd year university [utoronto.ca], and I never even thought much about writing software before last year (except in vague fantasies [geekculture.com])!
    At the same time, though, I think reading things like this extensively before even starting any of my planned projects (and I've been planning and planning!) will ultimately help me do the right thing in all the things I do.
    One can hope, anyway!

    *N
  • I've read the first half of this opus pretty carefully. I think there is a good handful of thought-provoking content in there, but it's tangled in some messy presentation.

    They introduce the concepts of mapper and packer without really defining them clearly in the early going. In general, I'm quite wary of folks who invent new names for everything. There's also the sense that mappers (like us) rock and packers suck. They bend over backwards not to say this but they seem to imply it at every turn.

    When I decided that mapper and packer weren't adequately explained, I conjectured to myself that mappers were algorithmically oriented, and packers were data oriented. Mappers understand how to do stuff or figure it out, packers follow the recipe out of the book. If this is so, then it should have been specified at the outset. Of course, every good hacker knows that programs are data. Makes life a bit more complicated.

    The essays are filled with obscure references and British regionalisms. The six lines on the STS SRBs, tramlines, potter mode, specular reflections, and so forth. Why can't the English teach their children how to speak?

    So their "quality plateau" code simplification wasn't correct. The point was well taken anyway, it's important to strive for simplicity and clarity. (K&T braces rock! Oh, sorry.)

    I think it's unfortunate that they buy so heavily into OO and dismisses procedural programming in their day 3 methodologies. Most of the OO code I inherit (MS VC++) tends to be utterly dazed and confused. I know it's possible to write beautiful structured code, but typical VC++ code is full of ratty piles of classes and resources managed by a wizard behind a curtain. Give the average programmer that extra rope they need to hang themselves. Gimme plain old C any time, and design carefully and economically.

    They bow to the false gods of TQM, ISO 9000, and Jackson, Booch, et al. In their own terms, these are all so packet. If only I open Grady's Booch of spells, and invoke the magic methods, I'll get quality code! Quality, quality, quality. Good code comes from good design. That comes from talented people thinking clearly. You can't fake it with a bottle of snake oil and an ISO 9000 certification.

    Alan and Colston do have lots of good and thought-provoking ideas. It might work out nicely for them to share their ideas in the open source spirit, and see what kind of help they can get from the multitudes. I'd say that their work is full of flaws, but it's sprinkled with sensible and interesting ideas. Worth a read, bring your grain of salt, and don't take it as gospel (if you take the gospel as gospel).

  • Our machine learning teacher regularily compares the programing styles of some students to genetic algorithms. Start with something that vaugly works, make changes in a random manner and occasionaly add some new code.

    End up with something that works on the test data only. :)

  • I've tutored a first year university programming unit and also would consider myself a mapper. I can only make assumptions about what I've seen but what the lecturers say back this up.

    Most people (first years especially) have difficulty in applying knowledge to different problems. It is amazingly difficult to teach some people the concept of functions, when to use them and when not to. Come to think of it, that whole flow of control thing is quite tricky for some :P

    Then we get to the whole *genetic algorithm* approach to programming as employed by some students. They (occasionally) think of what needs to be done and then implement something. It doesn't work so the swap some code around. It still doesn't work so they add some code. And so on until they end up with a monstrosity of a program that they have no idea how it works.

    Occasionally, when they are given test data, you get code along these lines (example of doing something to a linked list, exactly what is not important):

    if an item is two items from the end of the list and it's value is 4 and the list is 12 items long then ...

    Makes marking a lot easier :)

    Hayden

  • I've a hard time understanding this essay. As far as I understand, it deals with mappers and packers, where:

    • mappers are able to "create integrated conceptual pictures" of their knowledge
    • packers have disjointed bits of knowledge

    In fact, the packers (are said to) tend solving problems without taking into account the context, in a purely aristotelician methodology.

    The mappers have differing and numerous non-aristotelician approachs of the problems which is consistent with the essay.

    I'm saying all of this because the essay reminds me of the null-A trilogy by A.E. Van Vogt. The general idea of the trilogy is said to come from the book "Science and sanity" by Alfred Korzybski (sp?) which I never have to chance to read.

    Can someone confirm that I'm not completely way off?

    While I'm at it, did you notice that the reworking of the sample in chapter 2 (the one with the mutex(es)) migth be a perfect example of the refactoring thing discussed several days ago?

  • But to say that people are either one or the other, mapper or packer, is ludicrous.

    Exactly. Mappers switch to packing when there is way too little information to understand the situation, and no time or even interest in figuring it out. There may be a standard procedure though.

    Packers may switch to mapping too, when there are no applicable procedures for the situation at hand, and avoiding it is impossible too. Such as the Japan example in the text.
  • Sure, passit along and I'll post it on my site. URL to follow.
  • Does anyone know of a version of this in an electronic book format? anyone interested in compiling one?
  • The rambling lack of organization, the very parochial assumption that the reader shares his narrow cultural and linguistic framework, the pronouns that have no obvious referent - the generally horrible writing style, in other words - could be fixed by a few working sessions with a talented editor. But not fixable at all is the failure to provide any reason to believe that the packer/mapper thing is in some way related to whether an individual is a superprogrammer.

    In spite of all its flaws, however, this piece really is a terrific starting point for a worthy discussion. Just another instance of our failures being more valuable than our successes.
  • Well, this seemed a bit long to read online, so I converted it to .pdb (doc format) so that I could take it with me on my Pilot to read. The zip file is over at:

    http://members.xoom.com/Mikem42/pstone.z ip [xoom.com]

    And readers are widely available...

    - Mike

  • I munged it into doc fomat as well. Results at: http://members.xoom.com/Mikem42/pstone.zip [xoom.com]
  • "So what you're saying is, there are two kinds of people in the world,those who believe there are two kinds of people in the world and those who don't. Oh Wait. :-) "

    The truth is, that's almost exactly what i'm saying. The statement of the theory causes it to transcend logic. We get the same kind of result if you attempt to prove to me that God does not exist. You present a proof, and i might say, "Well, it looks like a correct proof, but since God is omnipotent, He might have adjusted our minds to be fooled by just such an invalid proof."
    Or i might claim to have psychic powers, but (as is often claimed) they don't work if you try to test them.

    None of these things are proofs of existance, of course. They are only proofs that existance cannot be disproved. (For the mathematically inclined: Check out this feature of the Axiom of Choice in ZF.)

    My point here is that there is little point in logically debating the existance of a group of people who by definition do not accept logic. This is the sort of thing that one either accepts or rejects based on intuition and experience (or superstition and prejudice as the case may be).

    -- Mike

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

    You've completely missed the point.
    We have this knowledge of the "nitty gritty" details because we find them interesting.

    The acquisition of knowledge is drudgery.

    No, the acquisition of knowledge is learning, a new discovery, a source of exhiliration.
    Having useless facts rammed down your throats by clueless teachers in the cesspit we like to call public education is drudgery.

    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.

    It will if you are capable of mapper thinking.
    Ever heard of tech manuals?
    A mapper is not daunted by lack of knowledge.
    A packer is limited by lack of thinking.

    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?

    No, the problem is that they teach you WHAT to think instead of HOW to think (packer vs mapper, anyone?).

    There is a BIG difference between how the function code pins work on the m68000 CPU and the dates that each explorer came to the americas (Can you believe that in grade 9 I had to memorize this shit in order to pass the course?)

    I gained my knowledge of computers and programming through "mapping"-like thinking, if you will.
    I was fascinated by computers and how they worked. The knowledge was a natural result of an inquiring mind.
    As for the explorer dates, they are all gone, wiped clean from my short-term memory once the exam was over.
    I lost interest in school after getting straight A's in first and second grade.


    Oh, and by the way:

    - Thomas Edison did NOT invent the lightbulb.
    - The Wright brothers were NOT the first to fly a manned airplane.
    - Columbus did NOT discover America.
    - "Honest" Abe Lincoln, your favorite president, was very much in favor of the slave trade.

    So, what else did you "learn" in school?

  • >We have this knowledge of the "nitty gritty" >details because we find them interesting.

    You find them interesting because you learned enough of them for your innate ability to think (to "map" as these folks put it) began to get interested in acquiring facts because you began to see a "map."

    Actually, no.
    I found them interesting because one day I went to my friend's house and he was playing games on his TV. I asked him how he did it and he said his dad programmed the games into the machine.
    I thought "COOL! I wanna do that too!", and a programmer was born.

    I learned the concepts of a computer by playing around with it and consulting the user's manual when I needed more information, not from a textbook.

    This is the difference between knowledge and faith, and the application of judgement based on observation rather than belief is the difference between wisdom and dogma.

    Precicely.
    I rely on observation. Most people just believe what they're told.
    My first question about anything is "how do you know it's true", not because there's some huge conspiracy...
    [checking my tinfoil hat]
    ... but because non-truths tend to become the collective truth of a society once it has been thrown around for long enough.
    The problem is that our school system doesn't teach the kids to use their brains to question things, to check things out for themselves and prove to themselves that something is true.
    I find it a satisfying excercise to just out of the blue start questioning the validity of something I've always implicitely believed in and bash it around a bit. The results can be startling, not from the fact that you were throwing around, but from the other ideas that are introduced as you do it.

    There is no substitute for study, for the exercise of memory. There is no subsitute for rote learning when it comes to the acquisition of "facts." Facts become the arsenal for the expression of "thought," which is the higher synthesis of information, the only truly human act.

    Obviously, facts are important. Dry facts, however, are not.
    Facts with a story behind them are interesting to read. Facts alone compartmentalized into lists are not.
    When I hear about an explorer of the americas, I want to hear about what he did, about the trials of the open sea, about how the boats were constructed to survive the tempests of the Atlantic. I want to hear of their first contact with the peoples of the new world and how they survived their first winter here (Thankfully, the trials of Cabot in his first winter up the St Laurence were included in my history book, and as a result it is pretty much all I remember about that era). In essence, I want a mapper's account of history.

    This is a FAR cry from a bland list of explorer's names and dates (the packer's account of history).

    I completely agree that mapper thinking exists. I just think it arises from a combination of wide knowledge AND self-confidence that one's thoughts are worthy of expression.

    Mapper thinking is the ability to examine what you DO know in order to formulate the right questions you need to ask to expand your knowledge.
    Mapping is a technique designed to find the optimal route to the facts you need.
    Packing is a pre-packaged list that everyone is expected to learn, whether it is useful or not.
    All facts are, of course, useful, but only at the correct time and in the correct context.

    I know nothing about the social etiquette and customs of the bushmen in Australia, but if I were going to the outback to meet some, I sure would find out in a hurry.

    Granted, there are certain things that a human being must know in order to function in society, but most of what they teach you (content, not topic) is of little value.

    Feynman's DAD on the other hand is a miracle. Feynman's dad would not say, "No, that's wrong." instead he would say, "Interesting idea. I wonder how we can test that?" Feynman being a genius was inevitable after that.

    This is the very essence of mapper thinking.
    Mapper thinking is a means to get the facts, not a replacement to them.

    Yes, I can. And I think there's nothing wrong with that. I'm not sure why you think there is. You never know when those facts may become integral to a much more sophisticated thought. No datum is without value.

    You know, that's exactly what my teachers told me.
    Guess what? it's still useless.
    I do have an interest in the area of the explorers, but I can easily read up on it in an interesting book about the subject. I am currently reading "The Discoverers", a highly recommended book (It's about the discovery of everything; the history of history, if you will).
    If we had been reading this book in school, I would have been at the head of the class.

    All the "mapper" thinking in the world doesn't prevent you from having to rediscover a fact that others already knew and you could have learned if only you had shut up and listened.

    Shutting up and listening is at the very core of the mapper thinking. I listen to everything someone has to say on a subject.
    I am interested in collecting facts, not having them forced down my throat.
    I went to college precicely because I noticed that my programming style was atrocious.
    I'd rather ask someone who knows (and ask questions to be sure they're worth their salt) than reinvent the wheel.
    In college, I met instructors who were mappers, and instructors who were packers.

    The mapper instructors had a genuine interest in what they were teaching. I was able to carry on a discussion about which caching scheme was good in which situation (we even discussed a "most recently used" substitution scheme - where the most recently used entry is flushed - which we knew was totally bogus, but was an intellectual experience nontheless. We even found cases where it outperformed the least recently used and least frequently used algorithm =).

    Then came the packers. In the packer classes, the students sat totally silent (usually sleeping) while the instructor droned on and on about this and that from his pre-made script, answering all questions with "I'll get back to you later, can we PLEASE continue the lesson?".

    Mappers do not substitute facts with their own thoughts. Quite the contrary actually. They hungrily take in a bunch of facts and then run with them until they've hit every permutation possible, then they come back for more.

    In order for a mapper to be happy, the class must be dynamic. There must be discussion (Within limits, of course. We only have an hour).
    The students must be allowed to suggest preposterous solutions which the instructor will run through to completion so that the student can come to the conclusion (and the teacher can verify that indeed it wouldn't work).
    Mappers need to be allowed to be wrong.
    I learn much more when I'm wrong than when I'm right.

    - The Wright brothers were NOT the first to fly a manned airplane.

    Right again. Still not sure what your point is...

    My point is that we are filled with these "facts" and no visible way to verify them (there are, of course, plenty of ways to someone who hasn't forgotten how to think mapper-style). It's always a great shock to find chinks in an armour you thought to be flawless.

    No, I think the only evil is the crushing of self-expression, the discouragement of child-like wonder, the disconnection of inference and imagination. It isn't memorization of dates. You are going to find through your life that people sometimes get the facts wrong; that some of the things you think are important to memorize turn out to be useless (to YOU); that things you beleieve turn out to be wrong. What matters then is your willingness to explore. That's what gets shot out.

    So we do agree after all! =)

    My point throughout this is that students are discouraged from exploring, questioning etc. We are just filled up with facts (both right and wrong) and sent on our way, as confused as when we arrived.
    Post-secondary education is different. You can usually learn something there.

    I can still remember going up to 100% students the day after an exam and asking them questions, only to find that they know nothing outside of the types of questions they studied for.
    These people would know all the factors leading up to the Russian revolution, and all the factors leading up to the French revolution (as prescribed in their books), but would be unable to compare the two.
    These are the people who "choose" the "correct" response to a question or situation.
    These are the people who love to regurgitate tired old cliches like "think outside the box" when subjects such as this one arise.
    These are the people who push for political correctness.
    These are the people who take on a cause, but can only give arguments based on the information pamphlet and whatever they heard someone else say.
    These are the people who participate in any given mass-hysteria that results in yet-another-stupid-law being passed.
    These are the people who know nothing outside of their TV (and don't care to either, since they went to school and got an education and are therefore smart).
    These are the people who say this-and-that war villain was sooo evil and country X was sooo right in killing him off, not realizing that country X put him into power in the first place!
    These are the people who hold a Judge Dredd-like attitude regarding rules, regulations, and policy.

    These are the people who drive me mad.
  • Perhaps I have not made myself clear on this subject.

    Do not think for a moment that I am creating this category to arbitrarily slam people into one camp or the other.

    This method of categorization is a tool used to express the current understanding on a subject (Much like the theory of the atom as it developped).

    I could very well be completely out to lunch but I'm convinced there is enough truth to what I am saying to make it a worthwhile intellectual endeavor.
    I am using terminology (mapper/packet) which has only been recently introduced, and as such is subject to many different interpretations, as we have seen during the progression of this discussion.
    There is, however, a certain behavior that has been observed that is pervasive throughout western culture, and perhaps even other cultures. I know for a fact that the Japanese exhibit this kind of behavior (though it's not so bad nowadays, unless you are filling in a form) to the point of draconian and pointless rules and procedures that must be met exactly - because I live there. There is a Japanese saying: The nail that sticks out is hit on the head.

    These kinds of behavior are being categorized by the author of the essay in an attempt to isolate to some degree the cause of this behavior and examine possible solutions to this problem.
    It's not expected to be an end-all. Nothing ever is. This theory will either be debunked or refined. This is the scientific method, not the gospel.
    Your reacting to my mulling these ideas over with statements such as:

    You willingness to dismissively throw a label on so many people you have never met, whom you know nothing about by observation, but only by assumption, and to suggest that all of the problems of the world are their fault (for obviously, you as a mapper are above any responsibility for the ills of the world) is the worst sort of uncritical and bigoted thinking, rooted, if you look deeply, not in any
    observation on your part, but rather on your prejudice, and, if you'll forgive me joining in, rather packerish.

    is showing that you are completely unwilling to consider my point of view without taking what I say and simply showing what the extreme of this line of thinking would produce, in order to debunk it.
    I could very well adopt the same argument strategy and say that you're suggesting that we completely ignore what ails our society and just give them a placebo and say everything will be fine in the morning.
    You can see how easy it is, (though this is an oversimplification, I know), and how I can simply put you on the defensive, thus avoiding the core of the discussion and any intelligent argument that could have happened.

    Surely you must realize that I was making a paper outline, not a concrete box when I was referring to packer / mapper thinking patterns.
    Surely you must realize that I am not suggesting an intellectual elite, a "Berlin Wall" separation between PACKER and MAPPER, with nothing in between. I'm not that stupid. You can't contain the human spirit that easily.

    What I was suggesting is that there is some validity to what the author had said: that people are mappers by nature, that we are taught packer thinking to excess in our current education system, and that people are missing their full potential (not to mention annoying others incessantly) as a result of it.
    Granted, there are many, many other factors involved here, but this is simply an attempt to model a spacific aspect of this and suggest a possible cause.

    I happen to find his reasonings very interesting, and I am inclined to agree with much of what he said because I have observed the same phenomena on countless occasions during my life and his arguments are logical based on the knowledge we currently have. If I am wrong, so be it. Give me arguments to the contrary, but PLEASE refrain from childish statements like "You're bigoted".


    As for Judge Dredd, it is a popular character from a cyberpunk magazine who is obsessed with the LAW. All citizens must follow the LAW to the letter.
    The movie made from this encapsulates his thinking like so:

    A guy comes back to the city after being in prison for hacking a computer. His block is currently engaged in block war with another block. He enters his apartment to find it full of gun-toting madmen who are shooting into the street.
    To make a long story short, he stays alive by hacking a food driod and hiding inside of it. Dredd finds him and then proceeds to judge him (He broke the law, and is now a repeat offender. Minimum 5 years).
    The dialog goes like this:

    Civillian: "I had to get out somehow! They were shooting at everyone!"
    Dredd: You could have used the window."
    Civillian: "What? on the 21's floor!? It'd be suicide!"
    Dredd: "Maybe, but it's legal."

  • 1) There seems to be a trend in this for broad over-generalization and labeling. Things in life never fit into tidy little packages, and writing should reflect that. In the second section of chapter 1, for example, the author claims that the state of programming as a whole is horrendous.

    I just can't agree with that belief. The book also labels people and idea's in a manner which is inconsistant with reality.


    You obviously haven't worked as a programmer for a big company.


    2) Secondly, I feel that the author has a pretentious, arrogant tone that makes me question the foundation from which the author is working. A bit of modesty, in my opionion, never hurts writing.


    Bullshit. Arrogance is usually a good sign of genius.

    The author knows what he is talking about.
    He may not be very eloquant, and he may not know how to structure an essay properly, but he knows his stuff.

    Stop looking at the surface.
  • Of course, this is by no means the one & final truth. Nothing like that is going to pop up soon.

    Attacking the writing style is useless, instead focus on the content.

    I do aggre that it is appears as if he implicitly partitions the whole world into mappers/packers. However, he doesn't - he points out that "packers" are just people who lost their "mapping" skills and need to rediscover them.

    And while it probably did not include too much really new information, he links it in some interesting ways. How much of it actually can be applied to your daily surroundings and if it helps you to improve your way of thinking is something only you can say for yourself.

    However, for myself, I found some good starting points for working on myself and improving my communication skills.
  • I'm unfamiliar with the reference to Feynman's story of the six lines on the STS SRBs. Can someone give a quick synopsis? Thanx.



    I can tell you the meaning of life,
  • Hopefully, though, after reading, they will turn away in discust. Sorry, I'm a libertarian/anarchist, but I'm not a fan.
  • Offtopic, but for the record...

    They landed 60 miles from the target under heavy air attack and walked across the island, taking their kit with them. The Argentinians (partly trained/ advised by the US military) were caught completely off balance. The British troops were colossally outnumbered and operating 8,000 miles from home. The won *very* convincingly through a combination of outstanding professionalism and creative thinking. In one battle (Goose Green) approx. 300 British troops took a fortified installation defended by 1,500 Argentinians.

    The Falklands War is widely acknowledged as one of the major triumphs of British Armed Forces in history.

    See the books "I Counted Them All Out And I Counted Them All Back" by Brian Hanrahan and "Don't Cry for me, Sergeant Major" (I'm too lazy to look up the author) for contemporary accounts.
  • Yes, "everyone knows that stepping back from a problem to see it in new light is often helpful". But the distinction being drawn is "do you know the words" or "do you practice the meaning".

    The author treats the distinction as a dichotomy, but it is a continuum, as stated in other articles here. Further, not only is the "mapper" ability continuous, but also it varies from domain to domain. e.g. I may be a mapper in software engineering, but am a packer in social situations. (But am aspiring to be a mapper there too!) ;)

    I also think that while his distinction is useful (because people can now develop techniques to improve your "mapping" ability) it is mislabeled.

    It seems to me that mapping ability is the ability for form abstractions. A "typical packer" only holds on to the barest of abstractions, while a "typical mapper" creates them continuously and deeply.

    Another different point. I've found that when I'm being shown how to do something by someone else, I often get frustrated when they try to describe it in "mapper" terminology. I want them to describe the barest steps, and let me develop my own "map" for it.

    I don't know quite where I'm going with this idea, but I think it's interesting. :P

  • It isn't the task itself which is so much "mapping" or "packing" but it's the "why" you do the things you do that can be described as "mapping" or "packing". Do you follow your methodology because you were told to do it that way, or have you tried a bunch of techniques, some of which you may have been told, and developed something that works, and you know _why_ it works.

    I think the "mapping" "packing" distinction is at a higher level than you are describing it as...

    But, that's just my opinion. ;)

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

    So what you're saying is, there are two kinds of people in the world, those who believe there are two kinds of people in the world and those who don't. Oh Wait. :-)
  • I'd have to agree with what many others have posted, that this strict packer/mapper dichomotomy is presented far too rigidly, dogmatically and arrogantly. But there is something in it - it's more like a continuum.

    Well, at least they're asking the right questions (which, as they would say, is a key feature of the mapper mentality! :-). It would be fascinating and enormously socially useful, to discover why some programmers are many times more effective than others, how we can avoid the catastrophic failure rates, etc.

    My two cents - yes, he's spot on in that the education systems we have (and Japan's is the epitome of this, despite its work cultures) are ridiculously rigid, out-of-touch and inappropriate for creative or partly creative activities like programming. But having the right development tools and machines and OSs etc. which don't crash all the time etc. etc. make an enormous difference. I sometimes spend hours hunting down a piece of debuggin info when if only I had the right tools I could get it in a few minutes, AND have a dynamically updated view of the data. Cross-platform abilities have the potentional to cut costs enormously (yes, can you tell I'm a Java evangelist already? ;-)

    And of course, there's that well-known statistic which STILL isn't really widely appreciated and put into practice: Mistakes cost ten times more to fix at analyis than requirements, ten times more at design than analysis, etc. etc. all the way down the line so that a bug fixed after product has shipped is thousands of times more expensive (sorry if I'm using outdated terms here - but that's my school's fault!). Mundane but true. And big names like Siemens, Bull, MS still haven't latched on to this.

    So sue me! It's true!

    Actually, the reality is more complex. Often they (MS especially) ignore problems, even horrendous ones that cause users to tear their hair out, because they know they can get away with it.

    Anyway, the commentary here on /. is unusually brilliant. A fascinating topic which has brought up some very diverse and thought-provoking . This is where /. really shines! :)

  • Recently a friend turned me on to Christopher Alexander's "Timeless Way of Building" [amazon.com]. If you liked "The Programmers' Stone" I suggest you take a look at it.
  • I'm not certain about the "six lines" exactly, but Feynman was the person who discovered exactly why the O-rings on the Shuttle (STS) solid rocket boosters (SRBs) weren't doing their thing during the Challenger explosion.

  • At what point am I going to stop just reading about the culture and the people (else) and all the neat toys and actually become a geek myself?

    Well, you're thinking about it the wrong way. While University will get you credentials, you've got to do things...on your own. I for example, started delving in to the bowels of computers when I was 14.
    How to become a geek in 6 easy steps:
    1. Get yourself a cheap computer.
    2. Install Linux w/ EGCS and kernel.
    3. Look at the kernel.
    4. Change something that looks interesting.
    5. Re-install your now broken Linux kernel.
    6. Repeat as necesary.

    Of course I'm oversimplifying here, but what I'm trying to say is that there is a point where planning ceases to become useful and turns into stalling. The ultimate objective here is that learning becomes effortless. You're no longer learning but doing something which happens to get assimilated into your "map"(to borrow the terminology in the essay). Don't learn so you can program...program so you can learn. Okay...I'm getting trite now, so I'm going to leave.
  • the fact that these questions / statements are being made. One can only hope that various managers actually read this all the way through - I sent it to mine after I read the whole thing.
    As a poster noted, the whole dichotomy was related in absolute terms, but perhaps it was written that way so **packers could read and understand it**.
    In reality we are a complex mixture of these two extremes - and spread across the spectrum of possibilities. That's why we need different programmers / software engineers for different tasks. An uber-mapper is not going to be particularly happy maintaining a piece of code where there is no chance at innovating within it, just as someone less a mapper might happily take that as one of their tasks.
    Anyway, it was an interesting read, and clarifies at least two of the psychological profiles that might be important when looking for those software ( and hardware for that matter ) people to make a difference.

    One poster noted that some sentences were hard to parse. It was written in English ( contrasted to American ) college style ;-)

    Unix is user friendly. It's just very particular about who it's friends are.
  • It's not hard to be convinced, I see, by a writer who tells us that we're smart (or gifted, or whatever). Most movements, philosophical, political, or religious, gain and retain membership by this very trait.

    Still, he doesn't go into great depths to explain why some people hecome "packers" and some "mappers". There's a lot of new-agey claptrap as well - that the modern man is essentially brilliant, but the strictures of (western) civilization have dulled his brain.

    In doing so, he neglects the main question: if there are packers and mappers, and a real difference between the learning processes of the two, then why the different outcomes given an essentially identical education and upbringing?

    It's interesting and I'm sure it's easy to buy, but it's harder to believe when put to a decent critical read.

    --
  • This is the kind of writing that makes for wonderfull 'How to Be a Success' books. But it needs work to be anything more.

    Scientific method exists for a reason. Coming up with labels and dogma are one thing but it doesn't really mean anything unless you can prove what you are saying is true.

    You need a explicit definition of what a Mapper/Packer is. You need to categeorize the people with the labels Before you examine how ther react in a particular situation.

    Retroactive labeling is infallible and consequently useless.

    The claim is that Mapping/Packing is developed through environmental pressures. There should be a statistical correlation between certain environments and mapping/packing

    If there are things that can change their Mapping/Packing status then it should be repeatable in experimental conditions.

    To fill their goals they need

    a Mapper Index (with test)
    Experiments to Show performance/index correlations.
    Experiments to show techniques to change the index
    Consistant correlations between induced index changes and performance.
  • Stop worrying - you've got the mindset right, the rest will follow.
    You're showing a clear understanding that there's more to it than studying facts at U. and are willing to investigate. So, go ahead, and just try to do things that appear to be fun. You'll find yourself a 'geek' soon enough if you ruthlessly follow up on this feeling.. :-)

    -John
  • Part 2 has nothing to do with programming at all. It has to do with that so called autism that allows people to dig deeper and therefore have trouble speaking with those permanently glued to the surface of all things. It has to do with being able to take information from one course of study and relate it to something else. Most surface dwellers (packers) understand by recognizing and identifying previous concepts not by analysis which leads to the knowledge that everything is pretty much the same at the core it's just a matter of knowing where to put new information. Now about that research regarding the visual performance of employees wearing tight neckwear. I think that needs to be forwarded to PHBs.
  • I don't mean this is a flame. I've seen this
    happen a number of times, but I can't imagine
    how. It seems that to reply to the wrong topic,
    you would have to go back to the main page,
    click on some other topic, and click "reply to
    this" there. That seems like too elaborate a
    sequence to be pure accident.

    Is there some more flattened out way to access
    the stuff on slashdot?

    Alex.
  • I made a text version by munging the output from
    lynx -dump. I could pass it on if you like.

    Alex.
  • I've just read the first chapter, but he just about nailed a problem that's been bugging me for a long time. I've long asserted that our lower school system is a mediocrity machine and that you don't really start learning anything particularly useful until you get to college. I've also said that most of what you learn in the lower school system is trivia and they only start to teach you to think in the universities. I myself was classified as a "slow" student in school because I would lose interest in things that bored me. I proved to do much better in advanced classes when my parents put their foot down on the issue. Most of what put me into the "slow" classification seem to fall under the mapping activities referenced in the first chapter. Imagine that.

    I've never seent the issue so clearly enumerated before. This article is a definite keeper and should be required reading for anyone in the educational sector.

  • I think that it's excellent that hackers and programmers are getting the proper distinctions. It's important that this happens so that people won't get the wrong ideas.
    Brad Johnson
    Advisory Editor
  • Could you repeat that, I wasn't listening...
  • The discussion is remarkably good. It's nice to not see a bunch of comments on how college curriculum should be more focussed around teaching students "programming" (i.e. syntax) as opposed to theory. The usual "pascal is dead and everyone should learn C so you can get a good job after college." This paper addresses a lot of the teaching methods of computer programming (and teaching in general). The whole idea of "knowledge packets" being passed to these empty vessels (students) waiting to be filled by the all knowing master (teachers) is inane. I think this is an excellent paper as it addresses a lot of the ideas in progressive education and a problematic assumption in, at least the US, about education. For instance learning a computer language isn't overly significant in college, learning how to learn a computer language and how to use think through problems is the whole point. If you can think and learn it doesn't matter what language you know, or what experience you have, you can do anything. Too often it seems like people are into programming to hop on the gravy train and get the bucks when deep down they don't love it. These are the people who are "packers." No passion, no soul just dollar signs in their eyes. Cubicle monkeys. They're the ones who hop on the management track as fast as possible and hopefully disappear from my life. Currently I'm in an excellent engineering team, small company, cool technology. But I just left Lucent and man that was a living hell. Cubicle monkey central. gid-foo
  • That is why I've found that people who go to technical schools/institutes or places like DeVry more often than not don't know how to 'properly solve' a programming problem. They learned C++ or Java or whatever the lanaguage of the day is (cause their courses are geared towards industry?) and figure it's the solution for everything.
  • The "single handedly designs, develops, integrates, and maintains a work of art" is a dead giveaway for a primadonna.

    Also, referring to oneself as "the important programmer" is quite a 2x4-upside-the-head hint.

    "Getting the job done" suggests and end-state, where "developer" implies an Ivory Tower. I tried to label myself "Applied, Practical Programmer" once, to embody the "no BS; lets make this work quickly" attitude... but I ended up sounding like a primadonna.

    The "mental model" used for debugging is common to all non-clueless programmers. Nobody sifts thru the code after being told of a bug; their eyes roll to gaze at their forehead while the work the problem backwards.

    The basic problem with a primadonna is: there are few useful tasks (beyond "hello whirled") that can be designed, coded, integrated and maintained by one person. Any useful application of substance requires a team and teamwork; which is alien to the premadonna.

    They're good for firmware writing, since that's usually a small piece of code with well defined boundaries and interfaces.

    Don't get mad at me for the label; I've been a premadonna too (I've caught myself twice in the last week alone!)

    Chris
  • . . . the story of my life.

    Don't let too many years go by before you decide to move.

    "The number of suckers born each minute doubles every 18 months."
  • The guy is obviously a goddam packer, and not one of us fine mappers who can spot concurrency problems from a mile away. :)

    Here is what I would have done with the original code: short of replacing the mutex with a critical section, I would eliminate the case in which the mutex is tested for abandonment. The logic of the system should guarantee that mutex abandonment doesn't take place. It can only happen if you have threads that mysteriously terminate when they should not, like in the middle of holding a critical lock. When that happens, your software is screwed; you might as well dereference a null pointer and call it a day. So these error checks are a complete waste of time and indicate a strong packer mentality---``I don't know what the hell is going on in this software, or what the relationship is between this function and the rest of the system, so I will guard myself against every possiblity, real or imagined.'' It would be better to inspect all of the critical regions of code protected by that mutex and verify that all of them properly release the lock, and do not terminate the thread in the middle.
  • And yet your original mispost got moderated as 'insightful' whereas your followup was what was 'offtopic.' Huh.
    ---
    "'Is not a quine' is not a quine" is a quine.
  • After reading Chapter 1, I forwarded it to my (packer) business partner as Required Reading. This is a really good explanation of why we (mappers) have such a hard time communicating with those who aren't like us.

    For many years I have summed up my philosophy as: "Challenge the Default Assumption", and applied this principle in every domain. It seems like a reasonably good technique for ensuring that new experiences and techniques get mapped instead of merely packed.

  • (Hopefully this isn't redundant..)

    The "Packers" vs. "Mappers" distinction looks a lot like the Sensing vs. iNtuiting distiction in the Myers-Briggs Type Indicator and it's ilk.

    See http://www.keirsey.com [keirsey.com] for an online MBTI clone, or http://www.skepdic.com/myersb.html [skepdic.com] for a more skeptical look at MBTI.
  • You've completely missed the point.
    We have this knowledge of the "nitty gritty" details because we find them interesting.

    I don't think I did. You find them interesting because you learned enough of them for your innate ability to think (to "map" as these folks put it) began to get interested in acquiring facts because you began to see a "map." I'm suggesting that "mapping" emerges naturally from sufficient observation of "facts." The problems come when people confuse information and judgement. When one becomes bigoted about facts. When one comes to accept facts not because they are observed, but because they are believed. This is the difference between knowledge and faith, and the application of judgement based on observation rather than belief is the difference between wisdom and dogma.


    No, the acquisition of knowledge is learning, a new discovery, a source of exhiliration.

    Having useless facts rammed down your throats by clueless teachers in the cesspit we like to call public education is drudgery.


    There is no substitute for study, for the exercise of memory. There is no subsitute for rote learning when it comes to the acquisition of "facts." Facts become the arsenal for the expression of "thought," which is the higher synthesis of information, the only truly human act.

    It will if you are capable of mapper thinking.
    Ever heard of tech manuals?
    A mapper is not daunted by lack of knowledge.
    A packer is limited by lack of thinking.

    What does that mean? I have never met anyone incapable of mapper thinking. My point was that learning facts is a straightforward application of self-discipline -- that learning the facts is required in order to think, and that "mapper thinking" doesn't contribute to this process. In fact, I am arguing that mapper think emerges from having a large and wide-ranging body of knowledge. This notion that "mappers" are some sort of intellectual elite, above mere fact, is, in the literal meaning of the word, poppycock. I completely agree that mapper thinking exists. I just think it arises from a combination of wide knowledge AND self-confidence that one's thoughts are worthy of expression.

    What I think public education does wrong is NOT the rote teaching of facts, but rather the ongoing process of humiliating children into thinking that their thoughts, their creativity has no value. What schools (painted with an overbroad brush) do wrong is that they criticize children when they have an insight, a flash of original thought, and they get shot down because that thought happens to be contradicted by a fact they didn't know about. That discourages the child from ever exressing another insight because they might be "wrong."

    Feynman? Whatever. Feynman's DAD on the other hand is a miracle. Feynman's dad would not say, "No, that's wrong." instead he would say, "Interesting idea. I wonder how we can test that?" Feynman being a genius was inevitable after that.

    No, the problem is that they teach you WHAT to think instead of HOW to think (packer vs mapper, anyone?).

    Everyone knows how to think. What schools do is to shut down the desire to think. Big difference.


    There is a BIG difference between how the function code pins work on the m68000 CPU and the dates that each explorer came to the americas (Can you believe that in grade 9 I had to memorize this shit in order to pass the course?)

    Yes, I can. And I think there's nothing wrong with that. I'm not sure why you think there is. You never know when those facts may become integral to a much more sophisticated thought. No datum is without value.

    I have never taken a computer course in my life and I now make my living writing computer software. I'll tell you this, though. While I am often a much more innovative programmer than those I have worked with, I had a lot to learn to learn from those people with their "useless" education. I had to learn a lot of engineering principles. I learned a lot about program stability, testing, completeness, and development process from those people. They have a lot of useful, practical knowledge that would otherwise only have come to be by my continuous process of Innovation by Spectacular Public Failure (I'm thinking about getting a patent). All the "mapper" thinking in the world doesn't prevent you from having to rediscover a fact that others already knew and you could have learned if only you had shut up and listened. Creative thinking is great, but no matter the subject, there is definitely somebody out there who knows something about it that you don't.


    - Thomas Edison did NOT invent the lightbulb.


    I never thought or said he did. He did make a commercial success of it, however, and by a very Microsoft like marketing practice made himself into the "lonely genius inventor," (like claiming to be a "mapper," perhaps?), never mind the 80 engineers working for him who actually ran all the tests and did all the experiements. Still not sure what your point is...


    - The Wright brothers were NOT the first to fly a manned airplane.

    Right again. Still not sure what your point is...


    - Columbus did NOT discover America.


    Nope. Instead he made the greatest face-saving PR move in history. I think it's fair to say America had already been discovered. By the Native Americans, at the very least.

    - "Honest" Abe Lincoln, your favorite president, was very much in favor of the slave trade.


    Not so. This is a gross misunderstanding of Lincoln's position. He was a politician. And while he was personally opposed to slavery and the slave trade, he had to be elected. The slave trade was a northern economic concern. There was no way for a political animal to take it on directly. He also was overwhelmingly concerned with the preservation of the Union, and as such he backed away from policies that could have been perceived as abolitionist. BTW, there was very little import of slaves by the mid-nineteenth century. Most southern plantations were "breeding" their own. In fact, the Confederate Constitution outlawed the slave trade as a nod to British opposition, and in hopes of encouraging them to recognize the Confederacy. It is one of the more seemingly incongruous elements of the Civil War period.

    BTW, I learned much of this in school (I was a history major) and I read a lot of it in books. Didn't "map" any of it.

    No, I think the only evil is the crushing of self-expression, the discouragement of child-like wonder, the disconnection of inference and imagination. It isn't memorization of dates. You are going to find through your life that people sometimes get the facts wrong; that some of the things you think are important to memorize turn out to be useless (to YOU); that things you beleieve turn out to be wrong. What matters then is your willingness to explore. That's what gets shot out.



  • Yes, I think we do agree. What I think rankles me is the high-handedness of anyone who believes he belongs entirely to one camp and is therefore able to label others as belonging entirely in the other camp. My observation of human behavior doesn't bear this out. Everyone is capable of, and at times requires both kinds of thinking.

    This tendency to observe something as obviously multivariate as human learning, and then to arbitarily create a handful of categories and then slam people into them (as if there were only that many kinds of people) is intellectually (and aesthetically) repellent to me. I also notice that people who categorize in this way tend to create a category with attributes they value and admire and another category with traits they dislike and revile, and then they firmply place themselves in the first category. All of these "models" of behavior seem to me to be self-serving. They seem to be a way for the creators of the model to feel good about themselves. While that's very nice, and more power to them, do not expect me to adopt their labels and say, "thank you very much. I will be so much happer knowing I am a 'type X!'. Obviously THIS is what has been holding me back all of these years!"

    It is such a gross oversimplification of a complex phenomenon that it cannot help but be inaccurate.

    I'm not saying generalizations are without value. If we could only talk about human behavior at the level of indivduals, we would never find patterns (in fact, we would never develop a vocabulary for it). In some cases it is the vagueness, in some cases it is the self serving quality.

    I do not see a big difference between someone saying, "I am a mapper," and someone else saying "I am a Capricorn." They are both saying equally vague and meaningless things about themselves.

    You willingness to dismissively throw a label on so many people you have never met, whom you know nothing about by observation, but only by assumption, and to suggest that all of the problems of the world are their fault (for obviously, you as a mapper are above any responsibility for the ills of the world) is the worst sort of uncritical and bigoted thinking, rooted, if you look deeply, not in any observation on your part, but rather on your prejudice, and, if you'll forgive me joining in, rather packerish.

    Please forgive me for the tone. I am not trying to single you out personally, because I am in general agreement about the nature of open-mindednees and free-thinking. It's just that I am always suspicous of anyone who is so freely claiming to be an open-minded free-thinker. I have found this is usually an unexamined belief. I happen to feel your conclusions about the deficiences of a significant portion of the human race whom, I am fairly certain, you have never met tends to bear out my conclusions.

    I cannot comment on Judge Dredd. I know nothing about it.
  • I don't wish to belabor the point. I can assure that nothing you have said puts me on the defensive. Perhaps I infer to too much from your writing style. If you go back and read your statements, they appear rather absolute.

    I'm sorry, but to find fault with the behavior of others and to reduce their whole humanity to a label, whether it be "packer" or any other label is the definition of bigoted. Again, perhaps this is me drawing overbroad conclusions from your style of rhetoric. I apologize if that is so. Even so, while you may not be guilty of these tendencies I expression concern about, the ability to use ideas like this one (and like DiSC, or like Strong-Campbell, or like any of a host of other psychological categorization systems) to segregate and create identities can be terribly abused. I am urging caution.

    The reason I have invested so much effort in striking the flanks of these ideas is because they are compelling. The seem holistic, and they appear to match experience. I think there very much is something of value here. I am merely suggesting that the ideas are vague, overbroad, and incomplete. I do not for moment think they should be dismissed or suppressed; merely examined closely.

    I am very willing to entertain your point of view. I entertained it very thoroughly and considered with much reflection before I committed my concerns to "paper."

    The one phrase in your most recent reply that causes me deep concern is "...people are missing their full potential (not to mention annoying others incessantly) as a result..." People who don't think like you do are annoying and those people are packers?

    I am not a literal-minded automata, I am merely concerned because I think many people can (and will) take these ideas not as an agenda for self-improvement, but as assurance of self-superiority, and a way to dismiss the opinions and thoughts of people whose way of thinking they find annoying.

    I am not a robot, I am not a genius (I think genius does not exist, actually -- it is merely full engagement of the human mind, much as I think you believe as well), I am human being with the full mix of intellect and prejudice, of reason and emotion, of calm and rage. So are you. So is everyone who annoys you. I simply mistrust that urge in me that suggests I see clearly where others do not. There are real differences in ability, but this does not necessarily correspond to social value.

    Please understand, I believe that you want to put these ideas out not to show the superiority of people who are "mappers," but rather because you believe that these ideas might help to liberate the thinking of people who haven't thought that way for some time because of social forces that discourage it. I believe your evangel to be one of liberation. I truly do. It is just that ideas like this can "tribalize" (if you'll fogive the disgusting neologism) and that does real harm.

    I try to live my life by a rather classless little cliche: "If one person tells you that you have a tail, you can laugh and tell them to go to hell. If two people tell you that you have a tail, it is time to check your ass."

    I am merely asking you to check your backside.
  • And of course that should be "express," not "expression" in the second paragraph. Ah, Preview, where is thy sting? ;-)
  • The essay is so heavily slanted towards the opinion that "mappers" are good and "packers" are bad that you can't help but put yourself on the side of the mappers, simply to avoid putting yourself into the PHB, packer mold.

    But to say that people are either one or the other, mapper or packer, is ludicrous. Everyone has pattern matching skills, everyone tries to fit problems into domains they know, and everyone knows that stepping back from a problem to see it in new light is often helpful.

    That some people are better at seeing patterns than others is not shocking news. Nor is it news that some people doggedly try stupid things until one of them works. But, a person who tries all fifteen keys on his key ring before finally opening his own front door might just be a fantastic improvisational musician (improvisation being much more ephemeral, non-analytical and dependent on "mapping" than programming).

    There were some good and interesting points in the essay. But the distinction between mappers and packers just doesn't hold up.
  • Well, Richard Feynman was involved in the investigation after the Challenger disaster. Someone who knew him as a friend asked for his opinion---which spiralled into Feynman sort of joining the investigation and uncovering some key evidence.

    I couldn't say for sure what "six lines" means. Maybe the seven separate segments that form the SRB? Beleive it or not, here I am at NASA and we haven't even got a picture of an SRB handy. The irony!

    quickie definitions for the acronym impaired--
    SRB = solid rocket booster
    STS = space transportation system (the shuttle)

    Offtopic: Saw a diagram the other day with an object labelled `RMS handle'. No, don't get your hopes up that's Stallman's going into space. It only meant `remote manipulator system';)

    This would probably be a good place to disclaim my opinions as my own and not those of any employers or agencies. Blah.
  • >Anyone else has the impression that programming courses are made up for those who don't grasp the concept of programming?

    Yes, that would be the point - they're in the class to learn it. :)

    However, too many people go in there and never quite 'get' programming, on a gut level. I totally agree with that. I've seen the sorry results of it - clueless people who produce horrid code, and don't understand *why* it's horrid.

    Not that I'm perfect, but the other developers in my group don't groan *too* loud when they see my code. :)
  • I obviously don't have time to read it all in one sitting, but it looks very promising from skimming through it

    I just have read it all the way through (it took about 4 hours), and it really is as good as it looks.

    The biggest thing I got from this is a word to describe myself. I am a Mapper (so are you, probably).

    One note, for anyone who makes it to the brief discussion of the Prisoner's Dilemma at the end. Go and read The Origins of Virtue [amazon.com] by Matt Ridley. It covers this situation and the more general problem of co-operation in an egotistical world. It starts at the level of chromosomes (there is such a thing as a parasite chromosome) and goes up the levels to society, subcultures and the whole world. Its definitely the work of a Mapper.

    Paul.

  • In fairness to NASA, bear in mind the following poinsts: People's lives depended on doing this stuff right. Ad-hockery in safety contexts has caused quite a lot of accidents in the past. Hence requiring the technicians to follow the procedure was the Right Thing. It probably did work out cheaper for NASA to employ these technicians to count around hundreds of little holes all the time than to verify the safety of the change (what type of paint? would it react with the fuel?) and reprint all the procedure manuals to accomodate it. A much bigger problem with the mindset was the quote "a 4kHz oscillation is in our database". This turned out to mean "we have a major vibration problem with the engine, but the management don't want to know about it". Paul.
  • 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.

    The thing about being a mapper is that once the map of the processor is established, details like the state of the interrupt enable flag become obvious. You don't have to learn them, you just deduce them from the map.

    I recall an incident where my wife was revising for an exam. She had written half a dozen equations down and was trying to learn them. I glanced at the sheet and said "Why bother learning all those? You only need these two simple ones and you can derive the rest". It summed up the difference very clearly.

    Paul.

  • To me programming is really pattern matching - you translate the requirements into a high level abstraction, then morph/manipulate that abstraction until it fits the form (a meta-pattern) of an interconnected set of previously encountered/implemented forms. In other words, you find the solution rather than solve the problem. It's much easier that way!
  • 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.
    I would have most likely been diagnosed with ADD, had I been born later than I was. Since I first heard of ADD, it scared me... "Let's pump these children full of drugs, since we can't control thm..." Yet if that was done to me... shiver

    I have found the concept of packers and mappers to be very true in my experience, though not in those terms. I have always seen people as "button pushers" and "problem solvers". I have met many people that seem to beleive that the only way to solve a problem is a procedure. "If the green light goes on press the red button." If you try to explain what the green light means and what the red button does to fix it, they will listen, and probably retain much of this (I have found many button pushers/packers take tons of notes...), but if one day the red button doesn't work, they will be completely lost as to how to solve the problem, no matter how trivial the solution is.

    Yet, I have also noticed that many people do have "mapper" abilities, but only in certain areas. For example, my mother could easily cope with missing an ingredient in a recipe, mapping all here knowledge of cooking to come up with an alternative, understanding everything involved. But if presented with a new task on the computer, she will not even try explorering the menus, or the help system. She will look imediately to me for a procedure.

    It is probably related to the way people learn a subject that determines how the act in regards to that subject. If you learn something almost entirely on your own, you will be essentially forced to "map" while if it is taught to you by others, you will likely only "map" if that is your dominate mode of thinking. In other words, you will learn in the manner you learned to learn. You will solve problems in the manner you learned to solve them. If you are inclined toward "packing", you will default to it. If you are inclined toward "mapping", you will default to it.

    I consider myself in that group which "packers" don't understand. I have worked with to many people of the "button pusher"/"packer" midset to dismiss the existance of this distinction in thought models. I would not go so far as to say that they a disjoint, far from it, but I will express the little bit of arrogance that most "mappers" likely share: Society would be better off if we taught our children to be "mappers", and if we aspired to lift our friends, coworkers and love ones out of the "packer" mentality.
  • Those who divide people into two kinds and those who don't.

    Seriously, though, I think programming is more than mere 'mapping' vs. 'packing'. I'm a database programmer from way back, and one of the first things I do is identify all the data elements in the problem domain at hand (this would be the perjorative 'packing' as I understand it). Yet, having done this, it's much faster then to proceed with the mapping phase: identifying relationships, constraints, business procedures, UI elements, etc. As you go, you enhance your data model and validate your mappings against elements of the data model. Is this so strange?

    It's almost like the dichotomy between top-down and bottom-up design. It's best not to do one or the other, but to approach a design from both ends (and the middle!). Any piece of hard-won knowledge about the problem domain that you come across has a place, even if its mapping isn't readily apparent... don't lose it!
  • The packer/mapper concepts look _a lot_ like concepts in Objectivism, only not as well developed. Ayn Rand talks about (and all of her villians in her fiction were instances of) concrete bound mentalities, these are clearly packers. The mapping concept is a primitive form of AR's theories on concept formation. Anyone who feels the mapper/packer concepts are like a flash of light in a dark room should probably go look into Objectivism for a far more developed theory.

    -- Eric
  • I obviously don't have time to read it all in one sitting, but it looks very promising from skimming through it. It seems like it's a very intelligent treatment of programming; at long last, perhaps, a sort of formalism for hacking, as opposed to structured, counterintuitive programming that seems to be the norm in programming classes. (Anyone else has the impression that programming courses are made up for those who don't grasp the concept of programming?)

    "There is no surer way to ruin a good discussion than to contaminate it with the facts."

  • I went through it quickly, until I hit the part (on the second page, I think) where they prettify some Win32 code from a book. I was delighted by their choice of brace style, and joyed by their slamming of the (IMO) awful Hungarian style, but then it hit me: they use parenthesis on their return statements! I never did understand why some people think return should have function calling-like syntax. Er, not until I looked it up in the C FAQ [faqs.org], question 20.19, that is. Hint: historical reasons. But anyway, yuck! :)

    OnOntopic: It did seem like a very good read, with lots of interesting ideas. It's nice to see ESR doesn't have a monopoly on this kind of material.
  • ...kind of like mine! I really like his concepts, although, coming from a similar point of view, I think that he is trying to apologize for his way of thinking and behaving--much like mine--using a new set of terms he creates. I used to call the dichotomy worker-bees and hackers. I remember getting punished for reading ahead in the book, or even reading a genetic engineering book in 9th grade biology. It is certain that the education system of today rewards his 'packing' behavior, and at best compartmentalizes--gifted and talented--the 'mapping' activities to avoid contamination. I do like his approach though.

  • Hello everybody,

    First - apologies for the extreme length of this mail - I'm not really acquainted with what is acceptable by Slashdot norms, and I have no webspace to put this rant on to link to, so please bear with me.

    This mail has several purpose. One, to point to further material that Alan produced, because many new ideas evolved, and were written down. If you liked the Stone, you might like the rest as well. Second, to answer a few of the criticisms, comments etc. that popped up in the thread.

    I'll introduce myself first. I have been acquainted with Alan Carter, half of the duo that produced the Programmers' Stone (I'm pretty sure he wrote the entire thing), for more than a year now (although I only recently met him 'live'. When introduced to his writings by a mutual friend, I fully experienced the a-ha erlebnis some of you will have experienced as well. The phenomenological side of the mapper description fit my situation extremely well, and solved quite a few conundrums that had been puzzling me.

    I immediately resolved to contact him, and we started to collaborate. One of the immediate results was an e-mail discussion group, consisting of some of his friends (amongst whom figured Bill Allsopp, the guy who works a lot with ADHD children - he was mentioned in one of the thread messages), and some of mine. Most people were generally quite like-minded (they could all be categorised as mappers in various degrees), but still there were some differences. Differences, mainly in attitude and drive, that later caused the group to break up, but not before having produced tons of reflections, ideas etc. The most important idea to come out of this resulted in the M0 paper.

    Building on the M0 idea, Alan produced a series of 6 papers, delving further and further into life, the universe and everything. The M0 paper and some other stuff is available on the Web (http://www.melloworld.com/Reciprocality - watch out, the URL is case sensitive ! - and they're sometimes unreachable anyway), but I can mail you the six central, current papers on demand (//mailto:parickx@janbe.jnj.com).

    All of this is experimental stuff - some newer ideas I discussed with Alan when meeting him have not been incorporated, and the whole thing is an outline, and would need quite some work - you have been warned.

    OK, now for some comments on what has been said in this thread.

    * Packers/mappers : a continuum ?

    Yes. It always is easier to just go ahead and state everything in black and white. That is indeed what Alan has done in the Programmer's Stone. The text itself does need refining on that point. At one point Alan drew up the 'Matrix of Doom' which was already a much more elaborate categorisation. It never got discussed much further, and probably could do with more refining.

    Personally I very much believe there's a continuity. I also don't think they're necessarily a good categorisation of the universe. Essentially, the human psyche is not linearly separable (my opinion). If one could classify or describe the mind as a multi-dimensional space (say n dimensions) (like MBTI does - they have four dimensions n=4) with each two values, at the simplest level), linear separability would mean you could categorise different classes by drawing a set of n-1 dimensional structures (hyperplane I think the correct term is) that separate the different classes.

    To simplify the math-speak, picture a two-dimensional space. In this space, a hyperplane is one-dimensional - a straight line. Linear separability of a set of points means you can draw a line or a set of lines in a way that you get different delimited areas each containing one category. In a one-dimensional space it's even easier : linear separability means you can mark a number of delimiting points, and each category should entirely be between two delimiters, and between each set of two points there should be at most one category.

    Placing all human psyches on one single line, and saying you can divide them up with one marking point, is to my mind pure folly (although many people tried over and over again). It amounts to ignoring the complexity of reality (but people are extremely good at ignoring reality, not in the least those who call themselves philosophers).

    Still, some approximations can be made succesfully. I believe Alan and Colston at the very least succesfully identified and described some subgroups of humans. The members of the 'mapper' cluster identified all experience the a-ha erlebnis when reading the paper (I'll get to the relation with MBTI in another paragraph).

    Packing is a very real phenomenon as well. Only, one should not jump to conclusions and say "one is good, one is bad". Both clusters differ mainly by having adopted through the ages a different cognitive strategy (or by having a genetical preference for one strategy - I'm not committing myself here, and I actually believe the truth is in the middle somewhere). The strategy is partly communicated from generation to generation by culture - I believe this could be demonstrated.

    These cognitive strategies could be viewed as different evolutionary strains (whether sociological/psychological or genetical again I do not presume to decide upon). And much as elephants, giraffes, tapeworms, rattlesnakes etc. have evolved from the same beginnings, several strains could have evolved in humankind, of which mapping and packing could be major strains (with lots of subspecies maybe). Is an elephant better or worse than a giraffe ? Or than a rattlesnake ? This probably mainly depends on where you are in the foodchain - but you seen the point : a priori there's no reason to believe one is 'better' than the other. The same mindset should be adopted when approaching the packer/mapper categorisation.

    Alan firmly believes however packers have done very bad things. He has ample reason to think so, partly because of his personal background. One of the things packers I think have brought into the world is the ubiquitous guilt and blame mechanism, which is a rudimentary form of social control, and which has grown into a cancer. People working at big corporations know what I'm talking about : blame is almost ritually shifted around until it hits a victim that cannot defend itself.

    This is done because nobody wants to take responsibility : if I see a problem coming up in somebody else's project, will I tell them ? Nope, because if I tell them I will become the problem to them. Compare this to Feynmanns account in 'Surely you're joking mr Feynmann' about the safes at Los Alamos. To demonstrate security was inadequate, he started figuring out how the safes could be cracked - an it turned out that it was relatively easy. Even before he could do this, he was telling everybody security was inadequate. When word got round he could crack the safes, people started keeping him (and nobody else!) out of their offices - he had become the problem. This superficial kind of reaction is typical of packers - they have problems seeing the 'deep structure', the 'real problem', and only detect the superficial symptomatic problem - Feynmann could get into their safes (whey they exhibit this peculiar problem - more on that later).

    These are bad problems, ubiquitous in society as we know it. Mappers probably suffer from other problems, but being a minority (more on that later), they never pervaded society. And nobody knows what a mapper-dominated society is like, because it doesn't exist now. It might have existed (Alan thinks it was the original state) but I don't think so. I think an evolutionary picture, with different strains springing up real soon, is probably more accurate. And it is great for avoiding the moral crudader-trap of dividing everything up into good and bad (I've been working on a theory of social-psychological fundamentals myself, shameless plug, and I think I'm on to something, but it has yet to be linked into Reciprocality. It does give a basis for a new morality, not founded on any funny dogmas... ask me about it if you're intrigued...).

    So - packers aren't any badder than mappers - but there's a lot more of them, and mappers tend to suffer badly from some of the mechanisms they brough into being, which leads me nicely into my next topic...

    * The invisible persecution of mappers

    I'll dig up the bible here. I'm not at all religious, but I'm going to demonstrate even the old Jews knew about packers and mappers. I specifically refer to the person of Joseph, who was sold into slavery by his parents, because he was always daydreaming - a typical mapper symptom. In Egypt, whilst in prison, he interpreted a few of the pharaoh's dreams, thus predicting a few things succesfully. He was released, and eventually made it to Pharaoh himself if I remember correctly, and saving Egypt from a bad famine in the process.

    I would like to advance the hypothesis that Joseph was an archetypical mapper, cast out by his family because they were a bunch of farmers, for whom the packer cognitive strategy was more than adequate. By accident, Joseph had the chance to prove himself to the Pharaoh of Egypt by doing a bit of highly intuitive pattern-recognition, and did a lot of good, in a management position.

    Go read the story, this is only a rough outline. The important bit I wanted to discuss here is the casting out bit. I put it to you that in our society, there is an invisible minority of dreamers that is being persecuted. Worst thing is : they don't even know it themselves (one, that there are others like them around, and two, that they're being persecuted). Only a few days ago, I got to know a girl described by her co-workers as being from another planet. I have talked to her a lot, and she definitely is mapper material. For the first time in her life, by talking to me, she realised she is not alone.

    Think of it : in the archetypical classrooms (I'm overgeneralizing a bit, but y'all get the point), daydreamers are positively persecuted by teachers. Learning by rote is thrust upon many pupils as *the* way to do it, the system often even doesn't allow any other approaches (never had to learn a poem by rote ? what's more nonsensical than learning a poem by rote ? would anyone of you teach computer science by having pupils learning actual source code by rote ? I didn't think so... (algorithms is different - they're 'meaning' rather than form, just as the poem is 'form' and the meaning behind it is the meaning...)).

    And socially, mappers have a hard time as well. Mappers tend to be interested in a lot of things, and have the automatic reflex of trying to find out the deep structure of *anything*. In many cases, whenever they hear a new, fundamental insight, be it about bee-keeping, writing a web-server, why the Germans lost WWII or just about whatever, their attention will focus on it (a new pattern or bit of deep structure to discover!) and they will delve into it. Packers will often find these non-useful things incredibly boring. And mappers being a minority, they get isolated. In some cases they become 'jesters' - discovering that putting the truth into a humoristic form (irony & sarcasm) makes a huge difference - it becomes digestible. Packers don't *have* to think about the sarcastic comments - they laugh and continue on. And as laughing is fun, they accept the mapper a little bit. So this is a typical social niche for mappers.

    And so on and so on. Fellow mappers will definitely recognise the persecution problem. The most flexible ones might have solved it, but I wonder if any mapper had a really happy childhood - my guess is that many either spend it in isolation, or have to fight for recognition and harden up - I know a few cases like that; I'm one of the soft cases. When hardening up, these mappers I think learn ad play the packer game. They migh become very succesful, but I think they turn into high-end packers themselves after a while, losing the Child inside (mappers often have a strong child in them - time to bring up a Zen motto 'always keep the mind of a beginner', and "conventional" wisdom : learn and see the world through child's eyes : I think the trick is not to forget...

    * MBTI

    I was quite amused at one response in the thread, which stated that mappers are simply the INTP category in MBTI. The amusement stemmed from the fact that during the MBTI course I did the test and came out... INTP. I have given the matter a lot of thought, and although there probably is a correlation, it isn't strong enough.

    I'm reasonably sure N (iNtuition) is a very strong mapper factor. It has a lot to do with the unconscious pattern detecting abilities almost anybody has. Mappers probably have high amounts of intuition in general - and it's essential to their cognitive strategy. The cognitive strategy of a mapper consists of detecting the 'deep structure' of the contemplated problem (a job for which you need advanced pattern detection), extracting and storing that structure, in a more or less object-oriented way (by creating classes in the mind, having properties attached, and having relationships between them). I think mappers are highly apt at manipulating and exploiting these mental structures. Packers on the other hand rely much more on learning by rote : storing packets of information, storing procedures, and not trying to figure out how it all fits together. Mind you, I think packers are people who get things done - basically because they spend little overhead on all the issues that aren't immediately relevant. Mappers have a lot of cognitive overhead, but are able to build more elegant, economic end-products.

    Anyway, that's the N-mapper correlation. the opposite for N is S (sensing) and has to do (I think) with seeing reality directly as it is. I think the MBTI goofed on this one - packers don't see reality as it is (deep structure isan integral part of reality, dammit !) but they absorb reality in 'literal unlinked bits' - of course they don't make associations as easily as N people in that case !

    The I (Introvert) correlation I think is probably mainly an environmental product, due to the packer dominance. Mappers are a minority, are repressed, and are forced into their 'own world' (often a fantasy world - hackers might start to see the deep-structure/hacker/science-fiction/fantasy/imag ination/daydreaming pattern emerging here, one of the reasons in the past I sometimes thought of posting to slashdot about the mapper/packer documents). So they rate introvert. I myself used to be very introverted - I had few or no friends, I spent all my time in my room, I never went out; at school I was hunted by other kids, who had no end of fun laughing at the fact that later I wanted to become an astronaut - in contrast, after through circumstances I 'blossomed', at work I was estimated as being very extrovert (can't shut up - this mail is a good example) and people were surprised I scored as introvert on the test.

    Actually, I was almost right in the middle between introvert and extravert. These experiences have led me to believe that introvert/extravert is not a relevant dimension for mappers/packers a priori, only circumstances created the introversion preference.

    As for the T - although I personally have quite a rational slant (I've got a bloody university degree in Math for chrissakes) I'm very emotional as well (very strong empathy - another trait which I think strong mappers have - the hard ones lose it because it's a very bad trait in a packer-dominated society - it subverts many procedures), and I scored about evenly on T (I forget wath it stands for, but I though it had to do using rational thought when making decisions) and F (which stands for Feeling - meaning those people make decisions based on emotions). I don't think there's any correlation - T and F people are equally likely to be mappers. Only F people might be less likely to be diagnosed as one, because many emotional reactions are socially programmed (think of how you would at first react to seeing a topless person walking by in the street - the reaction is socially programmed, in several tribes the clothing standard is a loincloth, and I guess there must have been tribes where nothing was worn frequently), and when you react to an event, emotional processing is neurologically faster than rational processing, so neurological response happens first. And since the social/emotional programming is mainly packer-made due to their superiority in numbers, F people will first react the packer way... QED (ok this is just a theory I just made up, but it makes some sense to me).

    And finally, P or J : I think J means 'Judging'. Extreme J's are very well-planned people, not liking unexpected things, and planning everything, and adhering as much as possible to the rules. P (forget what it stands for) are fly-by-the-seat-of-my-pants types. I think there's no natural preference here, but I think packer society trains people to be as J as possible, thus there could be a slant for typical packers to be J.

    What I'm basically saying is that when analysed, mappers and packers would be all over the place in the 4 by 4 MBTI matrix, with maybe a preference for mappers to be N (although mappers trained into packers might score as N whilst getting diagnosed as packers). I fully expect however that manifest mappers would be more strongly clustered (I would expect them to score higher on N and P) because I think certain types might be more resistent to social programming.

    * Wrapping it up

    There is more, much much more to be said. Anybody should feel free to contact me if you want any of the other written materials (which admittedly need to be worked on, but we could do that together ?). For reference : e-mail : parickx@janbe.jnj.com Alan and I have often played with the idea of making the whole thing an open-source project, by setting up some kind of organic website. We're not out to win any Nobel Prizes by cooking up a theory in secret then publishing it, or something like that. We just want to make the world a better place :-) And I'm not a blind idealist either (although it's hard to avoid the trap of putting everything in a black-white way, and putting in the nuances would take ages).

    We're also incredibly interested in validating the whole thing scientifically (the M0 paper actually adresses a neurological/biological phenomenon that might lie at the base of packer dominance - we'd so like to test it, any neuro-chemists in the crowd ?) so we try and be rigid. After all : anything I have said is true in one sense, false in another sense, and completely meaningless in another sense (I'm not a total relativist - think again if that was your conclusion, or read some RA Wilson).

    I'm also prepared to erect a second, new mailing list (the archives of the first one contain some very personal material, and are only accessible to those who were there - I know it's dangerous saying this in a roomful of hackers, but if you're a real hacker you know the meaning of respect and responsibility).

    So, fire away any comments, and anybody is welcome (especially critics, since their comments are the ones that show us our errors - much like in physics you test any theory by attacking it on all sides all the time).

    Take Care All !

    Philip Arickx - //mailto:parickx@janbe.jnj.com

  • Re:Programming classes (Score:3)

    by Anonymous Coward on Wednesday September 29, 1999 @06:54AM (#1650454)
    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. -- summarized as : those who only have a hammer to work with tend to see every problem as a nail.

  • Re:programming courses Re:Looks wonderful (Score:3)

    by Anonymous Coward on Wednesday September 29, 1999 @11:06AM (#1650455)

    Your post quite clearly shows that you don't know a first thing about Computer _SCIENCE_ (or then again maybe you overstated your opinion on purpose). CS is not primarily about programming. As a sidenote, Haskell can probably kick most languages' buts quite easily. Just because you don't understand the beauty of the language you start to bash it. I was like that a long time ago when I thought that C++ was the one true language; then I grew up.

    Programming is about how you solve the problem and how you arrived at the solution. How can you be sure your solution is correct, unless you can duplicate and verify your reasoning ? (see Dijkstra: A discipline of programming). It also matters a lot if the complexity of your solution is O(log n), O(n), O(n log n), O(n^2) or O(2^n) (see e.g. Cormen et al.: Introduction to Algorithms). If you're trying to solve an NP-complete problem you'd rather try to come up with an approximate solution than try to solve it with brute force. How do you know an NP-complete problem if you don't know algorithmic theory ?

    How you solved it and in what language also matters (there's this thing called _software engineering_, maybe you've heard of it ?). The Tao of Programming quite clearly states that you (or someone else) will have to maintain that solution sooner or later. (see e.g. Pressman: Software Engineering: a Practitioner's Approach)

    Maybe your hacker brain doesn't quite get that hacking is not science. Go work if you want to hack, computer _SCIENCE_ is supposed to teach a _scientific_ way of thinking (you know, models, testable theories, reproducible results, the thesis/antithesis/synthesis stuff, etc.). There are many misguided schools, which don't do this however and it's going to be worse because of industry pressure on the schools. If it were up to me, reading Dijkstra, Hoare, Mills and Knuth would be mandatory and I would also skip CORBA, Java, RUP, UML and OO in favor of formal specification and verification, algorithmics, conceptual modelling (formal ontology, description logics, etc.), AI and similar more theoretical areas of CS. It is my experience that the theoretical areas of CS contain a lot more useful (and longer lasting) subject matter than any of the industry-hyped technologies, which come and go.

    AC

  • Autism. (Score:3)

    by Kaz Kylheku ( 1484 ) on Wednesday September 29, 1999 @07:04PM (#1650456) Homepage
    Although, autism has had some slashdot attention lately, but let's not go overboard ascribing everything to it. ;) It's not productive to merge ``autism'' and ``intelligence'' as synonyms for the same thing; the power of words lies in their ability to discern among meanings.

  • Did you notice the screw up? (Score:3)

    by Kaz Kylheku ( 1484 ) on Wednesday September 29, 1999 @11:36AM (#1650457) Homepage
    In Chapter 2, section ``Quality Plateau'', the author attempts to restructure some skanky looking function written for the Win32 environment. For the sake of making it look more readable, he suspiciously moves a mutex release so that some accesses to global variables are no longer protected! The whole point of the mutex is so that you can safely and atomically do the g_nIndex++ and the update of the g_dwTimes[] array! (I know because I chased the reference and looked it up on the book. In _Advanced Windows NT_, a critical section is used instead of a mutex).

    I would restructure the piece of code by calling GetTickCount outside of the critical region of code, and only do what is absolutely necessary while the lock is held: namely the update of the shared data.

    Also, what kind of a dorky cheesehead thinks that changing from one bracing style to another is a form of simplification?

    Overall, I find the piece to be a rambling bunch of psychobabble designed to stroke the egos of programmers, who will at once fancy themselves to be the good mappers and not the evil peckers. Oops, packers. ;)

  • Temporary Mirror (Score:3)

    by Tekhir ( 32379 ) on Wednesday September 29, 1999 @06:36AM (#1650458)
    I've put up a temporary mirror and list of mirrors. I'll remove it in a few days so enjoy it while it lasts. I also zipped up the entire contents so you can download it for later reading. From what I've read its really good. The url is:

    http://www.geocities.com/tekhi r/Progstone/index.html [geocities.com]

  • Re:Feynman's story? (Score:3)

    by Basalt ( 47097 ) on Wednesday September 29, 1999 @09:57AM (#1650459)
    The six lines on the Shuttle Booster (STS SRB) had to do with lining up the segments of the boosters.

    Feynman found that one of the problems in setting up the boosters had to do with aligning the segments at the launch site. He asked the technicians, if some alignment marks (six lines) painted on the booster would help. They said "yes, but we're not allowed to. It's not in the spec'"

    BTW: This specific item turned out not to be directly involved in the disaster, but did point to the mind set that caused it.

  • Nice story, but.... (Score:3)

    by smoondog ( 85133 ) on Wednesday September 29, 1999 @08:58AM (#1650460)
    Just a couple of comments. Personally, I think this has a bit of the problems that many writings by talented but inexperienced writers often have. I'm not an expert, but hear are a couple of points that I think hurt the flow:

    1) There seems to be a trend in this for broad over-generalization and labeling. Things in life never fit into tidy little packages, and writing should reflect that. In the second section of chapter 1, for example, the author claims that the state of programming as a whole is horrendous.

    I just can't agree with that belief. The book also labels people and idea's in a manner which is inconsistant with reality.

    2) Secondly, I feel that the author has a pretentious, arrogant tone that makes me question the foundation from which the author is working. A bit of modesty, in my opionion, never hurts writing.

    -- Moondog

  • Did you notice the second screw-up? (Score:3)

    by rebill ( 87977 ) on Wednesday September 29, 1999 @11:58AM (#1650461) Journal
    The code reduction in The Quality Plateau (Day 2) does not perform the same function as the original. On the last iteration of the loop in the original code, ReleaseMutex() is called when g_nIndex == MAX_TIMES.

    In the final code, ReleaseMutex() is not called when Index == MAX_TIMES.

    That kind of reduction causes hard-to-track bugs :(

  • Mappers are from Venus, Packers are from Mars (Score:3)

    by cworley ( 96911 ) on Wednesday September 29, 1999 @12:39PM (#1650462)
    This is the sort of psychobable that led me to drop the school of Psychology in favor of a Computer Science degree (since then, I've found CS to be as much alchemy as Psychology).

    When you try to quantify and categorize behavior, you always find that you:

    1) force fit folks who don't fit; change the song to make the words rhyme.

    2) have too many exceptions to be a scientifically valid theory.

    So, it's my turn:

    You have four types of programmers:

    1) Clueless -- in way to deep over their heads, don't understand the subject, and it shows.

    2) Hacker -- I'm going to fix this problem any way I can and by any means necessary and am going to be obsessively focused. Can cause a coronary if allowed to work with Windoze for more than a year (unless they figure out that the solution requires a fork-lift).

    3) Guru -- Everybody turns to them for an answer; in reality, they just know how to use the man pages.

    4) Primadonna -- works well in teams of 1 or fewer. Must understand everything in minute detail before any work can be started. Has written the ultimate "hello whirrled" program.

    I've been all of these often; sometimes in the same day.

    Chris

  • Interesting pile (Score:4)

    by evilpenguin ( 18720 ) on Wednesday September 29, 1999 @11:35AM (#1650463)
    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."

  • Now I get it -- I'm a mapper! And I've been working with packers all my life (and a mapper here and there, of course).

    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

  • I'm not all that impressed (Score:5)

    by raph ( 3148 ) on Wednesday September 29, 1999 @06:59AM (#1650465) Homepage
    Yeah, it was an interesting read, but I don't think it contains any deep revelations.

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

    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.

  • Some Points to Consider (Score:5)

    by mself ( 29176 ) on Wednesday September 29, 1999 @09:00AM (#1650466)
    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

  • Re:Programming classes (Score:5)

    by Sajma ( 78337 ) on Wednesday September 29, 1999 @06:50AM (#1650467) Homepage
    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?

Slashdot Top Deals

E = MC ** 2 +- 3db

Close