I’m a teaching assistant in a C++ course for second-year physics students. The goal is to teach numerical and data analysis, but the course is structured around a very object-oriented style. For example, every function is defined through inheritance:

  class BaseFunction {
  public:
    BaseFunction();
    virtual double Eval(double x) const = 0;
  };

If students want to integrate or find the roots of a function, they must first subclass it:

  class SinClass : public BaseFunction {
  private:
    double _omega, _phase;
  public:
    SinClass(double omega, double phase);
    double get_omega() const;
    double get_phase() const;
    void set_omega(double new_omega);
    void set_phase(double new_phase);
    double Eval(double x) const override {
      return sin(_omega * x + _phase);
    }
  };

Everything in the course (numerical integration, PDEs, Monte Carlo sampling, …) follows this pattern.

The professor is an excellent teacher and students love him. But other faculty worry that our students leave without any real exposure to Python, and that they keep reproducing this heavy OOP style even in situations where a simple lambda or a few lines of NumPy would be far more natural. (Lambdas are shown at the very end of the course, but mostly as a curiosity.)

That’s why I found the blog post so interesting: it shows how natural code can look in Python or Fortran. By contrast, our students’ code is weighed down by boilerplate. It makes me think that sometimes the real difficulty in teaching numerical analysis isn’t the language itself, or whether arrays start at 0 or 1, but the teaching approach that frames every problem through layers of abstraction.