NAG Fortran 编译器的历史
前史
那年是 1988。Fortran 标准正陷入一团混乱的年代。
委员会重新检讨了 Fortran 标准 ISO, X3J3 (美国 Fortran 协会自那时改名为 J3)，大致上的争论有三个论述：
- 改革派：希望能大量的带入较先进的语言形式 (大部分的使用者)。
- 遵循传统派：希望能固定语言标准，或者只需要做些小部分的改变 (大部分的厂商)。
- 温和派：希望将语言稍微加入较为现代化的语言形式，但不像改革派的人所要求的那么多 (一些使用者与厂商)。
在 1987 年公开的讨论后，这三派的拥护者无法取得共识。传统派说新的语言建议无法实现。温和派的人说 那些建议的语言标准太复杂了，除了他们个别想要的功能外 (但是不同的人有不同的想法)。改革派的人说其他人只是想要将 好的东西拿掉将新的语言破坏掉罢了。(实际上，有许多的点子更加的复杂，但在那时这是很合理的简化概念。)
法国的会议
到了 1988，在巴黎所举行的 ISO Fortran 工作小组会议中 (此委员会以 ISO/IEC JTC1/SC22/WG5 为名)，这些争论到了沸点。这个工作小组担负了修订 Fortran 标准的责任，尽管当时与现在 的技术工作基本上都是委由美国的委员会所负责。由于在美国委员会中面临此僵局，WG5 认为有责任去决定在新的语言中要加些甚么，因此， 大家讨论了那些争论点。
为了回应传统派拥护者所宣称 Fortran 语言是很复杂且笨重的，且没办法更动。在本次会议中 Salford Software 公司的 Julian Tilbury 与我演示了前期的 Fortran 8x (我们所修订的 Fortran 版本)，它是很适合生成与开发 Fortran 程序的编译器。我们花了三个月的时间从头开发，完成了这个演示。(这次的演示并不太顺利， 因为我们用的是法文的键盘。所以当我输入例子时，我必须闭起眼睛、或者紧盯着屏幕，并以我所记得键盘上的位置输入 ，而不要去看键盘上的文字。)
会议中，WG5 决定将 Fortran 标准采逐步朝向较现代的方向调整，以回应各社群的期盼，并具体指明那些功能需要包含在其中。 因为预期能快速的完成这些工作，WG5 建议新的语言叫做 Fortran 88，然而所花的时间远较期望的要久，所以后来就成为 Fortran 90。
NAG 的想法
NAG 拥有许多优良产品，但是其最主要与重要的产品是 Fortran 语言的数值算法库。很显然的，NAG 会持续提供 最佳的 Fortran 数值算法库，也持续关注 Fortran 语言在程序语言中的市场占有率。同时 NAG 也相信 Fortran 语言必须要 更为现代化，否则就会被市场所淘汰，所以 NAG 支持了这次的会议，并参与其中 (也协助了 1988 年的演示工作)。
NAG 需要能够尽快使用 Fortran 90 编译器，以便其能够在编译器普遍之前就能将 Fortran 算法库产品备妥。 此外，在开发阶段能够成功使用 Fortran 66 与 77 的工具，来开发属于 Fortran 66/77 的数值算法库外，也希望同时能够使用 Fortran 90 的编译器。NAG 也有自行开发编译器的想法，除了能够刺激其他们编译器厂商外，也能确保在某些特殊平台上 没有编译器厂商支持时，仍然能够使用自己的编译器进行产品开发。
所以，我开始开发编译器...
那是在 1990 年春末，在与 NAG 其中一个董事讨论到 Fortran 语言的未来时， 会谈中他建议我，或许可以自行开发一个专属的编译器支持此新的 Fortran 语言。我回答说：当然！我想我可以做这样的事， 我长期就对程序语言的设计与实现深感兴趣，而且我在大学时期也确实设计了一个语言并为其开发了一个编译器 (当然，那比 Fortran 90 要小得多了)。
或许我不应该对事情的转变感到讶异... 第一，我的经理问我说我需要多久的时间开发编译器 (我回答："肯定需要 一年多的时间，大约要 15 个月")。下一件我所知道的事就是这变成了我的任务，而且我的截止时间就是 15 个月。 不用说，在那段开发期间，我费尽了所有的精力，且比过去花在任何产品上更久的时间。
第一个要做的决策是需要决定目标机器或目标语言，以及用甚么程序语言进行开发。我决定都以 C 语言来实现， 以 C 来开发编译器，并产生 C 的程序代码。原因如下：
- 我相当熟悉 C 语言，且能够开发出能够跨平台的程序。
- C 语言的编译器相当普遍。
- 能够让编译器快速的移植到新的系统上。
- 我能够使用 C 编译器的优化功能，能够减少 Fortran 编译器需要自行进行优化处理的时间。
我孰悉大部分 Fortran 90 的功能，因为在其他的程序语言中早就有类似的功能了。 唯一剩下的一个简单问题便是要多少功能以及要让它如何运作。
高性能的问题
我相对较陌生的语言功能是数组语法与数组运算。在第一版发布时，正确性是远远比性能更为重要的事， 我采用了较为简单的方法来处理数组的表示式。因为我不确定如何正确的处理整个数组表示式，但是 知道如何处理数组中的每一个元素，所以每个数组的语句都会被拆成许多个单一的计算，并将结果暂存在数组中。 这个方法在确保计算的正确性上相当的成功，但很不幸的却让整个计算相当没有效率。(也正因为如此， 在稍后几年第 2.0 版推出时，我便将整个数组表示语句的处理部分全部重写。)
另一个重要的问题是如何测试编译器。针对 Fortran 77 的功能，我们可以透过原有的测试组件进行测试。 对于数值计算的精确度，我们有自己的测试程序与算法库。对于所有的新功能来说，很显然的几乎没有任何存在的 测试程序 - 只有在标准中所列的少许示例以及 Mike Metcalf 与 John Reid 所写的 "Fortran 90 Explained" 这本书 (我们发现这本书对新的 Fortran 语言标准，解释的相当清楚， 所以我们决定用它当作编译器的手册)。
在开发时期，我写了许多特别的测试程序，但那是无法确保一起使用时是否能正常运作。我们知道 Brian Smith 等人已经写好了测试程序包，所以我们交换使用编译器的原型，并用来测试那些测试程序，当编译器有误时，将会有错误报告输出。这样的过程是无价的，若没有它，我们将会多花数个月的时间才能让 编译器达到可以发表的水平。
在 1991 年春天，我突然觉得我需要自整天的编译器开发工作中脱离，所以在晚上的时间我决定组装一台车 (Caterham Super Seven)。 似乎组装车子比编译器的开发工作简单多了，所以我先完成了车子的组装！
在经过多次的测试与考验后，编译器终于在 1991 年的 9 月推出 (是世界上第一个 Fortran 90 编译器)， 而几乎是在同一时间 Fortran 标准才公布出来。
在我全心进行编译器开发的同时，我所获得最大的回报就是：我的任务不仅仅是继续维护与支持编译器，还要扩充与强化 新的语言标准与功能 (HPF、再来是 Fortran 95、现在是 Fortran 2003)，用户对扩充功能的需求 (包含了许许多多， 大部分是对旧式 Fortran 风格的支持)，更高的运行性能，以及更多编译期与运行期的错误侦测功能。在我写这篇文章的时刻，此时的版本已经包含了大量的 Fortran 2003 功能，我正在持续进行开发中...
Malcolm Cohen 于日本东京, October 2004