The Programmers' Stone (2014) | Hacker News Reader

The Programmers' Stone (2014)

datapacrat.com

203 pointssnvzz34 comments

I haven’t read the whole thing yet, but the structure and format and content-richness is a breath of fresh air.

I miss sites that were about sharing ideas and helping others rather than getting claps.

The only way I could think of making this better was if it was generated from a git repo so that one day if I’m ever worthy of asking a question or sending a suggestion, I could send a pull request. But that’s totally author’s prerogative and I’m happy they shared this in a non junky-way.

This text is not as impenetrable as it first seems and offers some valuable insights on the friction between socially conditioned roleplaying ("packing") vs deep thinking ("mapping").

My best takeaways were:

1. You're not crazy for being a deep thinker: it drives force multiplication

2. Ceremony is very often bullshit

3. You're going to have to make some quality sacrifices in your code - here's a useful model on how to approach that

I also liked the bits about using a step debugger for code reviews, and avoiding nested conditionals. I mostly failed to grasp the camel sex analogy.

It's been ages since I read this, but I remember coming away with a very different impression. "Packing" is essentially storing away details in your memory. If you ever see programmers who write the solution to everything down and then are constantly looking up their notes: that's a packer. "Mapping" is essentially deriving from first principles. It frees up a lot of working memory in your head and allows you to explore the issues more freely.

I think it's a bit more than that, though. Fluency in a task usually means being able to do it without undue planning. When you are speaking, you don't figure out the grammar of what you are saying. You just open your mouth and it kind of pops out. It's that kind of synthesis that's important. It's the same as play chess at a high level or especially playing go. You might not know exactly why one move is better than the other, but your fluency allows you to judge it correctly. To me, that's "mapping". "Packing" is a good strategy if you don't need to judge the value of your work. This is the answer: right or wrong. You can write it down. You can memorize it. You can produce it at the appropriate time. But you can't derive it without a lot of effort.

This writing influenced my thinking a lot, but when I started to get involved with language acquisition, I started to feel that it's a bit limited. I think language/skill acquisition models are actually a better fit. However, this analogy is still useful in certain ways.

I didn't get that at all. The premise of the article is that society, for agrarian/industrial revolution reasons, has conditioned us to be "packers" - reactive cogs.

It implores us to learn from the Japanese post WWII practice of Total Quality Management / Kaizen to become imaginative mappers.

The article strongly divides people into one of the two camps, with frequent Dilbert references and disparaging remarks towards packers as "holding their toothbrush with chopsticks". It strongly criticizes packing as worthless ceremony for the sake of social ritual.

(If you squint hard enough there's also a parable in there about premature API layers and strong typing, but I'll concede that part's subjective).

The Ghost Not article/paper/essay sits adjacent to The Programmer's Stone and is mind-blowing.

https://www.datapacrat.com/Opinion/Reciprocality/r2/index.ht...

I'm very curious the history behind all of this, the original author(s), where they are now or where any of this theory went, whose thinking it influenced.

Thank you for linking to this.

Wow! This is a blast from the past! I'm trying to think... It's got to be 20 years old now. Anybody know if it's been updated in that time? I don't really remember it being quite so long. And for some reason, I remember the background being black or something weird like that.

Edit: Well, from the "unsolicited testimonial": 'On Tue, 2 Nov 1999, Alan Carter wrote' So, I guess I'm pretty close on the 20 year thing :-)

I first read this in the early 2000s. It's part of the Reciprocality project, which is hosted at https://www.datapacrat.com/Opinion/Reciprocality/

It's been discussed on Hacker News a few times before. There's also a Yahoo group for discussing related ideas: https://groups.yahoo.com/neo/groups/progstone/info with posts going back as far as 1999.

The bottoms of the pages claim this if from 1997.

Definitely not 2014.

I've formatted the book into an EPUB and uploaded it to libgen.io: http://booksdescr.org/item/index.php?md5=fa2fdee7b8a50612970...

Thank you! There are a few large sections in blue text. I'm not sure if you did that intentionally and I am missing the reasoning. Thought you'd like to know.

Those are in the original too. I'm not yet sure of the purpose either. On closer inspection, the blueness is from an <a> element that wraps the blue text. The <a> element seems to have a CSS class called "taylor" applied to it. Maybe an editorial artefact? Sorry for not fixing that.

Thanks! How do I download it from there? So unclear :)

Warning: this site seems to be infected with malware. I got a "your computer is infected" popup about 10s after the DOM loaded.

I'm not seeing that, but that might be because I'm using an adblocker. I vouch that the site is trustworthy (at least with an adblocker). If you click on the book's title on libgen.io [0] (the primary mirror of Library Genesis [1]), that's where it takes you.

[0] http://libgen.io/search.php?req=programmers%27+stone [1] https://en.wikipedia.org/wiki/Library_Genesis

I love that the authors blog [0] hasn’t been updated since 2013. It makes me feel better about my most recent post being from 2009.

Also points out the beauty of the web that it’s so effortless to maintain information that it’s easier for me to keep it running than shut it down.

[0] http://blog.datapacrat.com/

Scanning the table of contents, this looks pretty interesting. Anybody worked through it before?

I agree, looks interesting, but so do lots of things.

It would be valuable to have a short description from someone who's read this, please.

"There's two ways to approach work: social ('packer') and philosophical ('mapper'). Philosophical is more effective, but your boss is likely to be a packer. Here's some practical tips to understand and alleviate that tension."

It also champions the bazaar over the cathedral.

> If only the whole of the industry performed as well as the tiny minority of excellent workers, the economic benefits would be immense.

That ship hasn't come in yet. Maybe the Pareto principle is stopping it.

Wow! Sending that page to print as pdf (to read in a ebook) was a breath of fresh air, after struggling with headers, sidebars and floats in the typical web page.

Maybe you can share that PDF for some sweet, sweet fake internet points, since the site seems to have been hugged to death.

Are Internet points more fake than other kinds of points ? Would they be less fake if we had a system to aggregate all the points from other systems (Hacker News, YouTube, whatever other systems award their users points on the Internet) into a single Internet Points system ?

I only saved the first chapter, but you have the whole thing archived:

https://web.archive.org/web/20190627151514/https://www.datap...

> The purpose of this site is to recapture, explore and celebrate the Art of Computer Programming.

There's real good stuff here. Minor quibble: 'The Art of Computer Programming' is a well known series of books by Donald Knuth. You might say:

"The purpose of this site is to recapture, explore and celebrate the art of computer programming."

This is as old as a stone. I recall translating part of the essay to Russian when I used to study philosophy as a PhD student back in 2004. https://www.fabmicro.ru/~rz/Progstone_rus.doc

I always think about API/Implementation as Cause/Effect.

Each API will give different implementation.

The things that i learnt is that, i need to spend more time on API usage rather than implementation. With basic API and raw implementation, i could incrementally improve the implementation later.

With a broken API usage, my code is trashable.

FYI: It's always a good idea to put the date that you wrote this, and then the date that you update it.

The year (1997) is written at the bottom of the pages.

The title here says 2014, but each chapter has a "last updated date" from either 1997 or 1999.

Clicked some random parts. Got hooked right in! Is there an epub/mobi?

It should not be to hard to convert the html files to epub using pandoc with a script. Will check later if it is worth the effort. I would also prefer PDF to read it.

Here you go with a oneline (in bash, PDF, change as required):

    for i in {1..7} ; do curl "https://www.datapacrat.com/Opinion/Reciprocality/r0/Day$i.html" | pandoc -f html --pdf-engine=xelatex -o "chap$i.pdf"; done

Reply on news.ycombinator.com