[HN Gopher] Coders at Work: Reflections on the Craft of Programm...
       ___________________________________________________________________
        
       Coders at Work: Reflections on the Craft of Programming (2009)
        
       Author : aragonite
       Score  : 100 points
       Date   : 2023-12-27 12:30 UTC (1 days ago)
        
 (HTM) web link (codersatwork.com)
 (TXT) w3m dump (codersatwork.com)
        
       | kleiba wrote:
       | See also: https://news.ycombinator.com/item?id=817235 (from 14
       | years ago)
        
         | bloopernova wrote:
         | I know it shouldn't really impress me, but I am nonetheless
         | impressed that I can vote on HN comments from 14 years ago. It
         | used to be that Reddit would make threads read-only after a
         | certain amount of time, and I'm not sure if they still do that.
         | Seems like an indicator of how robust a given site/app is.
         | 
         | Mentioning Reddit, I'm still salty they deleted private
         | messages from before 2023. They couldn't even provide an
         | archive for people to download?!? Utterly bizarre.
        
       | mannycalavera42 wrote:
       | one of my fav, would like a new edition with more interviews (I
       | know, I know, check on youtube etc etc)
        
         | medo-bear wrote:
         | Some time ago I read that he expressed interest in writing the
         | 2nd edition to Practical Common Lisp
        
           | cylinder714 wrote:
           | Oh! Good to know.
        
         | hotcrossbunny wrote:
         | My thoughts exactly!
        
       | warkanlock wrote:
       | It's one of my favorite programming books that makes you realize
       | how quickly you can become confused by the latest trends and
       | shiny new best practices, losing focus on what's important: being
       | a productive and efficient individual contributor when doing
       | something you love
        
       | urthor wrote:
       | I must admit, I read this and failed to find any profound, deep
       | way that these coders are different.
       | 
       | Seems like they just worked hard.
        
         | faiD9Eet wrote:
         | > I must admit, I read this and failed to find any profound,
         | deep way that these coders are different.
         | 
         | I have come to the same conclusion.
         | 
         | > Seems like they just worked hard.
         | 
         | I would like to draw another conclusion. Fitzgerald operated
         | _live journal_ from his bedroom as a teenager - so he was at
         | the brink of new technology. Same effect that gave rise to Bill
         | Gates. There are probably more effects at play, like working
         | for a company that does not waste your time doing bullshit
         | tasks and having a mentor to get you started. Even a like
         | minded individual will increase your chances to overcome
         | obstacles.
        
         | electrondood wrote:
         | I read it as a collection of stories from on the job.
        
         | neves wrote:
         | They all debug using printf and hard thinking. No fancy tools.
         | I like to play with tools, but they showed me that they really
         | that important.
        
         | 082349872349872 wrote:
         | they just worked hard (which many people do) -- on things that
         | _mattered_ (which many people don 't)
        
       | pjmlp wrote:
       | A great book. regarding the history of programming languages, and
       | specially getting the realities of languages when they came to
       | be, rather the perception of their capabilities today.
       | 
       | Love Fran Allen's interview regarding C early days, versus other
       | ecosystems.
        
         | AnimalMuppet wrote:
         | For those of us who don't have the book, would you summarize
         | what you liked about that interview?
        
           | pjmlp wrote:
           | Something I quote regularly, regarding how C was hardly
           | impressive in terms of performance quality in generated
           | native code.
           | 
           | As anyone coding in the 1980's home computers knows, any
           | junior doing Assembly could easily beat those compilers.
           | 
           | It was the abuse from UB in optimising compilers that
           | eventually made the difference.
           | 
           | "Oh, it was quite a while ago. I kind of stopped when C came
           | out. That was a big blow. We were making so much good
           | progress on optimizations and transformations. We were
           | getting rid of just one nice problem after another. When C
           | came out, at one of the SIGPLAN compiler conferences, there
           | was a debate between Steve Johnson from Bell Labs, who was
           | supporting C, and one of our people, Bill Harrison, who was
           | working on a project that I had at that time supporting
           | automatic optimization...The nubbin of the debate was Steve's
           | defense of not having to build optimizers anymore because the
           | programmer would take care of it. That it was really a
           | programmer's issue.... Seibel: Do you think C is a reasonable
           | language if they had restricted its use to operating-system
           | kernels? Allen: Oh, yeah. That would have been fine. And, in
           | fact, you need to have something like that, something where
           | experts can really fine-tune without big bottlenecks because
           | those are key problems to solve. By 1960, we had a long list
           | of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60.
           | These are higher-level than C. We have seriously regressed,
           | since C developed. C has destroyed our ability to advance the
           | state of the art in automatic optimization, automatic
           | parallelization, automatic mapping of a high-level language
           | to the machine. This is one of the reasons compilers are ...
           | basically not taught much anymore in the colleges and
           | universities."
        
             | pmontra wrote:
             | I remember that excerpt from her interview and I'm with her
             | almost 100% and yet, if this is another case of worse is
             | better (we had a thread about that recently on HN) then
             | there was a definite demand for C. I was not yet around as
             | a developer but maybe those compilers were too expensive?
             | Did they require too large and costly machines? Did they
             | run on the computer people had at home? Etc.
        
             | AnimalMuppet wrote:
             | Thanks. (And I think I've seen you quote that here before.
             | I just didn't realize that this was what you were referring
             | to.)
             | 
             | Next question: _How_ did C do that? By becoming dictator?
             | No, it did it by persuading people that C was a better
             | direction than those other ecosystems. That is, _the other
             | direction lost the debate_. How and why?
        
             | kazinator wrote:
             | The problem is that C compilers have very advanced
             | optimizations. These make the language more dangerous. And
             | yet, the programmer still has to take care of it!
             | 
             | I have a litmus test. Every few years, I compile code which
             | does doubly-linked list operations:                 struct
             | node {         struct node *next, *prev;       };
             | /* Original: pred and succ must not overlap, but this is
             | not expressed. */            void insert_after_A(struct
             | node *pred, struct node *succ)       {         succ->prev =
             | pred;         succ->next = pred->next;
             | pred->next->prev = succ;         pred->next = succ;       }
             | /* Optimize with restrict: pred and succ do not overlap. */
             | void insert_after_B(struct node *restrict pred, struct node
             | *restrict succ)       {         succ->prev = pred;
             | succ->next = pred->next;         pred->next->prev = succ;
             | pred->next = succ;       }            /* Optimize by hand
             | in "load-store style". */            void
             | insert_after_C(struct node *pred, struct node *succ)
             | {         struct node *aft = pred->next;         succ->prev
             | = pred;         succ->next = aft;         aft->prev = succ;
             | pred->next = succ;       }
             | 
             | I'm consistently finding that the manual optimizations in B
             | and C are required to get the instruction count down.
             | 
             | Simply adding restrict is a simpler manual optimization,
             | but it's dangerous; now demons are allowed to fly out of
             | our noses when the arguments point to overlapping objects,
             | which doesn't happen in function C.
             | 
             | And what's the use of _restrict_ , when I can get the same
             | benefit by coding in a certain way.
        
       | torstenvl wrote:
       | Funny enough, I just bought this yesterday. I was having DNS
       | issues at work and trying random bookmarks, and happened to click
       | on https://www.joelonsoftware.com/2009/09/23/the-duct-tape-
       | prog... where it's highly recommended.
        
       | neves wrote:
       | Wow, more than 15 years old. I remember reading it in a vacation
       | and what really sticked with me was that all the luminaries
       | debugged using printf() :-)
        
         | HarHarVeryFunny wrote:
         | Me too - only thing I use a debugger for is analyzing core
         | dumps. Other debugging tools like Valgrind can occasionally be
         | useful to, but honestly a debugger is not the most efficient
         | way to find bugs!
        
       | nuncanada wrote:
       | Bought it just because of the interviews with Knuth and Norvig,
       | but it amazed me how fun and interesting was to read all the
       | other interviews also. Definitely one of my favorite CS books.
        
       | jrmg wrote:
       | The inspiration for this book, 'Programmers at Work', from 1986,
       | is also a gem:
       | 
       | https://www.goodreads.com/book/show/2092681
       | 
       | It contains interviews with 19 prominent programmers from that
       | era - some of who you'll definitely recognize. I remember
       | particularly enjoying the Tori Iwatani one - he's the creator of
       | PacMan.
       | 
       | The full list: Charles Simonyi, Butler Lampson, John Warnock,
       | Gary Kildall, Bill Gates, John Page, Wayne Ratliff, Dan Bricklin,
       | Bob Frankston, Jonathan Sachs, Ray Ozzie, Peter Roizen, Bob Carr,
       | Jef Raskin, Andy Hertzfeld, Scott Kim, Jaron Janier, Michael
       | Hawley
        
         | jrmg wrote:
         | [Replying to myself]
         | 
         | I read this ages ago and thought it might be a rare book - but
         | it looks like used copies are still available really cheaply.
         | Not sure if the second edition had updates - looks like it's
         | from 1989. Anyway, I highly recommend picking up a copy.
         | 
         | https://www.alibris.com/Programmers-at-Work-Interviews-Susan...
         | 
         | https://www.alibris.com/Programmers-at-Work-Interviews-with-...
        
       | jroseattle wrote:
       | This book is still on my shelf. When I first ordered and received
       | it, I sat down and read it cover to cover.
       | 
       | One of the things I really enjoyed was seeing how differently all
       | of the interviewees worked and went about their business. They
       | didn't seem to work that much differently from me, which made
       | their work that much more relatable.
        
       | braza wrote:
       | I really liked the stories and most of them are inspirational for
       | me; however I must confess that every time that I read such
       | remarkable histories and those guys doing relevant stuff; I feel
       | bad about the work that I do as a corporate software developer.
       | 
       | My day starts debugging some arcane shell scripts embedded in
       | some yaml in the CI tool; at afternoon I need to optimise some
       | SQL query moving several sub queries that makes the execution
       | plan costly and transform it in small steps in temporary small
       | tables; and before I leave I just noticed some bug in production
       | caused by wrong typing in Go and I need to fix it.
       | 
       | I mean, it's hard to think about the work that I am doing going
       | towards to a mastery state.
       | 
       | I really appreciate those histories, but for me it's more or less
       | watching Apocalypse Now from the perspective of a low level
       | cooker/dish washer on the grand scheme of things.
        
         | 082349872349872 wrote:
         | There are many things to be said for and against startups, but
         | working in an early stage (<12 people) startup is wonderful for
         | being able to actually build things.
        
       | ChrisMarshallNY wrote:
       | I never read that book, but I enjoyed _Software Craftmanship
       | "_[0].
       | 
       |  _> "The problem with object-oriented languages is they've got
       | all this implicit environment that they carry around with them.
       | You wanted a banana but what you got was a gorilla holding the
       | banana and the entire jungle."--Joe Armstrong_
       | 
       | That applies to almost every framework and dependency out there.
       | 
       | It's crazy to load a Web page, that adds almost 1MB of JS, so it
       | can animate something that could have been done with a couple of
       | lines of CSS.
       | 
       | [0] https://en.wikipedia.org/wiki/Software_craftsmanship
        
       ___________________________________________________________________
       (page generated 2023-12-28 23:01 UTC)