Exercise 2: Why the Historical Distinction Explains Reputations, Not Current Capabilities — Possible Solution ==================================================================== WHAT THE HISTORICAL DISTINCTION ORIGINALLY DESCRIBED ------------------------------ Per this chapter, TensorFlow originally used define-then-run (a static, pre-built computation graph) while PyTorch used define-by- run (eager execution) from the start — a real, accurate description of how each framework actually worked at the time, and the direct cause of PyTorch's own research-friendliness (Exercise 1's own topic) and TensorFlow's own early deployment-efficiency advantage. WHAT SPECIFICALLY CHANGED SINCE THEN, PER THIS CHAPTER ------------------------------ Per this chapter, "TensorFlow 2.x adopted eager execution by default, following the field's own clear preference." TensorFlow itself no longer requires the awkward, debugging-unfriendly define-then-run workflow as its default mode — it now behaves, by default, essentially like PyTorch's own original eager-execution model, directly addressing the exact weakness that originally distinguished the two frameworks. Separately, per this chapter, "PyTorch, in turn, added its own graph- based optimization and deployment tools (TorchScript, torch.compile)" — PyTorch acquired graph-based capabilities of its own, the exact strength that originally distinguished TensorFlow specifically for production deployment and optimization. WHY THESE TWO CHANGES TOGETHER MEAN THE ORIGINAL DISTINCTION NO LONGER HOLDS ------------------------------ The original distinction was a genuine EITHER/OR: TensorFlow had graph- based efficiency but not eager-mode debuggability; PyTorch had eager- mode debuggability but not graph-based efficiency. With TensorFlow now defaulting to eager execution AND PyTorch now offering graph-based tools, both frameworks currently offer BOTH capabilities — the distinguishing either/or framing that once cleanly separated them no longer accurately describes what either framework can actually do today. WHY THE HISTORICAL FRAMING STILL EXPLAINS REPUTATIONS ------------------------------ Per this chapter's own later section, PyTorch remains dominant in research/academic settings while TensorFlow remains strong for mobile/ edge and browser deployment — these current-day reputations and ecosystem strengths trace directly back to which capability each framework originally built its own community, tooling, and library ecosystem around, even though the underlying technical gap that originally justified those reputations has since narrowed considerably. A research community that adopted PyTorch early for its own debugging advantages, and built years of tooling, tutorials, and published work around it, doesn't necessarily switch away simply because TensorFlow later closed that specific technical gap — the reputation and ecosystem persist independently of the original technical cause. WHY THIS DISTINCTION MATTERS FOR MAKING AN ACCURATE CLAIM TODAY ------------------------------ Describing PyTorch as "the eager-execution framework" and TensorFlow as "the graph-based framework" today would be technically inaccurate, since both now support both modes. The historically accurate description is instead about WHY each framework's own community and tooling ecosystem developed the way it did — a claim about history and resulting reputation, not a claim about either framework's own current, present-day technical capability set. WHY THIS WORKS AS AN ANSWER ------------------------------ It identifies precisely what each of the two named updates changed about each framework's own current capabilities, explains why this means the original either/or technical distinction no longer holds, and explains why the historical framing nonetheless remains accurate as an explanation for each framework's own present-day reputation and ecosystem strength.