TS
Sign In
Knowledge Base
Detailed Notes||6m 44s

Modern Languages Don't Help Solve Hard Problems (Jonathan Blow)

https://www.youtube.com/watch?v=v6497Z9E9B0

Here are detailed notes from the transcript:

Detailed Notes: Programming Language Design for Hard Problems

Main Topic: The speaker is designing a new programming language, motivated by the unique and complex challenges faced in game development, aiming to address "truly hard problems" and improve the programmer experience, which they feel has stagnated for decades.

Key Points and Arguments:

  1. Critique of Traditional Language Design (0:02-0:16):

    • Historically, languages are designed in academic or business settings for relatively simple problems.
    • This approach fails to address the unique difficulties of game development.

  2. Game Development's Unique Challenges (0:21-0:39):

    • Game development often hits problems earlier and in more complicated ways than other industries.
    • The speaker's goal is to design a language specifically based on this experience to solve "really hard" problems.

  3. Distinguishing "Hard" from "Not That Hard" Problems (0:43-1:45):

    • Many language features focus on problems that are "not that hard," which might be constant frictions but not "brick walls."
    • Example: Memory Leaks (0:59-1:32)
      • Many complex systems are put in place to manage memory freeing.
      • Speaker's Argument: Memory leaks are "not actually very bad" during development. Games are restarted frequently, so leaks typically don't accumulate to a critical point until late-stage hardening.
      • Speaker's Solution: If code is too complicated to understand when to free memory, simply simplify the code (1:40-1:43).
    • True Hard Problems (1:45-1:55):
      • Knowing "how the game should behave."
      • Determining "what should this system be like."
      • The need to "rewrite this three times for it to be the right thing."

  4. The Importance of Iteration and "Disposable Code" (1:55-2:46):

    • Speaker's Philosophy: It's crucial to be able to "rough draft" code, treating it as "a little bit disposable" and not production code for a long time until the design is figured out. Only then should it be "hardened" (e.g., fixing memory leaks, refining logic).
    • Critique of Rust's Philosophy (2:13-2:28):
      • Rust's mindset is that "all code is production code."
      • Speaker's Argument: This mindset is "deadly" for game development. Slowing down the iteration loop by "10 or 15%" would have caused previous projects to fail or result in worse games because they were already "so hard to program."
      • Making development harder prevents the speaker from being able to create games.

  5. Identifying the Actual Hard Problems (2:47-3:10):

    • "I don't understand my program. It's too big and complicated." (2:50-2:53)
    • Debugging takes too long, and the problem is unclear. (2:55-2:59)
    • Having to write "big systems that are a little bit error prone because the language doesn't have features to help me out." (3:03-3:09)

  6. The "Programming Sucks" Problem (3:24-4:10):

    • Personal Anecdote: Started programming at 10, found it exciting and fun ("10 print hello," made a game).
    • Current State: As a professional programmer, programming "sucks and is horrible," and "makes me an unhappy person."
    • Argument: This is "most programmers' experience" and represents a fundamental problem that could be solved, yet no one focuses on it, instead worrying about memory freeing.
    • Goal: Attack the problem of why "programming sucks" and make it enjoyable again.

  7. Speaker's Language Design Goals and Philosophy (4:14-4:48):

    • Aims to "get rid of some of the problems" that make programming suck.
    • The new language is "decidedly a systems language" – not for non-programmers or those who don't want to think about memory.
    • The goal is to move the line on "real problems," even slightly, as the speaker believes this line hasn't moved for a long time.

  8. Critique of C++ (4:50-5:26):

    • C++ was an attempt to improve C, but "a few things from C++ help, but it's really just a few."
    • Speaker's Opinion: "Most of the features in C++ don't help at all and in fact make things worse."
    • Speaker's Usage: Doesn't use anything after C++11. From before C++11, avoids multiple inheritance, barely uses templates, and doesn't use the standard library ("a giant mess").
    • Notes that a "subfield of programmers" shares this attitude.

  9. Stagnation in Language Design (5:27-6:00):

    • References a conversation with Casey Muratori about future language design focusing on massively parallel computing ("wavefronts").
    • Speaker's Counter: Believes that language design "stopped in the 1990s."
    • Speaker's Goal: To create "what should we have made even in 1996, like what would have been the next step forward back then?" because language development has been stagnating for that long.

Important Facts or Data Mentioned:

  • Game development: Hits problems earlier and more complicated than other industries.
  • Iteration slowdown: A "10 or 15%" slowdown in the iteration loop can cause projects to fail or result in worse games.
  • C++26: Rumored to add reflection/introspection (speaker expects it to be "the worst thing ever").
  • Speaker's C++ usage: Does not use anything after C++11; avoids multiple inheritance, barely uses templates, and does not use the standard library.
  • Casey Muratori: Discussed the future of CPU architecture (massively parallel/wavefronts) in relation to language design.
  • Perceived stagnation: The speaker believes programming language design has stagnated since the 1990s (specifically mentions 1996).

Conclusions or Recommendations:

  • Re-evaluate language design priorities: Shift focus from "easy" problems (like basic memory management) to the "truly hard" problems of program comprehension, effective iteration, and programmer well-being.
  • Embrace an iterative development style: Languages should support rough drafting and disposable code, allowing developers to figure out solutions before hardening them.
  • Address programmer dissatisfaction: Design languages that make programming fun and exciting again, moving away from the current professional experience described as "sucks and is horrible."
  • Focus on fundamental improvements: Seek to implement core advancements in systems language design that have been missed since the 1990s, rather than just adding incremental features or focusing on niche problems.
Generated with Tapescript
7f0104f - 03/02/2026