HN

Comments (138)

• Menu

  Almondsetat
  I think Casey is currently the most informed person to make a series of books or articles summarizing the history of SW Engineering, all the lessons learned and forgotten, and all the good stuff that was published and still hasn't gained traction in the practice
• Menu

  FacelessJim
  Terrific presentation. But I have a comment:His dismissal of the argument Knuth makes regarding the hot loops could have been explored a bit better. I found it weird he didn’t mention the difference of types of programs of then vs now. Even today, in scientific code it is still absolutely the case a lot of the time that a huge chunk of the runtime comes from a single very very hot loop. It might be hidden in a library, but it’s there. Instead he focuses only on “program size”. Knuth samples where very small FORTRAN programs (compared to today’s standards). Today’s program are bigger but the fundamental number crunching primitive of “let’s compute stuff in a loop” remains. It’s just buried under a pile of extra cruft (data loading, parallelism, dispatching etc).Now we just deal with a lot more programs that are of a whole different class compared to what they where doing with computers in the 70s. We have much more I/O involved. And hot loops don’t like being I/O bound.
• Menu

  torginus
  Personally I'm quite sure this is super interesting, but I don't really have 3 hours to listen to this, even 1.5h at 2x speed is too much.I would very much prefer something written down, so I could absorb this at my own pace. I know, gift horse, but still.
• fantasizr
  I took notice when he breaks down the ethics of gen ai as it pertains to online theft, that AI broke the natural order of putting content online where you'd trade exposure for use https://youtu.be/bjO-s4rNPlY?si=uAtBTb6V_Sw1puBU&t=2244
• Menu

  ex-aws-dude
  What I don't understand with both Muratori/Blow is that they seem to be incredulous that someone wouldn't just make software high quality and fast for the sake of itLike they can't comprehend the fact that these things only happen if there is an incentive for itI think its because they work in games where there is a business incentive for performance, users care a lot if framerate suffers in a gameThey are so used to working in games that they take it for granted that the business incentive for performance existsAs someone who has worked in both AAA games and big tech it just comes across as a bit naive to me
• Menu

  kshallvari
  THE LEGENDARY GAME PROGRAMMER
• Menu

  cuechan
  He is just legendary when it comes to game programming
• register
  What is the thesis of his talk? Is it worth viewing?
• Panzerschrek
  It's a common situation for many quotes of such kind. Taken out of context they loose or completely change their initial meaning.
• mberning
  Will have to give this a watch after the kids go to bed. I like a lot of Casey’s views even if I don’t agree with them.
• dkersten
  I enjoyed this talk. It’s long, but it’s interesting and goes into a lot of “lost” history.
• Menu

  tialaramex
  tl;dr the saying is that "premature optimisation is the root of all evil", and Casey burrows into contemporary data to show that really although the claim was 3% of the code takes up 90% of the runtime even then it was more likely 4% takes 50%.The best thing you could take away from this lecture is something a reasonable person should take away from the original "root of all evil" saying anyway. Measure. Measure. Measure. If you aren't measuring that's not optimization it's masturbation.Ironically in the process of measuring for a third time yesterday I tripped a bug in Bill's language for which I opened an issue. This is not the goal of measuring three times but merely a happy accident.Along the way Casey discovers (?) that Structured Programming means just what we today call programming†, that software was a lot smaller in the days when 4096 bytes of RAM was a good entry level option and that loads of these famous people from 1970s computer science knew each other.† And knowing about this is one reason the Structured Concurrency people want that everywhere. Very possibly there's a future where it seems silly that people once wrote programs which did not use structured concurrency.
• jdw64
  Do not guess. Measure, but only measure the bottlenecks that threaten the business
• perkinsResearch
  Legend
• jeffrallen
  It's premature optimization, according to the video description.