Ist Delphi so Bedeutungslos ?

[Popov]

Zitat von musicman56:

Bin 57, hab noch 8 Jahre bis zur Rente, ...

Tut mir Leid, dass ich es bin der dir das sagen muss, aber wenn du 57 bist, dann hast du nicht 8, sonder seit letztem Jahr etwa noch 9 Jahre bis Rente.

Shit happens

Wenn du also an deinem 65'sten Geburtstag eine Abschieds-Rentenparty schmeißt und der Chef kommt rein und informiert dich, dass du noch 10 Monate länger arbeiten musst, dann tue wenigstes überrascht, auch wenn du es jetzt weißt.

[musicman56]

@Popov

Ich kann dich beruhigen. Den Zeitpunt wann ich in Rente gehe, den such ich mir selber aus. Ich bin seit 20+ Jahren selbständig. Die zitierten 8 Jahre sind nur eine Hausnummer die ich mir selber drauf geklebt habe.

[Medium]

Um noch mal das Thema "ich stehe für meine Bugs gerade" aufzugreifen:

Als "Underdog" (sprich alles, was nicht in aller Munde ist) bin ich halt dazu gezwungen, das quasi Unmögliche zu bringen: Ich muss ein Produkt haben, dass in Funktion, GUI und Features der ggf. bestehenden Konkurrenz ebenbürtig ist. Da ich aber vermutlich nicht so breit aufgestellt bin wie meine "großen Mitbewerber", muss ich in allen Punkten besser sein als dieser, weil mein Produkt optimistisch gesehen fast immer nur gleich gut / gleich mächtig werden kann. Darüber hinaus wird mein Produkt wohl aus dem selben Grund teurer ausfallen, da ich nicht über meine anderen 20 Sparten und Nischen kompensieren kann.
Wenn ich mich nicht in "Nebensächlichkeiten" wie Support, generellem Kundenkontakt, Engagement und generellem "Beinausreissertum" abhebe, ist mein Produkt letztlich eigentlich überflüssig. Das wird einem der Markt mittelfristig auch in seiner meist eher unfreundlichen Art sagen. Diese Dinge wären gerade die Killerfeatures für Produkte wie Delphi, wenn man von dem Rest TP-Veteranen (und wie in meinem Fall in gewisser Weise dessen Kindern) mal absieht. (Zumal das eine zügig schwindende Fraktion sein dürfte.) Wenn das Drumrum nicht sehr bald auf ein Niveau kommt, wo ich mich als Kunde ernst genommen und wichtig fühle, könnte das durchaus problematisch werden.

Und bitte. Der Verweis auf's QC ist doch Bullshit. Das dumme Ding hat nicht umsonst den Ruf, eher mäßig bedienbar zu sein, und eine Leichensammlung unbeachteter Bugs zu sein, denen keine Bedeutung beigemessen wird. Wenn man schon auf ein Bug-Tracking System verweist (und den direkten Support vermeiden will - was an sich ja schon ein No-Go ist), dann sollte es auch eine eigene Abteilung dafür geben, die sich wirklich darum kümmert die Dinge gründlich durchzugehen. Dann noch den Servicevertrag anzuführen finde ich wirklich hart. Der sollte für Fälle sein, in denen ich persönlich ein Problem habe, an dem ich nicht weiter komme. Wenn DAS für generelle Bugs nötig ist, dann ist der Service ohne Vertrag als gleich Null zu bewerten.
Weniger eigentlich: Rechne ich die Arbeitsstunden zusammen, die ich aufwende um herauszufinden, dass ein Fehler seitens Delphi vorliegt, addiere das mit der Zeit den Request einzustellen und das Demo-Projekt zu machen, und noch der Zeit (und Ablenkung von anderen Dingen die mein Geschäft eigentlich ausmachen) um meine Einträge nach Nachfragen/Lösungsideen/etc. nachzuverfolgen, wird ein QC Eintrag für mich als Geschäftstreibenden aber mal ganz schnell eine verdammt teure Sache. Der Support wäre daher also eigentlich als negativ einzustufen - man behindert mich zusätzlich zu den eigentlichen Bugs.


Wie machen wir das?
Wir müssen uns gegen so Kleinigkeiten wie Siemens und ABB behaupten. Mit einem 6-Mann Betrieb, der international tätig ist. Was tun wir? Rein funktional können sicher einige ähnliches bringen. Wir lassen uns aber zum einen voll auf Kundenwünsche ein, und schneidern nach Maß. Das geht bei "allgemeiner" Software wie z.B. Delphi nicht so richtig, aber was wir ebenfalls tun: Jeder Kunde kann uns zu jeder Tages- und Nachtzeit anrufen. Sogar wenn es etwas ist, was am nächsten morgen genau so gut ohne Einbußen behebbar wäre. Und auch wenn der Fehler letztlich in der Bedienung oder der von extern installierten Anlagentechnik ist: Wir reissen uns ein Bein aus den Fehler ANDERER zu finden und zu beheben, weil unser Job auch ist, die Funktion unserer Kunden zu gewährleisten. Kleinere Funktionserweiterungen werden unter der Hand innerhalb von wenigen Stunden/Tagen eingepflegt, dafür brauchen wir keinen Auftrag und stellen keine Rechnung. (Bei größeren Erweiterungen bzw. Umbauten dagegen schon.) Wenn einer anruft, spricht er spätestens nach einer Vermittlung mit dem Entwickler, der für den betroffenen Teil direkt und unmittelbar verantwortlich ist, und fachkundig Fragen stellen sowie Fixes erstellen kann. Oft noch im Gespräch.
Wir stellen auch sicher, dass ein Kunde möglichst immer mit den gleichen Personen in den gleichen Rollen zu tun hat. Er muss sich nicht damit plagen, Leute gedanklich "nachzurüsten", die das vorliegende Projekt nicht in- und auswendig kennen. Und all das leisten wir bei dennoch guter preislicher Konkurrenzfähigkeit zu den großen im Geschäft, und es sind eben genau solche Dinge, die auch unsere Kunden immer wieder als den Grund nennen, weshalb sie so gerne mit uns arbeiten. DAS sind die Sachen, mit denen man sich als kleinerer Mitspieler Bedeutung und Berechtigung verschafft. Emba verhält sich hier leider zunehmend wie eine Firma, die sich das locker leisten könnte. MEissings gut gemeinte, aber erkennbar gedrosselte 1-2-Zeiler helfen da leider auch oft nicht drüber hinweg (wobei ich mir auch darüber im Klaren bin, dass er persönlich fast sicher auch aktiver und umfangreicher schreiben würde, es aber einfach nicht kann/darf).

Das ganze Thema ist doch eigentlich sowas von Zentral! Wenn diese Dinge alle passen würden, da würde doch kein Hahn mehr nach Preisen krähen - dann wäre Delphi im Enterprise-Segment "der Shit", egal ob Neulinge jetzt mit Java, C# oder Python groß geworden sind. Business würde dann Delphi sprechen. Ähnliches gibt es bei DBs ja auch: Der Nachwuchs kommt über FB/MySQL, im Business Segment spricht man aber viel eher Oracle und MS SQL, die richtig Asche kosten. Anfüttern mit kostenlosen Versionen schadet sicherlich nicht, wäre aber in der aktuellen Situation wohl kaum mehr als ein verzweifelter Notnagel. (Am Rande: Kostenlos! Günstig reicht einfach nicht mehr, die Zeiten sind leider vorbei. Keiner kauft sich mal eben was zum testen, man läd Eclipse, #Develop, VS Express und eine Hand voll weiterer OS/Freeware IDEs runter um reinzuschnuppern. Dafür gibt doch keiner mehr Geld aus, nichtmals 1€, da der Bezahlvorgang an sich schon Hürde genug ist um den Browsertab ohne weiteren Gedanken daran zu schließen.)

[sh17]

Genau so siehts aus.

[Robotiker]

Zitat von Medium:

U
Das ganze Thema ist doch eigentlich sowas von Zentral! Wenn diese Dinge alle passen würden, da würde doch kein Hahn mehr nach Preisen krähen - dann wäre Delphi im Enterprise-Segment "der Shit", egal ob Neulinge jetzt mit Java, C# oder Python groß geworden sind. Business würde dann Delphi sprechen.

Das stimmt.

Ich frag mich immer wieder, welchen "Business" eigentlich Produkte wie den C++ Builder benutzt. Da gibt es jetzt endlich in XE3 einen 64-Bit Compiler. Der versteht endlich auch den aktuellen ISO-Standard. Gleichzeitig lässt man den 32-Bit Compiler so wie er ist, er unterstützt nicht mal den vorletzten Standard richtig. Wenn man also 32 und 64 Bit Versionen seiner Software herausbringen will, ist man gezwungen zwei Codebasen zu pflegen, oder einen Weg des kleinsten gemeinsamen Nenners zu finden.

Wenn ich die Newsgroup Beiträge von Emba Mitarbeitern richtig interpretiere, soll das auch erst mal so bleiben, bis irgendwann nach einem neuen Delphi Compiler auch ein neuer 32 Bit C++ Compiler kommt. Außerdem verweist man darauf, die meisten Windows PCs hätten heute sowieso 64 Bit. Sinnigerweise kann man aber für den Mac nur den alten 32 Bit Compiler liefern.

Zum Glück gibt es genügend andere C++ Entwicklungstools, der Builder spielt eigentlich keine Rollle mehr. Trotzdem frage ich mich weiter, welche Großkunden sich so ein Trauerspiel bieten lassen, irgendwer muss das Zeug doch kaufen ?

[sh17]

Vielleicht sollte man doch mal einen Fork von FPC erstellen, wo man direkt vom aktuellen Delphi migrieren kann. Ist das alles wirklich so komplex?
RemObjects schaffen das ja auch. Und wieviel arbeiten dort am Compiler? Wieviele Plattformen unterstützen die?

[JamesTKirk]

Zitat von sh17:

Vielleicht sollte man doch mal einen Fork von FPC erstellen, wo man direkt vom aktuellen Delphi migrieren kann. Ist das alles wirklich so komplex?

Ein Fork würde dir da nicht all zu viel nützen, da dennoch viele der aktuellen Delphi Features erst implementiert werden müssten. Hier ist die Liste derer, die ich weiß ("*" bedeutet, dass daran aktuell mehr oder weniger aktiv gearbeitet wird):

• Delphi kompatible Generics*
• Extended RTTI (+ RTTI Unit mit deren ganzen Spielereien)
• Anonymous Functions*
• Attributes*
• Dynamic Runtime Packages
• Unicode-fähige RTL/FCL* (damit wir bestimmte Plattformen von String=AnsiString auf String=UnicodeString umstellen können)
• Units der RTL/FCL Delphi kompatibel erweitern (z.B. Unit SyncObjs)

Da ist es geschickter diese gleich in FPC statt in einem Fork zu implementieren, dann haben alle was davon... Die Arbeit sich in FPC reinzuarbeiten hätte man so oder so und wir akzeptieren übrigens durchaus Patches für solche Features oder richten einen SVN Branch ein, wo man sich austoben kann (die Anonymous Functions werden zum Beispiel von jemanden implementiert, der kein Core Entwickler ist). Man sollte nur ein paar Kleinigkeiten beachten, aber ansonsten hat man da relativ freie Hand.

Zitat von sh17:

RemObjects schaffen das ja auch. Und wieviel arbeiten dort am Compiler? Wieviele Plattformen unterstützen die?

Wichtigster Punkt: Sie werden dafür bezahlt an sowas zu arbeiten. Im Gegensatz dazu arbeiten wir alle in unserer Freizeit als Hobby an FPC. Zu den unterstützten Plattformen von Oxygene (bitte korrigiert mich, falls ich falsch liege) zählen .NET, JVM und iOS (inwieweit hier Native kompiliert wird und ob i386 auch unterstützt wird kann ich nicht sagen).

Im Gegensatz dazu unterstützt Free Pascal die folgenden Plattformen:

• i386
• x86_64
• PowerPC(64)
• Sparc(64)
• Mips(64) (in Entwicklung)
• AVR (16 bit)
• AVR (32 bit) (in Entwicklung)
• M68k (inklusive Coldfire) (in Entwicklung)
• JVM/Dalvik
• ARM
• AArch64 (aka ARM 64) (in Entwicklung)

und die folgenden Betriebssysteme:

• Win32
• Win64
• WinCE
• DOS
• OS/2
• Linux
• FreeBSD
• NetBSD
• OpenBSD
• AIX
• Mac OS
• Mac OS X
• Amiga
• MorphOS
• Haiku
• Native NT API
• GameBoy Advance
• Nintendo DS
• Wii
• Android (native + Dalvik)
• Solaris
• Embedded (Entwicklung direkt auf der CPU)

Theoretisch haben wir noch ein paar weitere Betriebssysteme, aber deren Zustand weiß ich gerade nicht (Netware, QNX, BeOS, Watcom, PalmOS, Symbian).

Gruß,
Sven

[sh17]

meinetwegen auch direkt mit FPC. Aber eben halt weitestgehend kompatibel zum aktuellen Delphi (in erster Linie um gute externe Komponenten weiter nehmen zu können, VirtualTreeView als prominentes Beispiel) Ich würde da auch gar nicht soviel Russ um Rückwärtskompatibilität machen. Stand XE3, der Rest weg. RTTI, na gut, muss aber nicht primär.
Meinetwegen kann sich auch eine Firma dahinter klemmen, die dann das Geld mit der IDE verdient. Aber so bekommt man eine Alternative