Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Programmer's Stone

Hemos posted about 15 years ago | from the interesting-read dept.

News 114

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

Sorry! There are no comments related to the filter you selected.

Re:Interesting pile (0)

Anonymous Coward | about 15 years ago | (#1650354)

I think it's more than that. I've always thought differently from most people, and it's gotten me into a lot of trouble over the years. When I read this, I got the "Ahah!" others have gotten.

I think this packer vs. mapper is a very simplified (and incomplete) version of what is referred to in the Myers Briggs personality test. I suspect many mappers would turn out to be INTP types, or very close. Look it up if you don't know what I mean... Let me know if you don't find anything.

Still, I think he's pretty close to the truth. I used to get a lot of hell from teachers early on from daydreaming. I did great in Math, until it got complicated enough that I couldn't figure out the WHY anymore (largely due to teachers that didn't know the why and thus couldn't teach it - and I couldn't figure it out on my own well enough). I just don't learn well from rote memorization, which is pretty much the unthinking norm in education. I have to integrate everything into my internal model or knowledge hierarchy before it's very useful to me. So it takes me longer sometimes, but I actually understand it at a much deeper level when I'm done. I won't even get into the frustrations that so many people can't reason their way out of a wet paper bag. Logical fallacies are *everywhere*!

I could go on about the problems I've had from being different in this respect, and I think many of us have gone through similar experiences. But the parallels between my own life and this are too much to dismiss off-hand. I must say it's gratifying to read something that articulates all this.

BTW, about that "native curiosity"... I used to think that... I think maybe that's also stamped out my the educational system. Real curiosity along with intellectual honesty is a very very rare thing. You talk to people and eventually realize that most of them don't want to know. To me, people with those traits of curiosity and intellectual honesty are worth much more than merely their weight in gold. You can't put a price on that.

Looks like a bunch of jingoistic bull to me. (0)

Anonymous Coward | about 15 years ago | (#1650355)

"...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning." -- Matt Welsh

Essay? Ha! My Review; comparison with Objectivism. (0)

Anonymous Coward | about 15 years ago | (#1650356)

Just a quick comment... I sat down to read this during a break at work yesterday (I work at a workstation, basically unsupervised except that I have to turn stuff in and meet deadlines now and then) and ended up not being able to stop reading! I consumed the whole day! And I only skimmed some parts! When my boss finds out my projects are late, he'll be furious! If I were honest, I'd have to say that I was Stoned yesterday...

I'll probably write a critique of the Stone this weekend, just for my own personal reference; by then it will be too late to post any conclusions on Slashdot. Which reminds me of one of the things I hate about these daily news pages. (I read Slashdot and Redwood's and Blue's news.) Articles posted are of varying importance, and you cannot tune in, say, every Sunday and find out the most important items for the week. Sad! You also cannot continue to discuss things on Slashdot for too long, because people begin to forget they're there; they scroll off the bottom of the page and become less interesting than the new stuff. (Is there an alt.fan.slashdot Usenet newsgroup?) This is an article that will take many people weeks to digest...

I am approaching this as an Objectivist. My critique is therefore kind of weird, maybe even esoteric, but here it goes. Ayn Rand observed the same distinction between mappers and packers. She used different terminology and drew conclusions far broader than just programming. Guess what: the same kind of thinking that helps with programming helps with everything. Mapping is thought. It is the making and use of new concepts. (Although, unfortunately, mapping can wander pretty far from reality if allowed to.) Packers, OTOH, spend a great deal of effort trying to stay within the worlds where their knowledge packets still apply, and they fear anything foreign. Packing is an attempt to avoid thought; I think a consistent packer, i.e., one who never does mapping at all, maps to Ayn Rand's "anti-conceptual mentality." Ayn Rand hated those, as you can guess from her terminology for them! It is true that few people are entirely mappers or packers, but that does not invalidate the distinction, any more than the fact that few objects or climates are consistently hot or cold invalidates temperature. Some people, also, map when they program or write, but pack when it comes to larger issues such as philosophy.

Why do people pack? Because it saves time. Mappers do pack but they can explode their packets and re-form them as necessary; they know where the packets came from. Packers adopt packets without knowing where they came from. I don't think packing has anything to do with agriculture; it is as old as ritual.

There are huge philosophical arguments going on right now, between Objectivists and Libertarians and others, where each side tries to win points by proving (without using the terms) that the other side is packing... some people who rail against Ayn Rand are packers, but those who do it most passionately are mappers who think Rand's followers are packers... they would do well to think again. Different philosophies present entirely different maps, with few common points between them... but few have tried any comparative cartography; most prefer to deny that the other map exists.

The "mapper" and the "packer" are useful concepts. Because of that, this essay is a big step in the right direction. It has some flaws, e.g., it sets up packing as an equivalent "mode of thought" when it is really non-thought, but the important points of the essay don't depend on its flaws. To the author: way to go.

-- An Ayn-onymous Coward

Good Point (0)

Anonymous Coward | about 15 years ago | (#1650357)

I found myself trying to find as many things that would slant me to either side. While some of the things where kind of both sided, I do remember being paralyzed more than once because I'm trying to fit things in the proper order.

While I agree with his views on mappers, I can't think of anyone I know that would be the description of a packer. Maybe there should be a few more categories...

Too Much AD&D (0)

Anonymous Coward | about 15 years ago | (#1650358)

OK, after reading this and ESR's essays I just have to say that some people have played a little too many games of Dungeons and Dragons.

Didn't you people ever see the Tom Hanks movie [imdb.com] ? If you did you'd know that D&D will destroy your mind. It will make you write incomprehensable essays that are based on fifteenth-centery agrarian economics or the master-apprentice dynamic. This must stop!!!

-Grandmaster B
author of the forthcoming: "The Rabble and the Rousers: an epistomology study of Linux evangelicalism."

---
Sing: Join us now and embrace your insanity. You'll be free wackos. You'll be free...

Re:programming courses Re:Looks wonderful (0)

Anonymous Coward | about 15 years ago | (#1650359)

Programming is about how you solve the problem and how you arrived at the solution.

Bullshit. Programming is about building software that people can use. How you do it is completely and totally unimportant. You can take your formal specification and veification and shove it up your ass. Programming is not a science it is a CRAFT.

Re:Mappers are from Venus, Packers are from Mars (0)

Anonymous Coward | about 15 years ago | (#1650360)

well, you forgot the important programmer: 5) developer. gets shit done well, on-time, and the app actually works for years, is maintainable and understandable, and is somewhat logically consistent. Also understands what the app is for and the audience/users. Do you know your code well enough to use a mental model to debug it? Can you also incorporate the app/os/user interactions into your model?

programming courses Re:Looks wonderful (0)

Anonymous Coward | about 15 years ago | (#1650362)

A hearty second on that motion. My class is using this bullshit language called Haskell, and all the book or prof can do is sing the praises of functional programming... Phui! More like non-functional programming. My professor got her doctorate in Math, which might explain why the Official Coding Style Which Must Not Be Deviated From really strikes wrong notes against my organic, perl-lovin' hacker brain... I thought the point of programming was solving the problem, not how you solved it or in what language. :( Someone please firebomb the CS faculty here and save me teh trouble.

Bad programming classes (0)

Anonymous Coward | about 15 years ago | (#1650363)

The type of class, "here is your set of solutions, now fit it to your problem" is the wrong way to teach. I have taken programming classes where an instructor has tried to shoehorn the soloution to a problem into a predefined box. One even said, "It's not in the book."

The proper way is to teach problem solving. Then teach, how to choose the correct tool(s) for the problem. And then, how to apply those tools. And don't forget a course on debugging (but I don't need that :)


Software engineer wins against Mattel!" [sorehands.com]

Re:Wow, he's telling us we're...umm 'special' (0)

Anonymous Coward | about 15 years ago | (#1650364)

No, no, no. If anything has been learned from the stories on Slashdot this week, it is that computer geeks are 'special'. I mean 'special' as in "special olympics", not free beer.<g>

Re:programming courses Re:Looks wonderful (0)

Anonymous Coward | about 15 years ago | (#1650365)

If you actually like PERL, then its no wonder you can't wrap your mind around Haskell.

Mapping and MBTI (0)

Anonymous Coward | about 15 years ago | (#1650366)

You can take personality type into account, but you are misunderstanding the functional difference if you say it's a N vs S difference. SPs can be very good at mapping, and they get good at real-world mapping, like mechanics. I had a boss who was an ISTP, so they can learn tech too, but they have a different perspective on it than geeks(intuitives). I won't explain that here.

Mapping versus packing is really Introverted Thinking (Ti) versus Extroverted Thinking (Te)

A Definition:

Introverted thinking isn't related to introversion; you can be an extrovert and have it. It's the type of thinking that's based on "figuring things out". If you get a new video game and don't bother reading the instructions, but just figure out as you go, you're using introverted thinking. It can't really be taught, because it doesn't use words or principles;you just have to learn how to notice when you're doing it, kind of like walking.

If you read the instructions first and reorganize the instruction material until you understand it before you play, that's extroverted thinking. Extraverted thinkers are more likely to delegate, unless they can't do so for some reason.


Here's how MBTI personality type applies: if you have a type preference that ends in TP, you have introverted thinking. If you have a type preference that ends in TJ you have extroverted thinking. I'm not sure how 'F' types do their analytical thinking, so I won't comment on that.

Mappers (introverted thinkers) don't do well with methodology because they're too sensitive to the exceptions to the rules.

There may be some J-factor people who are offended by being called packers. If we put labels aside, the point of this post is that this phenomenon has been studied in other areas,like psychology, but has different terminology.

Re:God, some of his sentences are difficult to par (0)

Anonymous Coward | about 15 years ago | (#1650367)

I come from a country, France, where teaching is SOLELY focused on Math and Mapping behaviour.

Believe me it is no less traumatic to those that "don't fit in" i.e. the jocks and there are some downsides to a pure mapping culture.

marc

Simple reasons (0)

Anonymous Coward | about 15 years ago | (#1650368)

People who become packers are those who are willing to be led to that outcome by their parents, their teachers, their friends, etc. People who become mappers are those who don't 'follow the leader.' Sometimes it's helped by the parents, friends, teachers, etc. Other times, it's just sprung out of their mind, by whatever forces they posess in themselves. Upbringings are /not/ similar. Kids in school are divided into groups, parents treat kids differently (I have yet to hear of any parents that treat their children anything like other parents do. they all do it differently). the only similarity is that they're human. That itself says that they will be unpredictable. You never really know which way one person will go untill they are there.

Re:Wow, he's telling us we're...umm 'special' (0)

Anonymous Coward | about 15 years ago | (#1650369)

i don't know how much of it you meant as a joke, but i actually do get that feeling (perhaps attributable to the age factor concerning many posters???).

perception of your own thought process being different than others you encounterd can also mean that you are not graping information that others are, thus comprehending less. it doesn't necessarilly mean you are some, ahem, "mapper" genius.

this piece (touchhstone something) resembles so much of these business books, oversimplification bs where everything is one or the other.

boink. (one day, i'll figure this html crap out ;-)

Re:programming courses Re:Looks wonderful (0)

Anonymous Coward | about 15 years ago | (#1650370)

I think he mean "computer science" iso. programming.

Separation Of Duties (0)

Anonymous Coward | about 15 years ago | (#1650371)

Ditto once again on the authors' writing style and some of the analogies and examples are a little esoteric for most people. They have some excellent points to make but they make them in such a laborious fashion (at least for the reader). What ever happened to the KISS principle?

I agree with your three phases and that most coders aren't good at all three. This is exactly why there should be more separation of duties in the software profession (Hey, even accountants can get this one right!).

In a world without fences who needs Gates?

British Army at Port Stanley? (0)

Anonymous Coward | about 15 years ago | (#1650372)

Um, can someone explain what happened to the British Army at Port Stanley?

It seemed to be an important comparison in the article, but I don't grasp the connection.

I understood the bit about the US Army in Grenada, but I'm afraid my Falklands knowledge is lacking.

needs work (0)

Anonymous Coward | about 15 years ago | (#1650373)

ditto on style points, or lack thereof. awful writing style; let's hope that guy isn't writing flight control software. ditto also on previous comments on abstraction. I believe there are 3 phases of software creation;
1) problem grasp
2) decomposition, abstraction, and reduction (i.e. design)
3) craftwork (i.e. implementation)
in my experience, most coders are poor at all three. some are craftsmen but not good at abstraction. very, very few are good at "phase 2". SW engineering is good as far as it goes, but it leads weak minds into thinking all development work is phase 3. we have recently gone thru 9001 at my workplace, and geez the PHBs have grabbed onto it like a drowning man with a life preserver. which is ridiculous since this is a research environment, where everything we do is new.

He's ESR in disguise! (0)

Anonymous Coward | about 15 years ago | (#1650374)

And this looks like a new CatB!

Re:Interesting pile (0)

Anonymous Coward | about 15 years ago | (#1650375)

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 agree with this notion. It seems whenever I learn something that involves an interesting pattern of thought, I feel the sensation of the underlying beauty. Whether it's a mathematical proof, or a cool algorithm, once I understand the idea, it's as if I've plugged a new section into my brain and suddenly brought it to life.

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

Same here, until I discovered it was an obvious result of the fact 10 = 1 in the integers modulo 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)...

Again, a simple consequence of the fact:

arctan(x) = x - x/3 + x/5 - x/7 + x/9 ...

And tan(pi/4) = 1.

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.

True, but it is also important to explain to people WHY things are the way they are, and expose them to some of the underlying ideas as tools. Just giving someone an interesting fact will make them curious, but you aren't going to find many people brilliant enough to discover that arctan can be represented as a power series if they have no prior exposure to calculus.

Re:At Last! It's Been Put Into Words (0)

Anonymous Coward | about 15 years ago | (#1650376)

One of the things that I find most exhilerating --- and yet simultaneously, some days, most frrustrating --- about programming professionally is how it is necessary to function reasonably with no clear understanding of what is going on.

I work with a reasonably large code base, very little of which I wrote (inherited code, mostly). It's complex and interdependant enough that when I started, I was literally fixing bugs in a vacuum: in order to fix a bug, I'd have to form an approximate picture of how an entire subsystem worked, with no road map other than the code itself. As a result, I was extremely reluctant to venture outside of the narrow box of stuff that I understood --- changes with side-effects on subsystems you don't understand are scary.

I find on later reflection that a lot of my pictures were wrong, or at best half-right. But
that's ok; I have a better understanding now, and the picture becomes sharper, and the pattern clearer (although there are still gray areas that i've avoided looking at too closely).

Re:Temporary Mirror (0)

BlueWire (9674) | about 15 years ago | (#1650377)

Was just gonna ask... :) tucked - stuffed and in the pilot...

Re:Thanks so much (0)

mong (64682) | about 15 years ago | (#1650378)

Hmm, wonder if we could apply the /. effect to less "worthy" targets...

I believe MS have a great article on their site about Samba. Not sure where though, you'd better look around...

Mong.

* Paul Madley ...Student, Artist, Techie - Geek *

most people are forgetting... (1)

Anonymous Coward | about 15 years ago | (#1650379)

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.

Doesn't know anything about Deming, programming??? (1)

Anonymous Coward | about 15 years ago | (#1650380)

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

Chap 1 War references are wrong or incomplete... (1)

Anonymous Coward | about 15 years ago | (#1650381)

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.

process-focused vs goal-focused (1)

dmiller (581) | about 15 years ago | (#1650382)

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.

Re:Programming classes (1)

YogSothoth (3357) | about 15 years ago | (#1650383)

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" ;-)

Beggars in Spain (1)

Pseudonymus Bosch (3479) | about 15 years ago | (#1650384)

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

Gibson's vision is getting closer ... (1)

LizardKing (5245) | about 15 years ago | (#1650385)

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

Whoops ... wrong topic (1)

LizardKing (5245) | about 15 years ago | (#1650386)

This should have appeared under the Forbes/AntiOnline article.

Chris Wareham

Voodoo programming (1)

Francisco (5507) | about 15 years ago | (#1650387)

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.

Re:Interesting pile (1)

craw (6958) | about 15 years ago | (#1650388)

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.

Re:A wonderful essay, it fills me with dread. (1)

snicker (7648) | about 15 years ago | (#1650389)

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

Re: the idea of a test (1)

snicker (7648) | about 15 years ago | (#1650390)

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

A wonderful essay, it fills me with dread. (1)

snicker (7648) | about 15 years ago | (#1650391)

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

Now known as genetic programming :) (1)

hayden (9724) | about 15 years ago | (#1650393)

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. :)

Experiences of a tutor (1)

hayden (9724) | about 15 years ago | (#1650394)

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

Feel like the null-A trilogy? (1)

Snake (13761) | about 15 years ago | (#1650395)

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?

Re:Bee Ess (1)

Helge Hafting (14882) | about 15 years ago | (#1650396)

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.

Re:Version for Pilot? (1)

KFury (19522) | about 15 years ago | (#1650397)

Sure, passit along and I'll post it on my site. URL to follow.

Version for Pilot? (1)

KFury (19522) | about 15 years ago | (#1650398)

Does anyone know of a version of this in an electronic book format? anyone interested in compiling one?

Good in spite of itself (1)

webster (22696) | about 15 years ago | (#1650399)

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.

Quick conversion to .pdb (doc) for PalmPilot users (1)

Mike Miller (28248) | about 15 years ago | (#1650400)

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

Re:Some Points to Consider (1)

mself (29176) | about 15 years ago | (#1650402)

"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

Re:Interesting pile (1)

Mock (29603) | about 15 years ago | (#1650403)


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?

Re:Nice story, but.... (1)

Mock (29603) | about 15 years ago | (#1650406)


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.

Well, what did you expect? (1)

lmb (32460) | about 15 years ago | (#1650407)

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.

Feynman's story? (1)

Vegigami (32659) | about 15 years ago | (#1650408)

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,

Re:Not new ideas... (1)

look (36902) | about 15 years ago | (#1650409)

Hopefully, though, after reading, they will turn away in discust. Sorry, I'm a libertarian/anarchist, but I'm not a fan.

Re:British Army at Port Stanley? (1)

chazR (41002) | about 15 years ago | (#1650410)

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.

Re:Bee Ess (1)

Manax (41161) | about 15 years ago | (#1650411)

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

Re:There are only two kinds of people: (1)

Manax (41161) | about 15 years ago | (#1650412)

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. ;)

Re:Some Points to Consider (1)

drivers (45076) | about 15 years ago | (#1650413)

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. :-)

Article was good, but commentary better (1)

greenrd (47933) | about 15 years ago | (#1650414)

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! :)

Feels like the "Timeless Way of Building." (1)

L1Wolf (49045) | about 15 years ago | (#1650415)

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.

Re:Feynman's story? (1)

devphil (51341) | about 15 years ago | (#1650416)

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.

Re:A wonderful essay, it fills me with dread. (1)

GnrcMan (53534) | about 15 years ago | (#1650417)

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.

Maybe the importance lies in ... (1)

OldTechnoFreak (57505) | about 15 years ago | (#1650418)

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.

Wow, he's telling us we're smart (1)

twit (60210) | about 15 years ago | (#1650419)

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.

--

Where's the science (1)

Lerc (71477) | about 15 years ago | (#1650420)

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.

Re:A wonderful essay, it fills me with dread. (1)

DreamerFi (78710) | about 15 years ago | (#1650421)

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

Re:needs work (1)

Rares Marian (83629) | about 15 years ago | (#1650422)

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.

Re:Just to go a little further offtopic... (1)

muwahaha (85166) | about 15 years ago | (#1650423)

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.

Re:Version for Pilot? (1)

muwahaha (85166) | about 15 years ago | (#1650424)

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

Alex.

He just about nailed it (1)

Greyfox (87712) | about 15 years ago | (#1650425)

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.

great idea! (1)

Mr. Penguin (87934) | about 15 years ago | (#1650426)

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

Interesting paper... (1)

gid-foo (89604) | about 15 years ago | (#1650428)

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

Re:Programming classes (1)

dr (93364) | about 15 years ago | (#1650429)

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.

Re:A wonderful essay, it fills me with dread. (2)

jafac (1449) | about 15 years ago | (#1650431)

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

Re:Did you notice the second screw-up? (2)

Kaz Kylheku (1484) | about 15 years ago | (#1650432)

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.

Re:Whoops ... wrong topic (2)

Pascal Q. Porcupine (4467) | about 15 years ago | (#1650433)

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.

Packers and Mappers (2)

whig (6869) | about 15 years ago | (#1650434)

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.

Interesting; looks like MBTI S vs N (2)

Saucepan (12098) | about 15 years ago | (#1650435)

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

Bee Ess (2)

Smallest (26153) | about 15 years ago | (#1650440)

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.

Re:Feynman's story? (2)

Kartoffel (30238) | about 15 years ago | (#1650441)

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.

Programming classes (2)

hab136 (30884) | about 15 years ago | (#1650442)

>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. :)

Re:Looks wonderful (2)

Paul Johnson (33553) | about 15 years ago | (#1650443)

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.

Packers solve problems, mappers find solutions (2)

SpinyNorman (33776) | about 15 years ago | (#1650446)

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 would have been diagnosed as ADD... (2)

MetallicBurgundy (40252) | about 15 years ago | (#1650447)

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.

There are only two kinds of people: (2)

jlowery (47102) | about 15 years ago | (#1650448)

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!

Not new ideas... (2)

eric17 (53263) | about 15 years ago | (#1650449)

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

Looks wonderful (2)

Enoch Root (57473) | about 15 years ago | (#1650450)

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

C style hairiness (2)

Emil Brink (69213) | about 15 years ago | (#1650451)

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.

God, some of his sentences are difficult to parse. (2)

mattz (82905) | about 15 years ago | (#1650452)

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

Re:Programming classes (3)

Anonymous Coward | about 15 years ago | (#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 (3)

Anonymous Coward | about 15 years ago | (#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. (3)

Kaz Kylheku (1484) | about 15 years ago | (#1650456)

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? (3)

Kaz Kylheku (1484) | about 15 years ago | (#1650457)

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 (3)

Tekhir (32379) | about 15 years ago | (#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? (3)

Basalt (47097) | about 15 years ago | (#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.... (3)

smoondog (85133) | about 15 years ago | (#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? (3)

rebill (87977) | about 15 years ago | (#1650461)

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 (3)

cworley (96911) | about 15 years ago | (#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 (4)

evilpenguin (18720) | about 15 years ago | (#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."

At Last! It's Been Put Into Words (4)

ReadParse (38517) | about 15 years ago | (#1650464)

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 (5)

raph (3148) | about 15 years ago | (#1650465)

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 (5)

mself (29176) | about 15 years ago | (#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 (5)

Sajma (78337) | about 15 years ago | (#1650467)

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?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?