Programmierstandards - Feedback und Ideen

[B.Hauser]

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]

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

[Fuerchau]

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.

[ExAzubi]

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.

[dschroeder]

Ich denke, dein Vergleich mit dem Auto passt zu Standardsoftware. Die kann vergleichsweise leicht durch eine neue Version ausgetauscht werden.
Die Kernanwendungen in unserem Unternehmen sind alle individuell programmiert (egal, ob RPG oder Java). Da kann kein Externer für uns einfach eine neue Version programmieren und dann alles austauschen. Das würde ich anstatt mit einem Auto eher mit einem Haus vergleichen, an dem man lange gebaut hat. Wenn da eine Erweiterung notwendig ist, reißt man es ja nicht sofort komplett ab und baut neu. Da macht man einen Anbau, der dann natürlich nach dem neuesten Standard errichtet wird. Meine Idee ist, dass man irgendwann viele Erweiterungen nach neuerem Standdard hat, so dass man das Ursprungsgebäude räumen kann. Das wird dann durch einen neuen Anbau an (die Erweiterungen) ersetzt. Also Evolution anstatt Revolution.

Dieter

[andreaspr@aon.at]

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.

Um bei der Metaffa zu bleiben:
Nur weil mein Auto 1985 gebaut wurde, heißt es nicht, dass ich kein modernes Navi verwenden kann welches ich vielleicht sogar auch fürs Motorad oder andere Autos benutzen kann.
Oder eine "moderne" Dachbox ...
Ich würde nicht alles so schwarz/weis sehen.
Aber stimmt schon nicht immer funktionierts so einfach.

[B.Hauser]

Ich bin der Meinung, das gerade ein Softwarehaus, ihre Software nach 10-20 Jahren neu aufsetzen muss, um Konkurenzfähig zu bleiben!

Versuch mal ein Buchhaltungssystem neu zu schreiben!

Leider hat sich der Vorteil, den IBM immer angepriesen hat, d.h. Abwärtskompatibilität ohne irgendwelche Anpassungen zum Nachteil entwickelt.
Viele Unternehmen (Softwarehäuser oder nicht) haben das zum Anlass genommen, und nie in Aus- und Weiterbildung investiert.
Warum auch? Man kann ja immer noch im gleichen alten Stil wie 1988 oder sogar noch früher codieren.
Investition in Aus- und Weiterbildung wäre Verschwendung gewesen.
Damit hat man in den letzen 20 Jahren sich u.U. keinen Schritt vorwärts bewegt.
Und jetzt nach 20 Jahren wacht man auf! Das Geschrei ist groß, weil 20 verpennte Jahre kann man nicht in 2 Wochen aufholen!

In der PC-Welt hat es anders ausgesehen. Da war es klar, dass man die Leute auf dem Laufenden halten muss, weil ansonsten in 5 Jahren nichts mehr läuft. Da war Geld für Aus- und Weiterbildung, neue Systeme etc. immer genügen da.
Die IBM i (oder früher AS/400) Welt hatte das Nachsehen.

Wobei der Investitionsschutz ist als solches nicht schlecht. In einem WWS-System oder Buchhaltungssystem gibt es sicher ein paar Tausend Programme und wenn man einigermaßen am Ball geblieben ist noch wesentlich mehr Prozeduren, ggf. in unterschiedlichen Programmiersprachen, nach unterschiedlichen Konzepten (prozedural, OO) etc.

Ein solches Pakte schreibt man nicht mal "schnell" um!
Komplettes Umscheiben ist auch nicht notwendig, wenn man für Änderungen und Erweiterungen jeweils die neue und neueste Techniken eingesetzt hat.

Des weiteren kommt es gerade in Softwarehäusern auch immer darauf an, wer die Neuerungen auch bezahlt.
Bei jeder neuen Technik, ist immer ein gewisser Aufwand an "Ausprobieren" dabei und manchmal muss man alles nochmal in die Tonne treten. Dazu kommt noch der sonstige Aufwand für Konzeptionierung, Programmierung und Tests, die bei neuen Technologien immens sind.

A pro pos neue Technologien und Softwarehäuser. Wenn man nicht gerade SAP heißt, muss sich ein Softwarehouse immer nach dem letzten Kunden, der upgradet richten. Alle Änderungen müssen und mussten auf dem Release, das der "letzte" Kunde einsetzt lauffähig sein.
Früher waren die Release Zyklen 1,5 - 2 Jahre, IBM hat 3 Release unterstützt, d.h. wenn man sich an die IBM Regel hält war ein Softwarehouse 4-6 Jahre zurück. Jetzt wurde das Ganze umgestellt, d.h. jedes halbe Jahr gibt es einen Technology Refresh und die Release werden länger unterstützt. Release 7.1 hat jetzt den 11. TR (ist also schon fast 6 Jahre alt!). Das aktuelle Release ist 7.2 (auch schon wieder fast 2 Jahre alt).
Wir hatten Anfang Juli in diesm Jahr (als Release 7.1 auch schon 5 Jahre alt war!) beschlossen nur noch 7.1 oder höher zu unterstützen. Die Proteste unserer Kunden waren immens.

... und jetzt frag' mal wieviele Firmen noch Release V5R4 oder noch älter im Einsatz haben.

Erweiterungen nur um neue Technologien zu verwenden, will kein Kunde bezahlen.
Frag nicht wie oft ich schon bei meinem Chef antanzen musste weil ich etwas Neues ausprobiert habe und damit mehr Zeit als der Kunde gewillt war zu bezahlen benötigt hatte und mir dann anhören musste: "Hätten Sie ein altes Programm kopiert wäre das schneller gewesen".

Kurzfristig und blauäugig gedacht, nur leider ist sich zunächst mal jeder selbst der nächste (haben will ich's ja gerne, nur bezahlen dafür nicht!)!
... und leider sieht es in der Realität oftmals genau so aus.

Birgitta

[dschroeder]

Eine konkrete Empfehlung habe ich aber auch noch: Wenn ihr mit Profound arbeitet, könnt ihr in Displayfiles mit langen Feldnamen (Stichwort "alias") arbeiten. Bei uns heißt ein normales Displayformat F1. Wenn es ein zweites gibt, heißt das dann F2 usw. Wenn es eine Subfile ist, heißt das Format S1. (Bei mehreren Subfiles S2, S3, usw...).

Die Felder in den Formaten habe dann ganz "normale" Namen, wie z.B. "name" oder "rechnungsbetragBrutto". Sie brauchen keine eigene Kennung als Variablen von Display-Files, da sie über die Displayfiles-Datenstrukturen angesprochen werden. Also z.B. "f1.name" oder "s1.rechnungsbetragBrutto".

Hallo Dominic,
leider ist mir bei der Beschreibung ein Fehler unterlaufen. Ich hoffe, ich habe dich nicht in die Irre geführt.
Die Formate in Display heißen bei uns nicht F1 und F2, sondern FMT1 bzw. SFL1.
F1 und S1 sind im Programm definierte Strukturen, um die Alias-Namen zu verarbeiten.
Hier ein Beispiel:
Das Displayfile heißt "sis45ad", das erste Format im Display heißt fmt1, die erste Subfile im Display heißt sfl1.

Dann wäre folgendes die Deklaration der Display-File im RPG:

       dcl-f sis45ad WORKSTN handler('PROFOUNDUI(HANDLER)') alias qualified
                                             sfile(sfl1:f1.s1_satznr);

Die Datenstrukturen für die Formate sind dann folgendermaßen zu deklarieren:

// Qualifizierte Datenstrukturen für Bildschirm-Handling:       
dcl-ds f1 likerec(sis45ad.fmt1:*all);       // Alle Felder des normalen Formates
dcl-ds s1 likerec(sis45ad.sfl1:*all);       // Alle Felder von sfl1

Die Strukturen verwenden wir dann beim Zugriff auf das Format oder die Subfile,
also z.B.:

exfmt sis45ad.fmt1 f1;
oder
chain satznr sis45ad.sfl1 s1;

Der Zugriff auf die Felder erfolgt dann qualifiziert. Wenn es also in der Subfile ein Feld rechnungsbetrag gibt und im normalen Format ebenso, kann man die Felder so ansprechen:

if f1.rechnungsbetrag > 0, 
   ...

bzw.

if s1.rechnungsbetrag > 0, 
   ...

Das Schöne an den langen Namen ist insbesondere, dass man alle Attribute mit klaren Begriffen benennen kann. Wenn der Rechnungsbetrag sichtbar/unsichtbar geschaltet werden soll, würde man die Variable dafür im Display eben "rechnungsbetrag_visible"
nennen.

Entschuldige meine langen Ausführungen, falls du das sowieso schon alles wusstest. Aber ich dachte, bevor du lange rumprobierst...

Übrigens: Das Schlüsselwort *all bei der Deklaration der Datenstrukturen geht noch nicht so lange. Ich glaube, man braucht das OS Version 7.1 und ein bestimmtes Technology Refresh.

Dieter

[LordCinimod]

Danke Dieter, ich bin noch nicht dazu gekommen mich damit zu beschäftigen, stecke gerade mitten in meiner Prüfungsphase und komme daher im Moment nicht viel zum rumprobieren und programmieren : (

Vielen Dank aber für deine Korrektur und die Erklärung dazu, werde mir das anschauen sobald ich wieder ein bisschen Luft habe(voraus. nächste Woche wenn alles gut geht ;D )

[Pikachu]

Das erinnert mich etwas an die Evolution eines Programmierers ...