Skip to content

Instantly share code, notes, and snippets.

@dchest
Created December 29, 2011 18:00
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dchest/1535291 to your computer and use it in GitHub Desktop.
Save dchest/1535291 to your computer and use it in GitHub Desktop.
N. Wirth - Good Ideas, Through the Looking Glass 2005 (extract)
5.5. Using wrong tools
Using the wrong tools is obviously an intrinsically bad idea. The trouble is
that often one discovers a tool’s inadequacy only after having invested a
substantial amount of effort to 24 build and understand it, and the tool thus
having become “valuable”. This happened to the author and his team when
implementing the first Pascal compiler in 1969.
The tools available for writing programs were an assembler, a Fortran and an
Algol compiler. The latter was so poorly implemented that we did not dare rely
on it, and work with assembler code was considered dishonorable. There remained
only Fortran.
Hence our naïve plans were to construct a compiler for a substantial subset of
Pascal using Fortran, and when completed, to translate it into Pascal.
Afterwards, the classical bootstrapping technique would be employed to
complete, refine, and improve the compiler.
This plan, however, crashed in the face of reality. When step one was completed
after about one man-year’s labor, it turned out that translation of the Fortran
code into Pascal was quite impossible. That program was so much determined by
Fortran’s features, or rather its lack of any, that there was no other option
than to write the compiler afresh. Fortran did not feature pointers and
records, and therefore symbol tables had to be squeezed into the unnatural form
of arrays. Fortran did not feature recursive subroutines. Hence the
complicated table-driven bottom-up parsing technique had to be used with syntax
represented by arrays and matrices. In short, the advantages of Pascal could
only be employed by a completely rewritten and restructured, new compiler.
This “incident” revealed, that the apparently easiest way is not always the
right way, but that difficulties also have their benefits: This new compiler,
written in Pascal, could not be tested during development, because no Pascal
compiler was available yet. The whole program for compiling at least a very
substantial subset of Pascal, had to be written without feedback from testing.
This was an exercise that was extremely healthy, and it would be even more so
today, in the era of quick trial and interactive error correction. After we
believed that the compiler was “complete”, one member of the team was banned to
his home to translate the program into a syntax-sugared, low-level language,
for which a compiler was available. He returned after two weeks of intensive
labor, and a few days later the first test programs were compiled correctly by
the compiler written in Pascal. The exercise of conscientious programming
proved to have been extremely valuable. Never contain programs so few bugs, as
when no debugging tools are available!
Thereafter, new versions, handling more and more of Pascal’s constructs, and
producing more and more refined code, could be obtained by bootstrapping.
Immediately after the first bootstrap, we discarded the translation written in
the auxiliary language. Its character had been much alike that of the ominous
low-level language C, published a year later. After this experience, it was
hard to understand that the software engineering community did not recognize
the benefits of adopting a high-level, type-safe language instead of C.
-- From N. Wirth - Good Ideas, Through the Looking Glass, 2005
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment