The only formal notation with which most of our students are reasonably comfortable with, even as graduates, is a programming language. It thus makes sense to try to use a familiar programming language as the formal notation in which to describe the semantics of the programming language being studied.
Although somewhat unpopular with theorists, the use of programming languages to describe the semantics of other programming languages is hardly a novel idea: you do it every time you write an interpreter for language X in language Y.
Of course, writing an interpreter in the usual way is still far from trivial and does not spare the students from non-essentials like scanning and parsing. One way to address this is to trivialize scanning and parsing by adopting a LISP-like syntax for all of the languages studied, and to provide students with ready-made interpreters for subsets of these languages. This approach has been used with some success by Samuel Kamin of UIUC in his book ``Programming Languages - An Interpreter-Based Approach''[5].
My own approach is to make use of a compiler generating system which I have developed over the last few years. In this system, the scanner, parser and necessary scaffolding is generated from a single source file containing a BNF-like syntax definition. The rest of the specification is supplied in the form of Object-Oriented code written in a very high level language, constituting an interpreter for the language.
The structure of the system is such that students need not understand the scaffolding. Furthermore, since the semantics are written as Object-Oriented code, the similarities between different programming languages can be highlighted and exploited via code re-use between implementations.
Prof Herman Venter