Hallo Tom, und all die anderen,
"Die Energie für diese sich ständig wiederholende Diskussion könnte man auch effektiver verschleudern."
Dem stimme ich von ganzem Herzen zu. Danke auch für die Anerkennung.
"Nein, Xbase++ entspricht nicht dem Stand der Technik, wenn es um die IDE, die verfügbaren Tools oder die Art, wie heutzutage programmiert wird, geht, aber das ist auch nicht der Anspruch."
Da möchte ich doch - zumindest teilweise - wiedersprechen. Zu "Stand der Technik", naja Clipper hat Codeblöcke alla Lamda Expressions mit 5.0 eingeführt - damals von Lisp übernommen. .Net in 2007 und Java in 2014. Xbase++ ist eine dynamisch typisierte Sprache aus Überzeugung - der Type muss dem Model folgen, hat mal J.F. Codd gesagt, nur mit dynamischer Typisierung geht das. Der Type ist in Xbase++ im Datenmodel oder aber in der Klasse verankert. Das geht mit .Net seit 2015 und mit Java seit 2018. Prototype OOP ist der Grund, warum Javascript so sehr erfolgreich werden konnte und diese Mächtigkeit bei der Abbildung mehrschichtiger Probleme erreicht. Xbase++ kann seit 2014 Prototype OOP und von je her klassenbasiertes OOP. Mal sehen, wann Java oder .NET hier nachziehen.
Was ich damit sagen will ist, ja du hast recht, aber eben nur bedingt und gewiss nur aus deiner Perspektive - aber die Welt ist weit komplexer. Und ganz gewiss kann man mit Xbase++ so programmieren, wie es heutzutage gefordert wird - GOF / Fowler u.a.
Und ja, wir sind immer zu langsam - wir haben eben beschränkte Resourcen - muss aber auch nicht schlecht sein, wir sind seit mehr als 10 Jahren durchgängig profitabel und können in die Zukunft der Plattform, die wir toll finden, investieren. Wir haben die Produktentwicklung und die automatische Produktvalidierung in den letzten Jahren in einem unglaublichen Mass vorangetrieben. Unsere Balde-Center für die Durchführung der Validierung hat 224 Prozessoren und 1TB Hauptspeicher, damit wird jeder Build innerhalb weniger Stunden vollständig getestet ist. Deshalb können wir heute jeden Monat ein neues Update, mal mit neuen Features und mal mit Fixes, herausbringen. Und trotzdem noch das Produkt grundsätzlich umbauen und vorwärts bringen.
Auf jeden Fall verwehre ich mich ganz entschieden gegen dein letztes Statement:
"Aber, klar, mit der kaum noch - wenn überhaupt - neue Projekte geplant werden."
Also, verzeih mir, frei raus - das ist echter Stuss. Gerade in 2018 und jetzt in 2019 haben wir eine unglaubliche Anzahl von sogenannten Aufstockungen. D.h. Firmen, die bisher 1 oder 2 Lizenzen hatten, erhöhen jetzt plötzlich auf 3, 5 oder 10. Das passiert mittlerweile fast jeden Monat. Die Gründe sind immer wieder ähnlich. Erst wurde mit Xbase++ Jahre lang ein bestehendes Clipper System vorwärtsgetrieben, man wurde am Markt erfolgreich, ist gewachsen und dann musste entschieden werden, wie es weitergeht. Und jetzt wird es spannend, da gibt es einige, die dann nach Java oder aber .NET gehen und andere die sich klar für Xbase++ entscheiden. IMO interessant ist, dass gerade die Firmen, die sich bewusst für Xbase++ entscheiden, über das größte Gesamtwissen in der IT/Softwarebranche verfügen. Vor allem kleinere, gerade vertikale Lösungsanbieter, suchen hier oder da dann Ihr Heil in der ReImplementierung mittels .NET oder Java - traurig ist hier leider, dass die meisten scheitern - entweder ging Ihnen das Geld aus oder aber die Lösung ist nicht mehr wettbewerbsfähig. Ein Beispiel wäre da eine mehr oder minder bekannte Firma aus DE, die sogar Markführer in Ihrem Segment ist, dort wurde die Xbase++ Lösung in Java reimplementiert, nachdem die Firma mehrere Millionen Euro zusätzliche Entwicklungskosten geschultert hatte, wurde das Projekt gestoppt. Warum, naja weil in 4-5 Jahren ein Erfüllungsgrad von 10% der Xbase++ Lösung erreicht wurde.
Und diese Muster sind kein Einzelfall, leider ist das die Realität und leider haben die wenigsten Entscheider/Geschäftsführer den Schneid dann eine
falsche Entscheidung rückgängig zu machen - und deshalb wird dann manchmal auch das weiterverfolgt, was politische vielleicht korrekt, aber sachlich falsch ist.
Seht es doch mal so, welches wissen ist wertvoll? Genau, das Prozesswissen und das hat der Xbase++ Entwickler. Wenn jetzt neues Personal einen nativen Android Clienten mit Ionic erstellt und der neue Mitarbeiter für die UI Bootstrap mit AngularJS oder Vue.js verwendet, ist das völlig ok. Damit wird das Frontend zusammengebaut - und zwar für die .NET oder die Java oder NodeJS Anwendung. Das Frontend also die UI kommuniziert via XML oder JSON dann mit dem Xbase++ Microservice alla WebHandler. Und wenn wieder eine Kuh durch das Dorf getrieben werden muss, wird halt ein neues Frontend mit TypeScript und der neuesten Version von KendoUI zusammengebaut und dieses kommuniziert dann wieder mit dem Xbase++ Service.
Was ich damit sagen will, ist schlicht und einfach:
- Alaska Software ist seit mehr als 10 Jahren profitabel
- Wir nehmen den Investitionschutz für unsere Kunden sehr ernst
- Wir sind innovativ und zukunftsfähig
- Wir sind nicht perfekt
- Wir machen auch Fehler
- Das Werkzeug ist nicht nur rückwärtskompatibel, sondern vereint technologisch Zukunft mit Vergangenheit
Und über die Zeit kann man sich immer auf uns verlassen und das ist was zählt und das ist auch was uns von anderen am stärksten unterscheidet.
Mit besten Grüßen
Steffen F. Pirsig
Alaska Software Inc., Germany