View Full Version : Programmierstandards - Feedback und Ideen
dschroeder
11-01-16, 09:18
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
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
11-01-16, 10:40
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
11-01-16, 11:53
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
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
11-01-16, 15:57
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
Aber ich denke, dass es noch eine ganze Weile dauert, bis wir in der reinen "Java-Zukunft" angekommen sind.
Ob JAVA bis dahin noch das Gelbe vom Ei ist, bleibt abzuwarten!
Auch diese Programmiersprache kommt in die Jahre!
Birgitta
dschroeder
11-01-16, 16:40
Stimmt. Aber im Tiobe Index ist Java zur Zeit auf Platz 1 (hat gerade C verdrängt). RPG ist immerhin noch auf Rang 36. Wenn man allerdings C und C++ zusammenzählt, sind die ganz vorne.
Für mich sieht es so aus, als wäre C die Sprache, die es "immer" geben wird. Die gibt es schon recht lange und sie ist eigentlich die ganze Zeit populär.
Dieter
Auch hier denke ich, dass Java mit ein Grund ist.
Nur mit C/C++ lässt sich maschinennaher Code entwickeln.
Die Java-VM selber ist sicherlich der Kandidat für C/C++ um diese für diverse Plattformen verfügbar zu machen.
Der Rest erfolgt wiederum in Java.
Man bedenke, das Android ein Java-Derivat ist!
Und wo läuft das alles so?
Mein Blu-Ray-Player hat ebenso Java und demnächst wohl auch der Kühlschrank.
Also ich muss sagen, das Kollege Bender schon sehr Recht hat. Ich kann ein Auto, das ich 1985 entworfen und gebaut habe, nicht immer wieder mit neuen Errungenschaften erweitern.
Denn entweder passt das alles nicht mehr, oder aber es ist so verbaut, das keiner mehr einen durchblick hat.
Ich bin der Meinung, das gerade ein Softwarehaus, ihre Software nach 10-20 Jahren neu aufsetzen muss, um Konkurenzfähig zu bleiben!
Natürlich braucht man dafür Performance und Manpower, aber ich denke es würde heute auch keinen Autobauer mehr geben, der seine aktuellen Modelle auf einer Plattform von vor 30 Jahren baut!
Als Kunde mache ich natürlich das was im Unternhemen eingesetzt wird. Ich würde kein 30 Jahre altes ERP -System (GEAC, STEEB, ...) was aktuell im Einsatz ist, auf modernste Techniken umschreiben.
Wenn es läuft und nur ggf. Erweitert werden muss dann mache ich bein den Original-Sourcen nicht vorher ein CVTRPGSRC, das wäre Sinnfrei und würde ggf. die Useability "zerstören" da Masken & Verhalten sich ggf. von 98% der anderen Programmen ändern würden.