
\section{Herausgefischt: Pro und Kontra zu \\\hfill Visual Forth}

Neulich in der \texttt{Win32Forth@yahoogroups.com} ging es darum, ob man so etwas wie Visual Forth überhaupt braucht. Viel Meinung zum Für und Wieder, wenig Code, aber anregend fand ichs doch. Denn es werden recht unterschiedliche Programmierstile deutlich, wenn es darum geht größere Applikationen zu machen. Camille vertrat hier, soweit ich das erkennen konnte, noch allein, die Weiterentwicklung der \texttt{ForthForm} des {\sf Win32Forth} hin zu einem Visual Forth:

\subsection{Mittwoch, 22. Oktober, 2008 09:10 Uhr}
Wie ich Forth benutze, hatte ich hier in der Gruppe schon mal erwähnt (und das kann man auch als Antwort zum Thema \emph{Visual Forth} nehmen): 
Ich benutze die Forth--DLL als Kern, und das GUI (Graphical User Interface,  Benutzerschnittstelle) kann dann von einem beliebigen Softwaresystem kommen, etwa von Visual Basic, Visual C++, {\sf LabView} oder woher auch immer. Das ist sehr praktisch, auch weil einige unserer Auftraggeber ihre eigenen Oberflächen haben oder machen wollen (integrators).
Software als DLL vorliegen zu haben ist günstig. Das GUI kommuniziert mit der Kern--DLL über Zeichenketten (strings) in einer Syntax die vom Forth interpretiert wird. So dient Forth sogar als Model für ein MVC--Architektur (Mode--View--Controller [1]). Von daher habe ich gar keinen Bedarf an Visual Forth.
--- Yves 

\subsection{und .. 20:51 Uhr:} 
Neulich musste ich {\sf LabView} für einige Anwendungen benutzen. {\sf LabView} ist eine Programmiersprache in der alles \emph{visuell} erstellt wird. Man kann damit Programme machen ohne dafür auch nur eine Zeile Code tippen zu müssen --- alles von den Kontrollstrukturen bis hin zu den Berechnungen wird in Flußdiagrammen dargestellt. Ganz nett gemacht, aber nach einer Weile merkte ich, dass das textbasierte Entwerfen doch schneller geht. Was ich sagen will ist, dass visuelle Werkzeuge für die visuelle Gestaltung (GUI) gut sind, aber das, was das Programm machen soll --- die Logik --- macht man besser in regulärem Code. Ich fürchte das ein Visual Forth für die meisten Anwendungsfälle keine Verbesserung der Situation bringt.
--- Yves 

Da stimme ich zu. Die sichtbaren Teile einer Anwendung (oder eine Webseite usw.) mit gestalterischen Designwerkzeugen (visual tools) anzufertigen, macht Sinn, aber andere Teile werden besser in traditoneller Weise gemacht, also textbasiert.
--- Tom Dixon

\subsection{.. 21:54 Uhr} 
{\sf LabView} kenne ich gar nicht, aber der Beschreibung nach würde ich es auch nicht mögen. Das üble an Visual Basic oder so ist, dass man nicht an die Interna heran kommt. In Forth hingegen kann man das, auch in einem Visual Forth. Ich finde ein Visual Forth fügt nur eine Schicht Forth hinzu, und es verbietet ja nicht den regulären Forth--Code. Die Idee dahinter ist es ein integriertes Werkzeug (IDE) zu haben, das auch das Windows--Interface erzeugen kann (was eine Pein ist, wenn man es über regulären Code händisch erstellen soll), wobei das Herzstück des Codes immer noch regulärer Forth--Code ist. Und das es dann in Forth geschrieben ist, sodass wir eben keine fremden Werkzeuge benötigen.
--- Camille 

Genau das macht ja die \texttt{ForthForm} (des {\sf Win32Forth}). Es geht um einen Zusatz für die Eigenschaften der Form--Elemente (properties), also ein Feld in dem Forth--Code--Schnipsel für die Aktionen stehen können.
Diese legen schon in der Form fest, was die Schalter (pressing buttons) später machen sollen, anstatt dass diese Stellen dem generierten Code einer Form später 
hinzugefügt werden müssen. Dagegen bin ich gar nicht, solange der Editor dafür auf Scintilla [2] basiert und sich damit in die IDE einfügt --- oder einfach die IDE aufruft, und den Code dann in die Datei der Form ablegt statt irgendwo separat.
 
Ich habe aber auch nichts dagegen, wenn externer Code aufgerufen wird (wie die DLLs), wenn das den Job erledigt der ansteht, solange man den Code durch eine API (oder bei Daten per SQL) von Forth aus konfigurieren kann und das nicht erst anders programmiert werden muss.  
--- George 

\subsection{Donnerstag, 23. Oktober, 2008 00:22 Uhr}
Camille, Visual Forth ist bestimmt ein sehr interessantes Konzept von dem auch ich über Jahren geträumt habe, und erreichte den Stand einer einheitlichen Software--Architektur von den untersten Ebenen (low level code words) bis zu den höchsten (Rapid Application Development). Und mit OOP, das war unzweifelhaft ein größerer Fortschritt in Forth, 1000x Dank an Tom Zimmer und andere. Und ich gebe zu, dass ich etwas enttäuscht von der \texttt{ForthForm} bin, die doch recht eingeschränkt und dabei auch noch umständlich zu benutzen ist. Was mich angeht, liebe ich {\sf LabView}. Es ist die einzige Software die ich kenne, die es Studenten ermöglicht einen gutaussehenden Wellengenerator samt digitalem Oszilloskop in einem dreistündigem Praktikum zu erstellen. Man macht daraus EXEs, DLLs, es hat einen handlichen WEB--Server, um die eigenen grafischen Oberflächen mit einem WEB--Browser ansehen zu können, usw. Nur leider ist es keine freeware. ;-)
--- Yves 

\subsection{.. 12:49 Uhr}
Ich hatte nicht viel Erfolg mit der \texttt{ForthForm}. Kann an mir liegen oder an der Integration ins {\sf Win32Forth}. Wo der formspezifische Code am besten hin passt, weiss ich auch nicht, denn in Forth kann man machen was man will. Deides \texttt{*.f} oder \texttt{*.frm} kommen in Frage und sind von Hand anschließend  aus der IDE heraus editierbar. 
--- Georg

\subsection{Verweise}
\vspace{-1ex}
{}[1] Model--View--Controller (MVC, „Modell/Präsentation/Steuerung“) bezeichnet ein Architekturmuster zur Strukturierung von Software-Entwicklung in die drei Einheiten: Datenmodell (model), Präsentation (view) und Programmsteuerung (controller). So soll ein flexibler Programmentwurf entstehen, der spätere Änderung oder Erweiterung erleichtert, und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht.

Das MVC--Konzept wurde 1979 zunächst für Benutzungsoberflächen in Smalltalk durch Trygve Reenskaug beschrieben (Seeheim--Modell), der damals an Smalltalk im Xerox PARC arbeitete. Es gilt mittlerweile aber als De--facto--Standard für den Grobentwurf aller komplexen Softwaresysteme; teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC--Muster aufgeteilten Modulen. \ldots\\
Quelle: \url{http://de.wikipedia.org/wiki/MVC}

{}[2] Scintilla ist ein Werkzeug um Texte zu erfassen und zu edieren. Der Quellcode liegt vollständig offen vor, und die Lizenz erlaubt den Gebrauch in jedem freien oder kommerziellen Produkt.\\
Quelle: \url{http://www.scintilla.org/}

Viele Grüße, Michael


