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