Meine Programme

" Um aus Fehlern lernen zu können
muss man erst einmal welche machen. "

Um eins gleich klarzustellen, hier gibt es keine Softuähr für Uindouhs oder solchen Käse, sondern nur echt coole Programme , mit ordentlicher Bedienoberfläche und dergleichen. Wer damit nicht klarkommt, sollte jetzt umkehren, denn es ist die letzte Chance.

Einige meiner Werke kann man übrigens auch im Aminet abgreifen. Viele der folgenden Links gehen direkt dorthin. Bei diesen Links genügt fürs Herunterladen einfaches Klicken. (Ich möchte gerne mal wissen, wie die das hinkriegen!) Erscheint beim einfachen Klick statt eines Filerequesters Textsalat im Browser, liegt das File offenbar auf dem Server meiner HomePage und dann hilft das Abspeichern des Textes. Da Netscape/PC in diesem Falle einem den Bärendienst erweist, die PC-typischen Zeilenenden (CR+LF) in die Archive einzubauen, muss man diese mit meinem Programm StripCRLF wieder entfernen. Möglich ist auch Anklicken bei gehaltener Shift-Taste oder die Speicher-Funktion aus dem Kontextmenü, wenn man mit Sicherheit den Filerequester bekommen will (das CR+LF-Problem bleibt aber).

" Ein Programm, das nicht abstürzt,
wird nur nicht richtig benutzt "

Kommen	Sehen	Siegen
Assampler	Was soll ich denn damit? Noch nie war Klangbearbeitung so kompliziert!	Gib vorsichtshalber mal her
Assampler debug Version	Ich? Fehler suchen? Niemand ist perfekt! Wahrscheinlich nicht mal der.	Wenn's sein muss
DelfLuxe	Klingt ja komisch Schicke Klangeffekte mit der Soundkarte Delfina	Das will ich haben
DelfSetPipeMui	Ist es das, was ich denke? Schafft die richtige Verbindung zwischen den Effektmodulen auf der Delfina.	Darauf warte ich schon lange
NomenEstOmen	Wofür brauch ich denn das? Überlasst doch dem Amiga die organische Nomenklatur!	Das wollte ich schon immer!
FotoBestellung	Was ist das? Fotonummern auszählen, ausdrucken, zuordnen	Her damit!
MasterMindSolve	Kann man das essen? Verschiedene Algorithmen zum Knacken von MasterMind-Codes	Reich mal rüber!
Compare	Was soll das schon sein?! Dateien und Verzeichnisse vergleichen	Muss ich haben!
SplitFile	Kurzbeschreibung Datei auf mehrere Datenträger verteilen	Herunterladen
StripUmlauts	Kurzbeschreibung Deutsche Umlaute in ae, oe, ue usw. konvertieren	Herunterladen
StripCRLF	Kurzbeschreibung PC-typische Zeilenenden (CR+LF) durch normale LFs ersetzen	Herunterladen
MemTest	Kurzbeschreibung Speichertest	Herunterladen
TableGroup.mcc	Kurzbeschreibung Verbessertes Anordnen in MUI-Spalten-Gruppen	Herunterladen
Wheel.mcc	Kurzbeschreibung Drehregler ähnlich denen an Musik-Keyboards	Herunterladen
sound.datatype- Entwurf	Beschreibt Unterstützung von 16 Bit, stereo und HD-Edit	Zeig mal
Module für Cluster	ständig unaktuell
MUI Interface	Kurzbeschreibung	Herunterladen
Kick3.0 Interface	Kurzbeschreibung	Herunterladen
Eigene Module	Kurzbeschreibung	Herunterladen

Amiga Seiten-Ring Vorige Seite Nächste Seite Übernächste Seite Vorvorige Seite 5 Seiten weiter Zufällige Seite

Contents page

Die Programmiersprache Cluster

"Müßiggang ist aller Cluster Anfang"

oder

"Andere nennen es Faulheit, ich nenne es Effizienz."
(frei nach Dr. Armin Kramer, seines Zeichens Mathelehrer am GCG)

Wer eine Programmiersprache sucht, die flexibel und elegant ist, und wer damit leben kann, dass die dabei entstehenden Programme nicht auf jedem anderen Rechner kompiliert werden können, der ist mit Cluster ideal versorgt. Denn kleine Programme gehen mit den mitgelieferten Standardmodulen schnell von der Hand. Ob angeforderte Resourcen wirklich bereitgestellt werden konnten und ob diese dann am Schluss auch wieder freigegeben werden, darüber braucht man sich dank Resource-Tracking und Exception-Handling keine Rübe zu machen. Genauso unterstützt Cluster den Programmierer bei großen Projekten durch Modularisierung und Objektorientierung (was Cluster übrigens als erste aller Amiga-Sprachen konnte, aber davon weiß heute kaum noch jemand etwas). Die Amiga-Programmierung wird noch speziell durch Shared-Libraries (bei Benutzung wie bei Eigenentwicklung) und Tags (mit Typecheck) unterstützt. Dann gibt es da noch Kleinigkeiten von großer Bedeutung, die man in anderen Sprachen vergeblich sucht: Mächtige WHILE- und IF-Struktur, lokale Prozeduren als Rückruf-Prozeduren (mit allen Konsequenzen), generische Module, Methoden auf Records, erweiterbare Records, umfassenderes Handling offener Typen (CLASSPTR) und und und ...

Da ergibt sich völlig berechtigt die Frage, warum Cluster auf dem Amiga nicht populärer ist als ModulaII und Oberon. Wahrscheinlich aus dem gleichen Grund, warum PCs ungleich mehr verkauft werden als Amigas: Standards, Standards, Standards und bloß nicht mal was neues und besseres wagen!

Vom Vokabular her ist Cluster ein Nachfolger von ModulaII (der derzeitige Compiler schluckt auch puren ModulaII-Code), aber eben noch mit einigen Besonderheiten anderer Sprachen gespickt, z.B. dem Exception-Handling aus Ada. Daher auch der Name Cluster. Selbst im C-basierten Kickstart findet man sich mit Cluster problemlos zurecht. Die Interface-Module für die Amiga-Libraries sind doch den C-Includes an Klarheit und Übersichtlichkeit locker überlegen, oder? Das Argument der C-Verfechter auf dem Amiga besser mit der Betriebssystem-Sprache zu programmieren, ist nur in sofern von Belang, dass man sich als Nicht-C-Programmierer selbst um die Interface-Module kümmern muss. Ansonsten braucht man in Cluster überhaupt keine Abstriche zu machen. Im Gegenteil, das meiste wird stark vereinfacht. Ich denke da nur an die Eröffnungszeremonien von Exec-Devices.

Hören wir nun einen Auszug aus der Promotionsarbeit von Dr. Frank Brandau mit Leerstuhl in Aachen. Ok, vergesst den Titel und den ganzen anderen Schmus. Jetzt kommt jedenfalls die Geschichte aus der Sicht eines Cluster-Programmierers erster Stunde, seit dem 21.10.1999 zusätzlich mit Korrekturen von Thomas Pfrengle, einem der Autoren von Cluster:

"Sicherlich ist C nicht so elegant wie Cluster und auch C++ bietet nicht die Möglichkeiten, die Cluster zur Verfügung stellt. Mir wurde schon einige Male von Professoren gesagt, die Dinge, die ich in Cluster mache, seien informationstechnisch unmöglich ;)"

Entwickelt wurde Cluster vom StoneWare alias Thomas Pfrengle und Ulrich Sigmund. Später sind sie auf X-Pert gestoßen und wurden gebeten, EGS zu entwickeln. Im Zusammenhang damit entstand das Viona-Team. "Dieses hat für X-Pert damals eine Graphikkarte entwickelt, die sagenumwobene Visiona. Viele halten diese Karte für ein Gerücht, wenige wissen mittlerweile etwas darüber. Da diese Karte aber in meinem Rechner läuft und sehr nette Eckdaten aufweist (Gallium-Arsenid Prozessor mit 135MHz, 4MByte VRam mit 15ns Zugriff), bin ich mir der Existenz dieser Karte sehr sicher (Kostenpunkt 4.000 DM, Anm. von Henning). Wenn man das Alter der Visiona berücksichtigt und dann daneben hält, das ein SetPixel immer noch schneller arbeitet als eine CyberVision64 (Leider fehlt ein Blitter auf der Karte, scrolling ist gnadenlos langsam), die Auflösungen eigentlich alles schlagen was vorhanden ist (z.B. 8000x4000 in s/w, nun, wer's braucht :), dann kann man sich doch vorstellen, was das Viona Team leistete. Um nun ein Betriebssystem für die Visiona zu schreiben (EGS), hat man keine geeignete Sprache im Amiga Markt gefunden. Daher hat man dort Cluster entwickelt und die Nähe zur praktischen Anwendung bedingte auch die Mächtigkeit von Cluster. Aus mir bekannten Gründen haben sich das Viona Team und X-Pert zerstritten und Viona verließ X-Pert.

Eigentlich sollte der Visiona ein EGS-Cluster beiliegen, aber die Rechte für Cluster lagen nicht bei X-Pert, nur die Visiona hat das Viona Team nicht mehr herausbekommen. Doch X-Pert hat Cluster immerhin vertrieben und kurze Zeit später war ich stolzer Besitzer der Version 1.0. X-Pert hat den Laden dann langsam in die Pleite bugsiert, Cluster wurde nicht mehr vertrieben und als ProDev die Arbeit an Merlin übernahm, war Cluster praktisch nicht mehr von Bedeutung. Die Entwicklung für GVP, die Viona dann geleistet hat, wurde aber dadurch bestimmt, dass EGS nicht mehr nur in Cluster geschrieben wurde. Allderdings hat Ulrich Sigmund weiterhin an Cluster gearbeitet und irgendwann vertrieb DTM dann Cluster 2.0. Eine reife Leistung, arbeitete Cluster doch vollständig objektorientiert, eine Neuerung, die damals praktisch unbekannt war. DTM hat allerdings so gut wie keinen Support geleistet, die Arbeit an Cluster wurde Viona überlassen, da DTM aber Hauptdistributor für GVP-Produkte war, wurde auch Cluster weiterhin im Vertriebsprogramm gehalten. Der Amiga war zu dieser Zeit noch auf dem Höhepunkt seiner Laufbahn, aber ernsthafte Anwendungen standen damals nicht im Vordergrund. So gab es nur wenige Leute, die programmieren wollten. Einsteigerprodukte waren Lattice und Aztec C, viele lernten C und Cluster wurde nur von wenigen beachtet, die schon einen ausreichenden Überblick auf die vielfältigen Programmiersprachen hatten. Als GVP anfing, sich zurückzuziehen, wurde die Finanzlage bei DTM kritisch, der abzusehende Zusammenbruch von Commodore tat sein übriges dazu. Cluster wurde dann nur noch als kleines Nebenprodukt gehandelt, was seiner Verbreitung arg geschadet hat. Modula2 und das neue Oberon wurden an Schulen und Universitäten gelehrt, wer sich mit Wirth's Müll herumschlagen musste, nahm die Umsetzungen für seine Amiga. Professionelle Programmierer erkannten schnell die Vorteile von C und arbeiteten damit, so entwickelten sich die Bedeutungen dieser beiden Sprachstämme. Cluster geriet damit völlig ins Abseits, entwickelt als Sprache für Entwickler, die aber C benutzten, brauchbar für Informatiker, die aus Kompabilitätsgründen aber Modula oder Oberon brauchten.

Letzter Punkt dieser traurigen Entwicklung war dann M.O.M. Dort wurde der Support für EGS übernommen, da das Viona-Team faktisch nicht mehr existierte. Damit kam auch die Entwicklung von Cluster zu M.O.M. (Und ich bekam endlich einen schon lange fertigen Treiber für EGS7 für die Visiona und konnte die Karte endlich dauerhaft als WB-Emulation einsetzen). Der Programmierer bei M.O.M. war von Cluster sehr angetan, und setzte einigen Enthusiasmus in das Projekt. Daraus resultierten dann die überarbeiteten 3.0/3.1 Includes, die dies auch bitter nötig hatten. Allerdings gab es keinerlei Resonanz mehr auf EGS, es war aufgebläht und fehlerbehaftet, Gerüchte um RTG und die neue CyberGraphics-Emu haben EGS den Rest gegeben. Ebenso erging es Cluster, die Spache war zu unbekannt und nicht verbreitet. Sprachpakete wie StormC haben Cluster schon seit einiger Zeit den Rang abgelaufen."

Irgendwie deprimierend, aber das letzte Wort ist ja noch lange nicht gesprochen. Das AmiNet stand auch einst kurz vor dem Aus und ist heute unangefochtenes Zentrum der Amiga-Programmierer-Gemeinde. Der Amiga selbst ist heute praktisch tot und trotzdem zweifelt kein echter Amigianer an der Wiederauferstehung. Warum also Cluster nicht auch eine Chance geben? Wir alle sollten gelernt haben, das es grundlegend falsch ist, heute eine an sich gute Sache aufzugeben, nur um uns der Allgemeinheit anzupassen. Wer heute die Vorteile des Amigas aufgibt und auf PC umsteigt, weiß mit Sicherheit, dass der PC innerhalb der nächsten 10 Jahre nicht totzukriegen sein wird. Er sollte aber auch wissen, dass das PC-Konzept der übertriebenen Aufwärtskompatibilität und auf der anderen Seite jede Menge Software-Standards, die untereinander unverträglich sind (siehe Dateiformate) der Innovation enge Schranken setzt. Genauso muss sich jeder darüber im Klaren sein, dass bestimmte Elemente in C nie (auch nicht in Amiga-Implementierungen) aufgenommen werden, weil sie nicht standardisiert wären und damit der Portabilität im Wege ständen.

Cluster ist nicht tot! Cluster wird nur ignoriert! Deshalb, setzt Euch mit MOM in Verbindung, ordert aktuelle Demo-Versionen, bewegt sie zum Weiterentwickeln oder zur Freigabe der Source-Codes!

Die (alte originale) Cluster-Demo könnt Ihr auch gleich eintüten. Folgende Komponenten nach Wichtigkeit sortiert gibts:

Den leicht gehandicapten Editor+Compiler
Den Grundstock an Modulen
Die Sprach-Definition
Ein Vektorgrafik-Bei-Spiel in Cluster

An dem mitgelieferten Editor, der die integrierte Entwicklungsumgebung darstellt, scheiden sich seither die Geister. Für Besitzer von Grafikkarten sicher keine große Freude, ist er für Amigas, die noch auf AGA/ECS angewiesen sind, eine schöne kompakte Arbeitsumgebung. Wer die Vorzüge seiner Grafikkarte nutzen möchte, kann aber mit der ARexx-Version des Compilers und seinem Lieblingseditor oder dem mitgelieferten Editor 'HiTex' (nicht so das wahre) arbeiten.

Trotz allem ist es nicht verkehrt, auch mal zu den verwandten Sprachen Modula und Oberon, Cyclone und der PD-Serie AMOK zu schauen. Artikel über Cluster in der c't 01/1992

Das Magic User Interface

"Es reicht nicht, keine Idee zu haben,
wenn man unfähig ist, sie nicht umzusetzen."

Was gibt es zu MUI zu sagen? MUI ist einfach MUI und als solches Spitze. Da man als Amiga-Benutzer sowieso nicht drumherum kommt, ist es wohl das beste, ins Aminet (Verzeichnis util/libs) oder zur (lange nicht mehr aktualisierten) SASG-Seite zu stiefeln. Dort steht dann auch, was MUI alles kann. Und für angehende MUI-Programmierer, und alle, die glauben, es schon zu beherrschen, ist die MUI-Mailing-Liste unentbehrliche Anlaufstelle.

Leider scheinen einige Programmierer eine krankhafte Antipathie gegen benutzerfreundliche Software und gegen Arbeitserleichterung zu haben. Die einen machen sich viel Arbeit mit GadTools und dem Bestimmen der Koordinaten für die einzelnen Bedienelemente, andere bauen sich eigene Routinen, um hier wenigstens auf unterschiedliche Font-Größen reagieren zu können. Wieder andere entwickeln gleich ein komplett neues GUI-System, das sie dann natürlich auch unter die Leute bringen wollen. Überflüssig zu erwähnen, dass so ein System immer "mindestens genauso gut wie MUI" ist (wenigstens wissen diejenigen, an wem sie sich messen müssen), weil es immerhin fontsensitiv ist. So wird argumentiert, aber dabei wird übersehen, dass MUI viele Kleinigkeiten anbietet (Hintergrundmuster, vielfältige Einstellungen von Farben, Element-Rahmen, Tastenkürzeln, Reaktionen auf Benutzereingaben, AmigaGuide-Hilfe, ARexx-Anbindung, Commidities-Unterstützung etc.), die zu implementieren es einfach den Aufwand nicht wert wäre, kämen sie nur in einem Programm zur Anwendung. Außerdem fängt man nicht ein neues Projekt an, wenn man nur das machen will, was andere schon erreicht haben. Da muss man schon was durchgreifend neues anbieten, um die investierte Zeit zu rechtfertigen.

Folgende zwei Beispiele für selbstgestrickte GUI-Systeme seien hier zur Abschreckung genannt: OctaMED und GoldEd. Ich würde sicher keine Worte darüber verlieren, sondern einfach zur Konkurrenz gehen, wenn es welche gäbe. Man darf das hier also durchaus als Wunsch nach entsprechenden Applikationen mit MUI-Interface verstehen. Leider haben die beiden Kandidaten neben der zweifelhaften Oberflächen-Philosophie ziemlich gute Funktionalität zu bieten.

OctaMED
Unser erstes Beispiel wurde dereinst von Teijo Kinnunen ins Leben gerufen und hatte sich unter den vielen Trackern als einer mit systemkonformer Benutzerschnittstelle und MIDI-Unterstützung profiliert. Dennoch war es nach fast zehn Jahren Entwicklung nicht verwunderlich, dass es dann nicht mehr einfach linear weiterging. Ob der Autor jetzt keine Lust mehr hatte, oder ob er in den PC-Bereich wechseln wollte - ich weiß es nicht, jedenfalls fiel OctaMED (irgendwann 1998 muss es gewesen sein) der Kato-Developer-Group in die Hände. Die hatte erstmal nichts besseres zu tun, als das ganze Programm umzukrempeln und unter anderem ein eigenständiges GUI-System zu entwickeln (worauf die Entwickler sehr stolz sind) das C++-Klassen benutzt, was für den Programmierer eine bequeme Handhabung bedeutet, für den Benutzer allerdings sinnlose Speicherverschwendung. Denn während GUI-Systeme in Exec-Library-Ausführung von jeweils mehreren Programmen genutzt werden können (bei konstantem Speicherverbrauch, da Exec-Libraries shared libraries sind), ist das bei statisch gelinkten Libraries unmöglich. Für den Anwender bedeutet das, dass in jedem Programm, das dieses System benutzt, alle benötigten Teile fest in den Programmcode eingebunden werden. Sollte das System tatsächlich in die Leistungskategorie von MUI aufsteigen, berücksichtigt man dennoch, dass in einem bestimmten Programm nie alle Elemente genutzt werden, dürfte damit jedes dieser Programme um ein halbes Megabyte größer werden, als eine entsprechende MUI-Applikation. Eine Entscheidung für den Benutzer ist das sicher nicht.
Aktuell (2001.08.21) sieht es so aus, dass es um die Wiederbelebung des OctaMED äußerst still geworden ist. Würde mich nicht wundern, wenn auch dieses Projekt beim Basteln an der äußeren Hülle steckengeblieben ist.

GoldEd
Auch der GoldEd (mit dem ich gerade diesen Text hier tippe) von Dietmar Eilert kann inzwischen auf eine längere Geschichte zurückblicken (ich glaube aber noch nicht ganz so lange, wie der OctaMED). Die Philosophie des GoldEds besteht in der absoluten Konfigurierbarkeit und der Unterstützung von Programmierern (dazu gehört eben auch, direkt vom Editor aus die Programme ansteuern zu können, die Quelltexte kompilieren, HTML-Seiten anzeigen, Skripte ausführen etc.) Da wäre es nur konsequent, das Konfigurationswunder GoldEd auf dem Konfigurationswunder MUI aufzubauen. Das passiert aber nicht. Der Programmierer hat keine Beziehung zu MUI und Punkt. Die Einstellerfenster sind daher nicht umgrößerbar, dafür wird eben die Mindest-Screen-Höhe auf 400 festgelegt, auf die der Editor eisern pocht. Das dürfte einen OCS/ECS-Besitzer wenig freuen. Dafür belehrt der Autor, dass das Programm ohnehin für Entwickler mit entsprechenden Maschinen gedacht ist. Selbst die werden aber keinen Spaß an einem GUI haben, dass wiederum ihren Platz auf dem Bildschirm nicht vernünftig ausnutzt. Aber Halt! Demnächst wird auch Umgrößerbarkeit implementiert, lässt er uns wissen. Da haben wir's den Entwicklern von frei verfügbaren GUI-Systemen aber wieder gegeben! Nur leider wird es bis dahin weitere Klassen und Extras für MUI geben, die GoldEd-Benutzern auf lange Zeit erspart bleiben. Toll wie der GoldEd-Autor für uns mitdenkt :-(

Wenn es nur das wäre, hätte ich den Texteditor hier nicht erwähnt. Das eigentlich ärgerliche ist, dass der GoldEd-Verfasser etwa seit der Version 3 (wir sind jetzt (23.04.1999) bei Nummer 5) den Flitz hat, alle möglichen Bedienelemente selbst von Grund auf neu zu programmieren, das allerdings nur sehr halbherzig (recht luftig, daher platzverschwendend, dennoch ohne grafische Besonderheiten) und der Windows95-Look ist auch nicht sehr originell. Hier kann man im direkten Vergleich sehen, wie viele Details in den entsprechenden MUI-Klassen verwirklicht sind. Die Liste der von Dietmar Eilert unnütz programmierten Bedienelemente umfasst bereits (in MUI-Äquivalenten ausgedrückt): Listtree.mcc, Popstring.mui, BetterString.mcc, Toolbar.mcc, TearOff.mcc, Registergroup.mui, Scroller in Fensterrahmen, (Kontext-)Menüs, Iconify, BubbleHelp, AmigaGuide-Hilfe. - Dafür hat jeder registrierte GoldEd-Benutzer bezahlt und sinnlos gewartet!

Wäre es wenigstens eine primitve GadTools-Oberfläche, könnte man ihr mit Patches wie MCP (Gadtools- und Stringgadget-Patch) zu Leibe rücken, es bestände in Zukunft vielleicht gar die Möglichkeit die Oberfläche komplett auszuwechseln, so aber entzieht sie sich hartnäckig allen Verbesserungsmöglichkeiten.

Ich denke mal, diese Zeit- und Speicherverschwendung wie in den oben genannten Beispielen muss wirklich nicht sein, insbesondere, wo es bereits mehrere GUI-Systeme gibt, die auch zum Teil erweiterbar sind, als da wären: MUI sowieso, ClassAct, StormWizard (wurde von Haage&Partner mit ClassAct zum neuen GUI für OS3.5 zusammengeschraubt), Triton, bgui, gtlayout und ich habe bestimmt noch welche vergessen.

Aber gut, ziehen wir einmal so eine klassische MUI/AntiMUI-Diskussion durch:

Kontra	MUI ist langsam. Die Reaktion auf Benutzeraktionen ist zu langsam für Echtzeit-Anwendungen. - Wir haben es ehrlich versucht!
Pro	Kann ich nicht bestätigen. Ich habe MUI bereits auf meinem Amiga benutzt, als er noch mit 68000/14MHz ausgerüstet war und es gab keinen Unterschied zu GadTools. Das Vergrößern von Fenstern dauert natürlich, es muss schließlich die gesamte Anordnung der Grafikelemente neu berechnet werden. Das muss aber sicher nicht in Echtzeit gehen. Für Programmierer: Es gibt Tricks, um ernste Engpässe abzufedern. Das kann man natürlich nicht wissen, wenn man es nur mal eben versucht. Für solche kniffligen Fragen gibt es übrigens auch eine Mailing-Liste! Möglichkeiten zur Geschwindigkeitssteigerung sind z.B. nach Häufigkeit sortierte Methoden-Verteilung im Dispatcher, auch nicht überdefinierte aber häufig gebrauchte Methoden wie Set ganz vorne in das switch-Konstrukt schreiben und sofort an die Super-Klasse weiterreichen, binäre Suche der Methoden (manche Compiler optimieren switch bereits auf diese Weise), Umgehen von zeitintensiven Methoden - Set gehört zweifellos dazu; wenn man neu eingeführte Attribute oft im Sammelpack setzen und abfragen möchte, schreibt man dafür besser eine neue Methode.
Kontra	MUI-Klassen sind eierlegende Wollmilchsäue und daher langsam und speicherintensiv.
Pro	Geschwindigkeit, siehe oben. Speicherverbrauch, ebenfalls siehe oben. Der Speicherverbrauch wird dadurch wett gemacht, dass mehrere Programme den gleichen Code nutzen können. Ansonsten sprechen die vielfältigen Fähigkeiten der MUI-Klassen doch eher für MUI - wäre das nicht so, hieße die Kritik wahrscheinlich, MUI sei nicht leistungsfähig genug.
Kontra	MUI ist fehlerhaft und stürzt gerne ab.
Pro	Ich hatte mit MUI 3.8 überhaupt keinen Absturz mehr, der durch MUI verursacht wurde. Fast immer stellte sich heraus, dass es ein Fehler beim Benutzen von MUI war. Manch andere Ungereimtheit gibt es dennoch, bisher ließen sich alle umgehen und das in jedem Falle schneller, als deswegen ein komplett neues GUI zu entwickeln. Übrigens wird MUI von sehr vielen Leuten benutzt und damit intensiv getestet. Was man von nebenbei entwickelten GUI-Systemen nicht erwarten kann, obwohl sie nicht minder fehleranfällig sind.
Kontra	MUI bietet die eine oder andere Klasse nicht, die ich dringend brauche. Oder die entsprechende Klasse kann nicht das, was ich benötige. Beispiel: Seitwärts Rollen in Listen.
Pro	Zum einen können bestehende Klassen um neue Fähigkeiten erweitert werden. Zum anderen kann man die Klasse immer noch durch eine komplett neue ersetzen, sollte sich ersteres nicht bewerkstelligen lassen. Jedenfalls entwickelt man deswegen nicht gleich ein völlig neues GUI.
Kontra	MUI braucht soviel Platten- und Speicherplatz.
Pro	Es ist klar, dass ein umfangreiches System umfangreiche Daten mitbringt. Aber ich denke die 2.5 MB Plattenplatz sind gut angelegt. MUI ist sehr schön in Libraries gegliedert und was nicht gebraucht wird, wird auch nicht eingeladen und nimmt daher keinen Speicherplatz weg. Nicht vergessen werden sollte, dass sich mehrere Applikationen automatisch MUI teilen, so dass im Prinzip nur für das erste Programm der Speicher für MUI fällig wird, alle weiteren bekommen es gratis dazu.
Kontra	MUI fährt die Windows-Philosophie "Programme optimieren? Du willst wohl die Hardwareentwickler arbeitslos machen?"
Pro	Was soll das? Sollten GUIs etwa in Assembler verfasst werden? Zur Windows-Philosophie gehört auch, dass jeder sein eigenes Süppchen kocht und sich keiner nach dem anderen richtet oder mit ihm zusammenarbeitet (was bedeuten würde, sich von dessen Weiterentwicklung abhängig zu machen). Erstaunlich dass jeder glaubt, sein Standard würde sich durchsetzen (=Geld, Macht, Ruhm!), obwohl er sich kaum von den anderen unterscheidet, geschweige denn die Fähigkeiten von allen Konkurrenten in sich vereint. Aber dieser Sachverhalt ist wohl eher mit selbstgestrickten GUI-Systemen vergleichbar als mit MUI.
Kontra	Man macht sich als Programmierer von MUI und dessen Fortkommen abhängig. Außerdem sind MUI Programme stark systemgebunden und lassen sich nicht portieren.
Pro	Das ist nur die halbe Wahrheit. Keiner soll glauben, dass sein Programm portierbar wäre, nur weil er kein MUI benutzt. Es ist ganz klar so, dass man bei leicht portieren Programmen keine Besonderheiten der betrachteten Plattformen ansprechen kann, vielmehr muss sich das Programm mit dem Minimum der Fähigkeiten aller Plattformen abfinden. Das geht für den Benutzer immer mit Einschnitten im Komfort her. Aber wir wollen ja maximalen Komfort, warum dann nicht die Möglichkeiten des Systems, hier also Amiga, nutzen? Indem man die AmigaOS-Routinen direkt anspricht und einen Compiler mit Amiga-spezifischen Erweiterungen benutzt, tut man das bereits, MUI sowie jedes andere Amiga-GUI-System wäre lediglich ein weiterer Schritt, eine eventuelle Portierung (ja nur eventuell, wirklich vor hat es noch nicht mal jemand) zu erschweren. Für MUI gibt es z.B. unter Windoof gar kein Äquivalent. - Dürfen wir es deswegen auch nicht haben? Nicht zuletzt kann man auch MUI-Programme durch strikte Trennung von GUI und Hauptprogramm einigermaßen portierbar halten, MUIBase demonstriert (auch wenn man es von außen nicht sehen kann), dass es möglich ist.
Kontra	MUI kostet Lizenzgebühren, wenn man es in einem kommerziellen Programm verwendet.
Pro	Die Entwicklung eines eigenen Systems kostet wohl keine Zeit und damit Geld?
Kontra	Wir würden ja kein eigenes System entwickeln, wäre es nicht nötig.
Pro	Das ist wohl eher ein Indiz für die eigene Engstirnigkeit.

Falls jemand noch weitere Kontra-Punkte anführen kann - immer her damit! Ansonsten betrachte ich alle bisherigen Vorbehalte als reine Vorwände und Vorurteile von Leuten, die sich nie richtig mit der Materie beschäftigt haben. - Was der Bauer nicht kennt, isst er nicht.

Fazit: Glaub niemals einem Programmierer, der behauptet, er hätte keine Zeit. Er hält sich womöglich nur bei den falschen Dingen auf.

Links für Amiga-Software-Entwickler

"Um etwas entwickeln zu können,
muss man's erst einmal einwickeln."

Aus der Not, dass Anwender und Entwickler den Amiga nach und nach verlassen, entstanden einige Tugenden, mit denen sich die Arbeit der Entwickler viel effizienter gestalten lässt. Diese Initiativen sind wirklich mit dem Ziel angetreten, dem Amiga über die Durststrecke zu helfen, bis der Name Amiga wieder für bahnbrechende Innovationen steht. Obwohl diese Projekte auch über eine Entspannung der Lage hinaus erhaltenswert sind. Hier also meine Auswahl der Angebote, die ich für besonders wichtig halte:

Amiga Idea Site

Tagtäglich wird unter Programmierern das Rad neu erfunden. Auf PCs wird das Problem durch Masse kompensiert: Wenn sich von einer Million Programmierer unabhängig voneinander jeweils tausend an ähnlichen Projekten schaffen, können immer noch tausend Probleme bearbeitet werden. Auf dem Amiga muss man die wenigen noch vorhandenen Energien bündeln, auch eine Art der Resourcenschonung, wofür Amigas ja bekannt sind (oder sein sollten). Wer sich beim 1000. Tetris-Clone, der keine Neuigkeiten zu bieten hatte, oder dem 100. fontsensitiven GUI-System, das angeblich viel absturzsicherer und schneller sein soll, als das oft geschmähte MUI, ärgerte, wofür Programmierer, die nie Zeit haben, ihre Zeit vergeuden, der sollte - ganz gleich ob Benutzer oder Entwickler - diese Seite ansteuern. Hier können Benutzer ihre Traum-Programme skizzieren und Programmierer Ideen für neue Projekte holen, die dann auch mit Sicherheit von wenigstens einem gebraucht werden.

Amiga Translator Organization

Damit die Sprachanpassung von Programmen z.B. mit Hilfe der locales.library auch von Programmieren, nicht 20 verchiedene Sprachen fließend schreiben können, bewältigt werden kann, haben sich in der ATO Leute zusammengefunden, die mindestens zwei Sprachen beherrschen (meist Englisch und die Muttersprache), ihre bevorzugten Programme in ihrer bevorzugten Sprache benutzen wollen und die Übersetzungen koordiniert abwickeln.