View Full Version : Programmierstandards - Feedback und Ideen
Nun gut, das automatische Konvertieren von Subroutinen in Prozeduren wird dann wohl nicht lange auf sich warten lassen.
Jetzt muss ich aber auch mal doof fragen:
Was soll es mir bringen, wenn Subroutinen, die nur globale Variablen verwenden in Prozeduren konvertiert werden!
M.E. ist die Konvertierung ohne Kapselung sinnlos und zum Kapseln, Ein-/Ausgabe-Parameter und lokale Variablen definieren, muss man Hand anlegen.
Free RPG hat zumindest einen Vorteil, dass lange Variablen-Namen ordentlich lesbar generiert und ohne unnötige Umbrüche verwendet werden können.
... übrigens! dass RPG komplett im Free-Format geschrieben werden kann ist nicht wahr!
I und O-Bestimmungen können nicht im Free-Format codiert werden!
... auch wenn viele diese Bestimmungsarten in den letzten Jahren nicht mehr verwendet haben (was gut so ist)
Solche Beispiele lassen sich auch in Fenstertechnik lösen.
In meiner Bildmaske sind nur Ausgabefelder der Adresse.
Benötige ich eine Adresserfassung rufe ich die entsprechende Funktion auf.
Diese macht eben alles wie gerade beschrieben und liefert mir die Adresse zurück die ich anzeige.
Ebenso kann ich z.B. per F-Taste auf der Adresse die Änderungsfunktion aufrufen.
Das ist dann genau die gewünschte Modularität.
Ebenso kann man eine Adresseingabe mit einer AdressStruktur aufrufen, die gibt mir dann die Fehlernummer und ggf. das Feld für die Positionierung auf dem Fehler zurück.
Möglichkeiten gibt es auch bei DSPF sicherlich viele.
Aber wer nutzt denn noch 5250.
So was unmodernes kann man doch keinem mehr zumuten.
Hier muss .NET oder Java o.ä. eingesetzt werden. Dann läuft sowieso alles schöner, besser, schneller.
dschroeder
08-01-16, 16:10
Tja, Baldur. Ich bin wirklich ein Fan der iSeries und habe 20 Jahre lang 5250-Oberflächen programmiert. Aber seit wir grafische Anwendungen auf der iSeries entwickeln, möchte ich wirklich nicht mehr zurück zur klassischen 5250-Oberfläche. Ich meine jetzt nicht mal die Frage, ob das für den Anwender schöner ist. Ich spreche rein von der Programmierung. Bei grafischen Umgebungen ist wirklich vieles so viel einfacher zu implementieren. Z.B. weniger Plausis, weil der User die Daten nicht eingibt, sondern auswählt. Weniger Probleme, noch Platz auf dem Bildschirm für neue Felder zu finden. Im Gegensatz zu 5250 ist der grafische Bildschirm ja riesig!). Und das Handling von Subfiles ist geradezu kinderleicht im Vergleich zu früher. Ich wüsste nicht, wann ich früher mal Programme mit mehr als einer Sfl auf der Maske geschrieben hätte. In unseren Profound-Masken ist das fast schon Standard, eben weil man Platz hat und es so einfach ist. Zur Klarstellung: Wir sind kein Softwarehaus, sondern Anwender. Wir verkaufen kein Profound und wir bekommen auch keine Provsion. Das ist jetzt alles nicht aus Werbezwecken gemeint. Das ist echt so!
Wenn man dann eine grafische Maske entworfen hat, findet man ein Umschalten für die Adresseingabe einfach nicht mehr so schön. Das ist dann irgendwie "nicht zeitgemäß". Sorry, ich möchte dir nicht zu nahe treten. Ich habe selber früher lange in einem iSeries-Softwarehaus gearbeitet und weiß natürlich, dass man nicht machen kann, was man möchte, sondern dass man darauf angewiesen ist, was die Kunden wollen. Wenn die 5250 haben wollen, baut man das natürlich als Freelancer.
Das mit dem Umschalten auf die Adresseingabe ist aber eben nur ein Trick, weil man es nicht richtig in die Maske integrieren kann. Ich muss zugeben, dass unsere Eclipse-Entwickler da echt mehr Freiheiten haben. Auch wenn ich Profound echt toll finde, geht da mit nativen Windows Werkzeugen echt noch mehr!
Dieter
Gerade weil die freie Eingaben für eine Programmiersprache so wichtig ist, ist es doch klar, dass sich die RPG-Programmierer dafür interessieren, wie es geht und die Forderung aufstellen, dass es vernünftig funktioniert.
Dieter
... 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.
camouflage
10-01-16, 15:17
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.
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
10-01-16, 16:42
... 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 ; )
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
11-01-16, 08:24
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
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.