I’m sorry, but I am totally opposed to this. It is a bad idea if we are talking about analytical differentiation and a very-very bad idea if it’s about numerical differentiation.
- Analytic computation of derivatives is a job for Computer Algebra Systems (CAS), and they are very good at it. I see no reason to bloat a programming language to a semi-CAS - which will never be as good as the many CAS already existing for decades anyway.
I personally use Maxima (after ditching Mathematica years ago) for several reasons. Maxima (and pretty much all CAS) even have a command to “export” the resulting derivatives in F90 form, which you literally copy and paste in your Fortran program. Where is the need to bloat Fortran itself with that feature? - Numerical differentiation is not easy. In fact it is usually much harder than integration. But let’s say it is not. Which method will be used? Finite differences? Why not using a spline - if the function is smooth enough, it’s a better method. But cubic splines will also require tridiagonal Gaussian elimination, right? And while we are at it, why not adding a ship load of other “LAPACK-ish” methods as well? But then again, isn’t all that what the countless numerical analysis packages already available for ages now are for?
I see no reason to give the novice programmer yet another way to avoid learning anything and just use the built-in differentiation, integration, whatever else the language itself provides. I can tell from experience the vast majority of students will stick to this method (because it’s easier) without having the slightest idea what’s the pros and cons of using that specific method, when that built-in method is to be used and when it’s not a good idea using it, or even what’s its name.
Years ago, I released a Numerical Analysis package for a specific machine. The package offered several ready-made numerical methods. The shooting method for solving boundary-value problems was quite popular in the small community of users. But of course you had to supply a Jacobian, and I did the mistake to add an “auto” option which could be used to skip the analytic Jacobian by using a (finite differences) numerical approximation instead. I did add a note - with big fat letters in the manual - saying something like “always supply the analytic form of the Jacobian, its automatic numerical approximation is not recommended unless you know what you are doing”. I assumed this will prevent users from using it unless in special cases. Guess what, none ever bothered computing the Jacobian. Literally none ever asked anything about it, they just used the built-in “automatic” option, essentially numerically approximating the Jacobian, and I doubt most of them even knew what method was used in the package for said approximation. They even released their own packages solving specific problems using that numerical approximation. Since then, I learned my lesson, never give the user too much “convenience”, because they will use it. Every time, all the time.