Prominent geworden ist diese Idee durch das an der Universität San Diego, Kalifornien, entwickelte UcsdPascal System, das Anfang der 80er Jahre für die Ausbildung der Informatik Studenten auch hier in Deutschland eingesetzt wurde. Es wurde u.a. auch auf den legendären Apple II portiert. Auch frühe Implementationen für SpracheSmalltalk fallen in diese Ära, Smalltalk-80 spricht jedoch von ByteCode (siehe Bluebook).

Nachteil dieser Idee war, dass die Interpretation des PseudoCode in Software langsamer ist als die Ausführung von NativeCode auf einem Prozessor. Dies hat den Siegeszug von TurboPascal unterstützt, das Ende der 80er Jahre UcsdPascal fast überall verdrängt hat.

In jüngerer Vergangenheit erlebt das Konzept durch die JavaVirtualMachine und die Microsoft CommonLanguageRuntime (Siehe DotNet) eine Wiederbelebung. (Siehe auch "Sun Invites IBM, Cray To Work On New Computer Language".)

Interessant wird dieses Konzept vor allem dann, wenn es durch einen JIT-Compiler ergänzt wird. Der PseudoCode wird dabei (JustInTime) in - hoffentlich optimierten - NativeCode verwandelt und läuft dann annähernd so schnell wie ein direkt in NativeCode compiliertes Programm.

In bestimmten Situationen könnte JIT-compilierter PseudoCode sogar schneller laufen als NativeCode, nämlich dann, wenn auf der Zielmaschine auf die speziellen Eigenschaften der jeweiligen CPU optimiert wird. Zum Beispiel könnte JIT-optimierter Code auf einem Opteron oder P4 schneller als generischer x86-Code laufen.

Eine ausgezeichnete Stoffsammlung kann man bei den Ruby-Leuten finden, siehe http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/. Für SpracheRuby gibt es derzeit nur einen Interpreter und noch keine schnelle VirtuelleMaschine. Siehe auch http://www.rubygarden.org/ruby?CardinalProject und http://www.parrotcode.org/ (VM Entwicklung für Perl6). Unter http://www.alumina-vm.org/AluminaWiki/ wird versucht, Ruby in einer Smalltalk-VM laufen zu lassen.