Programmierstandards - Feedback und Ideen

[camouflage]

Die ganze Diskussion erinnert mich an die Aussage einer befreundeten Fotografin:
"Was nützt die tollste Fotoausrüstung, wenn man nicht das Auge für das Motiv hat"!

just my 2 cts.

[Fuerchau]

Dem kann ich mich nur anschließen.
Bei den ganzen Möglichkeiten bin ich einfach froh, dass meine Programme funktionieren.
Egal ob COBOL, RPG, mit oder ohne ILE oder SQL, meine Kunden zufrieden sind und die (interne) Doku verständlich wirkt.
Dabei habe ich meinen eigenen Standard entwickelt, passe mich den Kundenwünschen aber an oder überzeuge Sie, wenn mein Weg der bessere ist.

[LordCinimod]

... warum erinnert mich das nur immer wieder an F.W. Bernstein? Die schärfsten Kritiker der Elche, waren früher selber welche.
Die Metamorphose des tiefblau gefärbten AS/400 Anhängers lässt mich immer wieder schmunzeln.
Stufe 1: der RPG Zyklus ist das Größte.
Stufe 2: RPG ist so toll, weil man den Zyklus nicht mehr benutzen muss.
Stufe 3 a: /free und /end-free ist Spitze , weil man sofort sieht, dass jetzt keine Spalten mehr kommen.
Stufe 3 b: toll, dass man Kommentare am Zeilenende nicht kennzeichnen muss
Stufe 3c: Deklarationen müssen in Spalten bleiben, das ist einfacher
Stufe 3d: embedded SQL, da kann kein free format gehen
Stufe 3e: call und eval sind das Größte
Stufe 4: toll das embedded SQL jetzt auch in Freeformat geht
Stufe 5: toll, jetzt gibt es sogar noch ein eval corr
Stufe 6: toll, jetzt braucht man nicht einmal mehr /free und /end-free schreiben
Stufe 7: toll, jetzt gibt es total free
Stufe 8: noch toller, jetzt gibt es fully free
Stufe next: jetzt warten wir auf total fully free
Stufe übernext: jetzt fehlt nur noch full total fully free
final Stufe: jetzt funktioniert sogar alles

D*B

PS: das Endergebnis hätte man auch einfacher haben können: CRTDUPOBJ CRTBNDC QSYS *CMD NEWOBJ(CRTBNDRPG), dann hätte man sich sogar eine Menge Gedöns mit Prototypen erspart und Blöcke könnte man einfach durch geschweifte Klammern darstellen (Vorsicht Elchtest: das könnte in full total fully free RPG kommen), aber das hätten die Elche wahrscheinlich nicht gemocht.

Mhm, ich verstehe gerade deine Aussage nicht so genau, was ist schlimm daran das RPG moderner wird? Als ich meine Ausbildung angefangen habe habe ich mit free rpg angefangen. Ich fand das sehr umständlich, mir persönlich gingen diese Spalten tierisch auf den Nerv! Gleichzeitig war ich froh, da mir das so definitv besser gefiel als die alte Schreibweise ohne free und end-free.

Als dann tfr rauskam war ich selig, viel angenehmer zu schreiben und zu lesen(da sind sich alle Azubis bei uns in de EDV und in der Common-D Schulung einig). Ich finde es klasse das RPG weiterentwickelt wird und mir ist bewusst das es vllt. erst in x Jahren (wenn überhaupt) den Stand einer heutigen Sprache erlangt, aber hey was solls hauptsache es gibt einen Fortschritt und warum soll man das dann nicht auch gut finden dürfen?

Selbes trifft auf DDS und Profound zu (wie dschroeder schon schrieb) Profound ist viel angenehmer zu programmieren und auch zu nutzen.

Vllt. bin ich aber auch als Azubi nur naiv und habe zu wenig durchblick xD

PS: Auch wir schreiben Programme nur rein intern für unsere Firma, arbeiten also nicht für externe Firmen. Vllt. ist das ja der Grund für die unterschiedlichen Meinungen ; )

[BenderD]

Die Situation bei der Firma wo ich gerade meine Ausbildung mache ist nämlich das wir noch keine Programmierstandards besitzten. Was natürlich verschiedenste Probleme in der Entwicklung und Wartung aufwirft, zum Beispiel nutzt kaum einer Prozeduren oder ServiceprogrammeGrüße
Dominic

... du hast das Problem doch klar umrissen. RPG ist ein Sammelsurium der verschiedensten Konstrukte, mit Spalten, ohne Spalten und mit jeder "Modernisierung" ist die Sprache fetter geworden und jeder sucht sich das aus, was ihm schmeckt, mit anderen Worten: macht so weiter wie vorher oder fängt halt so an, wie er soll oder versucht das Software Engineering neu zu erfinden, so wie er es halt verstanden hat.

Wenn ich neu aufsetzen will, mit einer graphischen Oberfläche und einer modernen Benutzer Ergonomie, dann nehme ich keine Programmiersprache, die das alles nicht kann und einen Aufsatz, der das auch nur verkleistert, sondern sehe mich mal im Mainstream um und lande dann bei .net oder Java, muss dann keine Räder erfinden und mir meine Werkzeuge selber bauen.

D*B

[LordCinimod]

Morgen ,

jetzt verstehe ich wo das Problem für dich liegt. Du hast Recht es ist ein Sammelsurium an verschiedensten Funktionen ect. und RPG ist ziemlich unübersichtlich von den Möglichkeiten (jedenfalls für Anfänger wie mich) aber muss das zwangsläufig heißen das eine Sprache schlecht ist?

Java geht z.B. doch auch diesen Weg um Abwärtskompatibel zu bleiben, denn da gibt es auch redundante Möglichkeiten welche mit der Zeit entstanden sind. Zudem ist es gerade in Java sehr leicht 2 Paradigmen ohne Probleme zu mischen, da nimmt dann ja auch jeder Entwickler was Ihm vllt. gerade besser gefällt. Dann gibt es noch Sprachen wie Perl. Perl schreibt es sich ja sogar auf die Fahne das es für ein Problem dutzende Möglichkeiten gibt. Zudem die sehr aktive Communities, welche sehr stark unterstützen.

Wenn Entwickler einer Sprache einen Cut machen z.B. wie in Python 3 dann ist der Aufschrei nämlich auch immer groß, unter dem Motto: "Wiesooo den ein Cut, jetzt muss ich ja meine alten Programme alle wieder anpassen!.... "
Für mich ist das ganze mehr ein Programmierer/Organisationsproblem unabhängig der verwendeten Sprache.

Ich kann zum Schluss nur noch sagen, ich kenne Java, ich kenne C# und auch mit Python2 & 3 habe ich schon programmiert und trotzdem bringt mir RPG (TFR) mit Profound UI Spaß und vermissen tue ich fast nichts (wobei das natürlich immer auf die Anfoerung ankommt). Für mich reicht das und ich freue mich daher auch weiter über jede neue RPG Versionen mit neuen Möglichkeiten ; )

Aber wie du schon geschrieben hast kann man ja auch andere Sprachen auf der System i nutzen, daher kann ja jeder selber entscheiden ob ihm RPG reicht oder man lieber eine andere Sprachen nimmt und man muss nicht streiten : D

PS: Ich hoffe ich bin niemand auf die Füße getreten und bekomme trotzem in Zukunft noch Hilfe und Feedback ; P

[Fuerchau]

Meine ganz persönliche Sichtweise:

Her muss man 2 gravierende Dinge unterscheiden!
Das reine Sprachkonstrukt und die Bibliotheksfunktionen.

Bei RPG/LE enthält das Sprachkonstrukt bereits eine Vielzahl von Funktionen (z.B. Dateibearbeitung).
Die BuiltIn-Funktionen (%dec(), usw.) mag man noch als Bibliotheksfunktionen hinnehmen, gehören aber zum Sprachkonstrukt.
Bibliotheksfunktionen sind in RPGLE quasi nur als z.T. hochkomplexe API's verfügbar.

Die Sprachkonstrukte von Java, C++, c# o.ä. enthalten im Gegensatz dazu ausschließlich wenige Schlüsselworte und jede Menge Operatoren.
Daran hat sich seit Einführung so gut nichts mehr geändert und ist (meines Wissens) auch nie erweitert worden, was natürlich für die Stabilität der Sprache an sich spricht.
Alles andere wird ausschließlich durch Bibliotheksfunktionen bereitgestellt. Damit sind natürlich jede Menge Erweiterungen, Features und verschiedenste Lösungsansätze möglich geworden.
Die verschiedene Java-Versionen drücken sich nur durch verbesserte Runtime-Funktionen aus, ändern aber nichts an der Java-Sprache (ein "Stream" ist eine Funktion der Runtime (in diesem Fall ein Objekt)und nicht das Sprachkonstrukt, ein "Integer" gehört zum Sprachkonstrukt).

Bei ILERPG hat sich der Funktionsumfang nur marginal geändert sondern nur die Schreibweisen vervielfältigt und dadurch z.T. vereinfacht.
Klar ist es heute einfacher, komplexe Formeln mit einem simplen EVAL (den man auch weglassen kann) zu kodieren an statt alles wie früher in Einzelschritte zu zerlegen. Das ist aber wie gesagt keine Funktionserweiterung sondern nur eine andere Schreibweise.

[dschroeder]

Wenn ich neu aufsetzen will, mit einer graphischen Oberfläche und einer modernen Benutzer Ergonomie, dann nehme ich keine Programmiersprache, die das alles nicht kann und einen Aufsatz, der das auch nur verkleistert, sondern sehe mich mal im Mainstream um und lande dann bei .net oder Java, muss dann keine Räder erfinden und mir meine Werkzeuge selber bauen.
D*B

Jetzt hast du es aber auch auf den Punkt gebracht: Deine Alternative Java oder .net ist dafür geeignet, "wenn ich neu aufsetzen will". Die Realität ist aber, dass tausende Programme mit Millionen Zeilen Code im RPG vorhanden sind. Es ist nicht (jedenfalls nicht immer) wirtschaftlich, das alles neu zu schreiben. Außerdem funktioniert es ja. Wenn jetzt Anforderungen kommen, in diese "alte" Software Änderungen und Erweiterungen einzubauen, ist es meiner Ansicht nach sinnvoll, diese Änderungen so gut wie möglich und mit den besten verfügbaren Werkzeugen umzusetzen. Also auch mit grafischen Tools (wie z.B. Profound) zu arbeiten. Etwas anderes wäre es, wenn man Java oder .net direkt in die RPG-Anwendungen integrieren könnte. Dann könnte man dafür auch diese Sprachen benutzen. Aber das klappt ja nicht so richtig.

Dieter

[BenderD]

Jetzt hast du es aber auch auf den Punkt gebracht: Deine Alternative Java oder .net ist dafür geeignet, "wenn ich neu aufsetzen will". Die Realität ist aber, dass tausende Programme mit Millionen Zeilen Code im RPG vorhanden sind. Es ist nicht (jedenfalls nicht immer) wirtschaftlich, das alles neu zu schreiben. Außerdem funktioniert es ja. Wenn jetzt Anforderungen kommen, in diese "alte" Software Änderungen und Erweiterungen einzubauen, ist es meiner Ansicht nach sinnvoll, diese Änderungen so gut wie möglich und mit den besten verfügbaren Werkzeugen umzusetzen. Also auch mit grafischen Tools (wie z.B. Profound) zu arbeiten. Etwas anderes wäre es, wenn man Java oder .net direkt in die RPG-Anwendungen integrieren könnte. Dann könnte man dafür auch diese Sprachen benutzen. Aber das klappt ja nicht so richtig.

Dieter

Totally free (sprich: Aufgabe der 72 Spalten Begrenzung) erfordert aber gerade einen kompletten rewrite und dann würde ich das nicht mehr in RPG machen, sondern bei dieser Gelegenheit in den Mainstream wechseln. Bei .net würde das bedeuten, dass dann auf der AS/400 nur die Datenbank verbleibt, bei Java, dass die Anwendung auf der AS/400 laufen kann, aber nicht muss.

Strategisch kann man sich heute m.E. nicht mehr guten Gewissens auf RPG stützen, da fehlt einfach zuviel, was man für aktuelle Anforderungen an Ergonomie der Software braucht - und damit meine ich nicht in erster Linie Grafik. Neue Komponenten kann man besser mit aktuellen Werkzeugen und dann in anderen Sprachen entwickeln und in dem Sinn ist die Weiterentwicklung der RPG Syntax in Richtung C Syntax hilfreich, da wird der Schritt kleiner. In vielen Fällen wird man vorhandeen Code im Backend weiter verwenden können, meist wird man ein gewisses Redesign zur Erhöhung der Modularität des vorhandenen Codes benötigen.

Profound und andere Zauberkästen sind dann hilfreich, die große Masse der Funktionen, die sich so gut wie nie ändern, optisch anzugleichen, mit minimiertem Aufwand.

Knackpunkt ist für mich: RPG Komponenten durch Herauslösung aus der vorhandenen Anwendung für die strategische Umgebung verfügbar zu machen, anstatt benötigte Funktionen über vergleichsweise exotische Tools für RPG verfügbar zu machen. Moderne Benutzer Ergonomie benötigt Event driven Frontends und das verträgt sich nach wie vor nicht wirklich mit RPG, nicht einmal im Backend (im bereits erwähnten MVC Pattern benötigt das modell multithreading).

D*B

[andreaspr@aon.at]

Ich unterscheide bei so einer Diskussion zwischen Backend und Frontend.
Unsere GUI z.B. ist HTML. Dafür kann ich Java, PHP, .Net oder was es da sonst noch alles gibt verwenden.
Mit solchen Technologien kann ich auf moderne Tools zugreifen die es in RPG entweder gar nicht oder nur sehr umständlich gibt.
Das Backend mit der DB ist bei uns RPG & DB2.
Wenn man schön ordentlich mit klar definierten Schnittstellen arbeitet können alle Programme aus der GUI Welt (Java, PHP, ...) auf die gleichen RPG Programme zugreifen um eine Verarbeitung zu starten oder Daten zu bekommen.
Damit habe ich weiterhin die AS/400 samt deren Vorteile + die Möglichkeit modernes einsetzen zu können.

Ich habe z.B. ein WebService in Java bei uns aufgesetzt, welches für die Backend Verarbeitung die bestendend RPG Programme verwendet. Hätte keinen Sinn gemacht das alles neu zu programmieren (Kosten/Nutzen).
Klar hätte man das WS auch in RPG machen können, wenn man aber z.B. WS mit Signaturen haben möchte, stoßt man schnell an die Grenzen.
Ich habe lediglich die Schnittstelle dazu entwickeln müssen. Das war oft einfach nur eine simple External SQL Procedure.

Funktioniert bei uns wunderbar.
Man muss eben nicht immer alles gleich über Board werfen.
Mit einer klar definierten Struktur und Schnittstellen geht das auch schrittweise.
Und mir persönlich sind gute Strukturen als Basis wichtiger als Diskussionen wie dass die Variablen mit "V_" beginnen sollen.

lg Andreas

[dschroeder]

Es kommt eben immer darauf an, welche Anforderung umgesetzt werden soll. Wenn man Anwendungsteile hat, die sich "als Block" aus der Gesamtanwendung herauslösen lassen, kann man sie natürlich in eine andere Umgebung (z.B. in die Java-Welt) bringen. Das machen wir an verschiedenen Stellen auch so. Die Anzahl der Java Entwickler ist in unserem Unternehmen bereits doppelt so groß wie die Anzahl der RPG-Entwickler.

Es gibt aber auch bestehende Prozesse, die in RPG implementiert sind, in die man nicht mal so eben etwas mit Java einbauen kann. Man hätte da ja die Problematik, dass man Maskenabläufe im RPG hätte, dann käme ein Java Maske und dann müsste man wieder zurück in die RPG-Maske. Die Steuerung würde da sehr komplex und wackelig. Da muss man sich dann entscheiden: Entweder den ganzen Prozess nach Java verlagern oder lieber weiter im RPG arbeiten. An so einer Stelle setzen wir oft auf Profound, weil das eben alles weiterhin unter der normalen RPG-Steuerung läuft und trotzdem eine moderne Oberfläche bietet.

Wenn wir Anwendungsteile komplett in Java neu schreiben, machen wir es oft so, wie Andreas es beschrieben hat: Die Datenbank liegt zentral auf der iSeries und die Java-Anwendungen greifen über Webservices oder über SQL-Funktionen (UDF) auf die Daten zu.

Dieter

[BenderD]

Es gibt aber auch bestehende Prozesse, die in RPG implementiert sind, in die man nicht mal so eben etwas mit Java einbauen kann. Man hätte da ja die Problematik, dass man Maskenabläufe im RPG hätte, dann käme ein Java Maske und dann müsste man wieder zurück in die RPG-Maske. Die Steuerung würde da sehr komplex und wackelig. Dieter

... ohne Reengineering des RPG Teils mag das stimmen, aber der reengineering Teil (rausziehen der Controller Logik => MVC) sollte überschaubar sein.

D*B

[dschroeder]

OK, das mag überschaubar sein. Aber dennoch müssen funktionierende Programme und Abläufe reengineered werden. Das ist oft nicht notwendig, wenn nur eine zusätzliche Funktionalität implementiert werden soll. Es ist nicht (jedenfalls nicht immer) wirtschaftlich, bei jeder funktionalen Erweiterung das ganz große Rad zu drehen und ein Reengineering aller betroffenen Programme durchzuführen. Wenn man die Zeit dafür hat, wäre das natürlich zu begrüßen.

Ich glaube, wir liegen mit unseren Ansichten gar nicht so weit auseinander. Aus meiner Sicht gehört zur Wirtschaftlichkeitsbetrachtung in der Programmierung nicht nur die Frage, in welcher Sprache eine Erweiterung am effektivsten umgesetzt werden kann, sondern auch die Frage, ob es bereits bestehende Software gibt, die weitergenutzt werden kann. Wenn ich die Programmierplattform wechsele, muss ich ja sehr viel neu schreiben, was im RPG bereits fehlerfrei funktioniert. Es sind ja nicht immer nur Batchprogramme, die per Webservice weitergenutzt werden können. Es gibt ja auch Masken, die gut funktionieren.

Unser Ansatz ist zur Zeit eher eine Evolution hin zu moderneren Sprachen. Ein komplettes Neuschreiben ist für uns zu aufwändig.

Mir ist klar, dass die Zukunft in moderneren Sprachen als RPG liegt und dass auch Tools wie Profound nur ein Zwischenschritt sind. Aber ich denke, dass es noch eine ganze Weile dauert, bis wir in der reinen "Java-Zukunft" angekommen sind.

Dieter