Delphi am "Ende"?

[Delphi-Laie]

Zitat von Insider2004:

Ich schätze, da werden ein paar hundert Bug Reports eintrudeln für Delphi 64 bit. Das Ding muss sich erstmal beim Kunden reiben. Das dauert. Diesen Schritt hat Lazarus 64 bit bereits hinter sich, weil es seit 5 Jahren im Feld ist.

Da lobt mal wieder jemand sein Lieblingskind in Bausch und Bogen.

FPC und Lazarus sind noch voll in der Betaphase, da liegt noch gar nichts "hinter sich", die Bugreports zeigen das auch. Den Vorsprung mit den 64 Bit und der Verfügbarkeit für mehrere Betriebsprogramme hat es allerdings Delphi weit voraus. Eigentlich eine Peinlichkeit für ein Softwareunternehmen.

[implementation]

Zitat von Delphi-Laie:

FPC und Lazarus sind noch voll in der Betaphase

Lazarus: ja.
FPC: nein.

Der FPC ist schon soooooo lange raus da.

[Delphi-Laie]

Zitat von implementation:

Zitat von Delphi-Laie:

FPC und Lazarus sind noch voll in der Betaphase

Lazarus: ja.
FPC: nein.

Der FPC ist schon soooooo lange raus da.

Nunja, alles ist Ansichtssache. Wenn der FPC sich nicht mehr im Betastadium befindet, ist es unerklärlich, warum immer noch auch Compilerfehler im Lazarus-Bugtrucker auftauchen. Wenn man Glück hat, werden die sogar bestätigt/anerkannt/akzeptiert und womöglich beseitigt.

Die fehlenden 64 Bit bei Delphi ließen mich auch dieser Software zuwenden, doch stelle ich generell - auch und gerade bei den Compilaten - ein etwas "unrunderes" Verhalten als bei denen mit Delphi erzeugten fest - man muß mit mehr Macken rechnen und hoffen, diese "irgendwie" "wegprogrammiert" zu bekommen (was durchaus klappen kann). Die 64 Bit finde ich gut, doch allein deshalb würde ich diese Software nie in Bausch und Bogen loben, wie z.B. den Betastatus als längst historisch hinstellen.

[michaelthuma]

Mhhh, also wir selbst haben etwas gelitten unter dem etwas unrunden Verhalten als wir uns dranmachten AnyDAC zu portieren auf zumindest mal auf Win64 - Problem mit Interfaces, das nicht zum Compilefehler führt sondern zu einer Exception zur Laufzeit*), war in der nächsten Beta relativ hurtig draußen ... aber gut ... Ich kann deinem Argument folgen ... Schicken wir mal über Jahre Software zum Kunden die run um die Uhr läuft ... das soll aber das Engagement und die tolle Leistung der FPC/Lazarus Leute nicht schmälern, die machen das nicht hauptberuflich und für das ist das Ergebnis erstaunlich. Eines der wenigen Projekte die mir bekannt Sinn, die so lange ohne einen großen Sponsor im Hintergrund durchgehalten haben.

Es ist angebracht bei Vergleichen wie

• MS <-> EMB
• EMB <-> FPC/Lazarus community

das aus der Situation gegebene Mögliche als Optimum vorauszusetzen und FPC/Lazarus schlägt sich ganz gut, genauso wie EMB im drübersthenden Vergleich. Ich habe kein Problem mal mir was mit dem FPC/Lazarus für IT zu entwickeln die ich selbst verantworte, aber es ist bestimmt nicht die Aufgabe eines Entwickler der einer externen IT gegenüber Verantwortlich ist den Compiler oder die Libraries zu patchen - im Sinne von groben Schnitzern.

*) Wer die 90er erlebt hat dem sind solche Sachen nicht fremd ... es ist durchaus der Delphi compiler der sehr streng ist und das zu recht.

In dieser Diskussion ... ich habe sie überfolgen ... Interessant ist es gibt 2 "64bit Compiler" derjenige der jetzt kommt und ein längerlaufendes Projekt.

Die ersten virtual machines für Assembler und virtuelle hosts (frühe Form der heutigen Virtualisierung die 30 Jahre danach in den PC Bereich einzog) gabe es im Mainframebereich seit den 60ern. Auch schon damals wurde Software auch nur ungerne, ob der Kosten neu geschrieben.

Möglw. zielt das längerlaufende Projekt darauf ab, mal die Speicherverwaltung der Runtime zu überlassen. Den Speicher selbst zu verwalten und ein Host Programmier sieht schon eher den Weg von Java oder .net mit einem Konstruktoraufruf als sehr gewagtes Experiment ... wenn auch im Enterprise Umfeld zugegeben. In diesem Kontext ist selbst Java in 6 und .net in 4 eigentlich eher sehr beschieden aus Sicht der Vision.

Für mich persönlich ist der wesentlich Punkt, auch wenn cookie22 zurecht sagt, das Delphi keinen guten Ruf in Mitteleuropa - in der Breite wohlgemerkt - hat mehere Gründe ... die mit dem Produkt selbst weniger zu tun haben, in Südamerika und USA war Delphi scheinbar fast ein Hypeprodukt - meiner Ansicht nach hat es aber mehr von der MS Schwäche profitiert, denn von der eigene Stärke und das hat sich jetzt gewandelt.

Aber einen Angriff auf den Markt braucht einfach mal naja 3 OSen und 32/64bit, vorher ist einfach die Strategie die bestehenden Kunden zu streicheln zu versuchen und leichte Zugewinne, wenn auch mit hohem Aufwand zu erzielen, sofern dieser Angriff jemals käme, der gangbare Weg. Aus EMB ist die Sache etwas komplexer - Fragmentierter Markt allumfassend vom Anwendungsgebiet als auch von der Kundensturktur, wenn auch im Moment dünn besetzt.

Man möge allein eines nicht glauben, dass die Leut die heut auf .net schwören mögen das bekommen was sie sich als Entwickler wünschen. Ich war auf einem Produkt der SAP, das denen einfach passiert ist ... SAP Businesswarehouse. Auf einmal haben fast alle begonnen das zu nehmen ... Spießrutenlauf für alle über 8 Jahre mit dem Ergebnis ... tonns of legacy... billions wasted ... und alle müssen damit leben. Fluch und Segen von Software ist, dass es ein Selbstläufer ist oder das Ergebnis bescheiden und hart umkämpft.

Die MS wird auch die Spark Programme nicht ewig haben laufen und Engineering Companies die nicht MS Produkte vertreiben sind der MS ein "Dorn im Auge". Im Moment mit MS Partnership 2500EUR fast alles für ein Jahr, halt mit Zertifizierung auf einem Produkt und Eintrag im Partnerregister - wird schwer sein im Software Engineering für Industries und gehobener Mittelstand was anderes zu platzieren. Wehe dem Tag and dem die MS die Partner in die Pflicht nimmt auf die von ihr angedachte Weise - IBM nur billiger und das kann man wohl mit Delphi umgehen oder open source. Ich kenne die MS jetzt naja 20 Jahre - eines war sowhol der MS als auch Apple immer so was von egal - Entwickler...

MS, da hat der Joel Spolsky nicht unrecht - die machen wirklich Fire & Motion. Aber vom Ergebnis her betrachtet mit .net 4.x haben wir jetzt ein funktionierendes COM+, ASP und ADO, bei dem man auf bestehender Hardware kaum Desktop Apps kann lassen laufen. Das ist nicht grad der ulitimative Heuler.

Denn eines ist klar, wenn die ASP.net Apps abgelöst werden in den Enterprises bestimmt nicht als Webanwendung. .net ist für Enteprises und das Spiel fangt in 2 bis 3 Jahren wieder an.

Apple hat wenigstens im Device Eck und auch im Gesamtkonzeptionseck einiges weitergebracht.

Selbst der jetzt dann noch dieses Jahr verfügbare Compiler hat schon einiges an Neustrukturierung erfahren. Ich bin optimitisch, klar ist der Compiler spielt für die meisten schlicht keine Rolle beim Kauf, aber am Schluß zählt der Binary der läuft und heute ist fast alles 24*7 von der Betriebs- und Deployment Komplexität.


[QUOTE=Delphi-Laie;1076587]

Zitat von implementation:

Zitat von Delphi-Laie:

FPC und Lazarus sind noch voll in der Betaphase

Lazarus: ja.
FPC: nein.
... , warum immer noch auch Compilerfehler im Lazarus-Bugtrucker auftauchen. Wenn man Glück hat, werden die sogar akzeptiert und womöglich beseitigt.
.

[cookie22]

Zitat von Delphi-Laie:

Zitat von implementation:

Zitat von Delphi-Laie:

FPC und Lazarus sind noch voll in der Betaphase

Lazarus: ja.
FPC: nein.

Der FPC ist schon soooooo lange raus da.

Nunja, alles ist Ansichtssache. Wenn der FPC sich nicht mehr im Betastadium befindet, ist es unerklärlich, warum immer noch auch Compilerfehler im Lazarus-Bugtrucker auftauchen. Wenn man Glück hat, werden die sogar akzeptiert und womöglich beseitigt.

Die fehlenden 64 Bit bei Delphi ließen mich auch dieser Software zuwenden, doch stelle ich generell - auch und gerade bei den Compilaten - ein etwas "unrunderes" Verhalten als bei denen mit Delphi erzeugten fest - man muß mit mehr Macken rechnen und hoffen, diese "wegprogrammiert" zu bekommen (was durchaus klappen kann). Die 64 Bit finde ich gut, doch allein deshalb würde ich diese Software nie in Bausch und Bogen loben wie z.B. den Betastatus als längst historisch hinstellen.

Fpc ist Open Source also ist es mehr oder weniger immer im Wandel oder anderes gesagt es ist immer irgendwie im Beta-Stadium.

Lazarus ist mehr Alpha als Beta. Musste nach langer Zeit mal wieder damit Arbeiten und es war wie immer der reine Horror, nichts funktioniert richtig und irgendwie ist alles total hackelig. Wenn man von Delphi ab D2007 und den MS IDEs verwöhnt ist, geht Lazarus wirklich gar nicht.

[michaelthuma]

Das bestimmt.

Erschwerend und für die Verbreitung - Für Einsteiger ist das ein wenig hart. Die Lazarus Leut sind schlicht patschert ... wenns darum geht für Ein- und Umsteiger egal woher etwas anzubieten, das sich leicht läßt installieren, wenn man den Anweisungen auf der Website folgt. Sie gehen davon aus, dass ein Delphi Entwickler der typsicher User wäre und das wird auf die Art schnell eine Art selbst erfüllende Prophezeiung ...

Es ist ihnen auch egal. Das Thema Lazarus als Delphi Ersatz, das eigentlich mehr den Delphi Leuten zuzuschreiben ist, die nach 64bit und andere OSen suchen im Moment. Es ist nicht das Projektziel.

Die 0.9.29 läuft schon recht gut. Unter Linux ists schon ein Fortschritt.

Bunny

[Bernhard Geyer]

Zitat von cookie22:

Windows für ARM ist gerade angekündigt, X64 gibt es seit Jahen. Das ist wohl ein großer Unterschied.

Hier ein Update zur "Windows auf ARM-Prozessoren"-Ankündigung

[Assarbad]

Zitat von Bernhard Geyer:

Hier ein Update zur "Windows auf ARM-Prozessoren"-Ankündigung

Ich würde eher annehmen, daß es eine strategische Aussage ist. Er hat zwar nicht unrecht, aber andererseits pflegt MS schon seit zwei Jahrzehnten Windows auf anderen Architekturen als ihrer "Heimat-Architektur"

Aber nur die Zukunft wird uns zeigen was wirklich Sache ist.

[Bernhard Geyer]

Zitat von Assarbad:

Zitat von Bernhard Geyer:

Hier ein Update zur "Windows auf ARM-Prozessoren"-Ankündigung

Ich würde eher annehmen, daß es eine strategische Aussage ist. Er hat zwar nicht unrecht, aber andererseits pflegt MS schon seit zwei Jahrzehnten Windows auf anderen Architekturen als ihrer "Heimat-Architektur"

Also das "normale" Windows läuft nur auf x86/x64. Die Itanium-Schiene läuft auch bald aus. Und wieweit Windows Phone/CE den gleichen Quellcode teilt wird man vermutlich nur als Mitarbeiter mit VSS-Zugriff wissen.

Zitat von Assarbad:

Aber nur die Zukunft wird uns zeigen was wirklich Sache ist.

Das stimmt. Solch eine Ankündigugn hat bisher eher die Relevanz/Wichtigkeit wie die Ankündigung das das nächste (oder doch nicht) Windows nur noch .NET-Code "native" ausführen kann und Win32 nur noch emuliert wird.

[michaelthuma]

Interessant - hatte ARM bestenfalls im Kontext von PADs oder tablets vermutet, die Windows embedded Schiene ist irgendwie eher - sucht keiner dort, liefe aber mit mehr oder weniger Standard Windows. Intel wird sich die Server Räume so leicht nicht nehmen lassen - Rückzugsgebiet für das PC Konzept auf mittlere/lange Sicht - je nachdem was im Privatbereich der Primary Device wird. Der Atom hält langsam Einzug dort wo früher noch "gelötet" wurde ... Spezialchips sind kaum mehr länger als 6 Monate verfügbar ... dort punkten sie und sind beliebter als FPGA mit dem Atom. Das ist ein Eck das kann dem Delphi Entwickler durchaus entgegen kommen, auch wenn EMB sich dort nicht wirklich sieht.

Denke ARM hat sich da ganz fest im mobile Eck eingenistet und intelligente commodity chips. Intel produziert ja sonst auch noch, von PC Chips und Prozessoren leben die nicht allein.

Eher wilde Spekulation, dass ARM einen Serverchip bauen im Moment oder das MS da jemals eine gewichtige Rolle spielt. Man kann an sich mit einer schlichteren Struktur der Befehlssätze einiges erreichen, das war am 68000er noch so, aber eigentlich die physischen Register im Intel sind ja schon fast unzählbar - d.h. Dinge wie Register Renaming macht an sich der Prozesser eh selber - eher wohl schauen, dass man keine stalls kriegt in der Pipeline und keine Alignment Strafen, aber selbst die sind mit DOS Programmen am Pentium Pro nicht aufgefallen und heute sind wir 16 Jahre danach... die Chips bügeln so manche Eselei von uns unter der Haube aus.

Was braucht Strom - Prozessor und Festplatte ... zweite ist da eher unter Ablösezwang ... von der Energieeffizienz her und weil die Festplatte schlicht der letzte mechanische Teil ist. Dann wird es wieder lustig, weil man dann möglw. auf chaches kann verzichten und DBS mit großen Cache, weniger buffering ...

Bunny

Zitat von Bernhard Geyer:

Zitat von cookie22:

Windows für ARM ist gerade angekündigt, X64 gibt es seit Jahen. Das ist wohl ein großer Unterschied.

Hier ein Update zur "Windows auf ARM-Prozessoren"-Ankündigung