Das Programm Visual Paradigm, das in der Veranstaltung Softwaretechnik benutzt wird, verwendet DND-Editing. Hierbei kann man beispielsweise eine Klasse zu einem Diagramm hinzufügen, indem man das Symbol in der Palette anklickt und im Diagramm an die gewünschte Stelle klickt. Hier ist es auch möglich, aus Code Diagramme automatisch erstellen zu lassen und umgekehrt. Es sind also beide Herangehensweisen an die Modellierung (textuell und graphisch) möglich, die sich passend ergänzen. Das im Hardwarepraktikum verwendete Simulationsprogramm ISE Xilinx macht ebenfalls extensiven Gebrauch von Drag-and-Drop-Editing. Die Benutzerschnittstelle ist komplett mausbasiert; abgesehen von Eingaben in VHDL ist keine textuelle Beschreibung der Funktionalität möglich. Insbesondere ist es nicht möglich, die Verdrahtung der Bauteile so zu beschreiben, sondern der Benutzer muss in Kleinarbeit Bauteile und Leitungen legen und wird nicht daran gehindert, Freveltaten wie die im Artikel "Why Looking Isn't Always Seeing" (dort Abb. 2) genannten zu begehen. Hier wären Alternativen wünschenswert und unserer Meinung nach auch durchaus machbar. "Verbinde den Übertragsausgang des Halbaddierers H mit dem Exklusiv-Oder-Gatter G" ist einfach textuell beschreibbar, zum Beispiel indem man sich an die Einführungsvorlesung "Programmierung" bei Michael Hanus erinnert, der eine Schaltungssimulation in Scheme vorgestellt hat, vgl. Harold Abelson, Gerald Jay Sussman, "Struktur und Interpretation von Computerprogrammen", Springer Verlag, 4. Auflage 2001. Warum ist hier eine textuelle Beschreibung (besser) geeignet? Weil es im Hardwarepraktikum nur auf das Verhalten des modellierten Systems ankommt und es unerheblich ist, welches Aussehen und welche Abmessungen die modellierte Schaltung in der Realität hätte. Andererseits ist hier jedoch zu bedenken, dass das unmittelbare graphische Aufbauen der Schaltung dem Hantieren mit realen Bauteilen erheblich näher kommt als die textuelle Beschreibung des Verhaltens und deshalb nicht von vornherein abzulehnen ist.