Delphi am "Ende"?

[Delphi-Laie]

Zitat:

Zitat von Insider2004 (Beitrag 1076288)

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:

Zitat von Delphi-Laie (Beitrag 1076446)

FPC und Lazarus sind noch voll in der Betaphase

Lazarus: ja.
FPC: nein.

Der FPC ist schon soooooo lange raus da.

[Delphi-Laie]

Zitat:

Zitat von implementation (Beitrag 1076586)

Zitat:

Zitat von Delphi-Laie (Beitrag 1076446)

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:-D.

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:

Zitat von implementation (Beitrag 1076586)

Zitat:

Zitat von Delphi-Laie (Beitrag 1076446)

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:

Zitat von Delphi-Laie (Beitrag 1076587)

Zitat:

Zitat von implementation (Beitrag 1076586)

Zitat:

Zitat von Delphi-Laie (Beitrag 1076446)

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]

:-D 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:

Zitat von cookie22 (Beitrag 1076285)

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:

Zitat von Bernhard Geyer (Beitrag 1077993)

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. :stupid:

[Bernhard Geyer]

Zitat:

Zitat von Assarbad (Beitrag 1078149)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1077993)

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:

Zitat von Assarbad (Beitrag 1078149)

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

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:

Zitat von Bernhard Geyer (Beitrag 1077993)

Zitat:

Zitat von cookie22 (Beitrag 1076285)

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]

http://www.codeproject.com/Surveys/1...velop-des.aspx

Delphi nur auf dem vorletzten Platz. Wobei die Frage ist, inwieweit die Seite (die ich mehr dem C/C++/C#-Lager zuordnen würde) vielleicht der Grund für dieses "Zerrbild" (?) ist.

[Daniel]

Mit Blick auf Cocoa auf dem letzten Platz denke ich, dass die Zielgruppe wirklich zu C++/C#-lastig ist.

[Bernhard Geyer]

Zitat:

Zitat von Assarbad (Beitrag 1078597)

http://www.codeproject.com/Surveys/1...velop-des.aspx

Delphi nur auf dem vorletzten Platz. Wobei die Frage ist, inwieweit die Seite (die ich mehr dem C/C++/C#-Lager zuordnen würde) vielleicht der Grund für dieses "Zerrbild" (?) ist.

codeproject wäre ein der letzten Seiten die ich bei Delphi/Pascal-Fragen besuchen würde ...
Im Delphi-Forum gibt es gerade mal 188 Posts.

[Assarbad]

Sorry, daß ich das nochmal herauskrame - der Aspekt Geschwindigkeit wurde hier ja zuvor noch nicht so stark angesprochen. Vielleicht hat Embarcadero ja auch einen Kommentar zu dem Thema.

Hier mal ein Vergleich des Scimark Benchmarks (auch auf die Kommentare achten):

http://delphihaters.blogspot.com/201...nd-delphi.html

Es gibt da verschiedene Versionen, es ist wohl ein neuerer Port im VCS. Einerlei, die Delphi-Versionen scheinen irgendwie immer ziemlich schlecht abzuschneiden. Ihr könnt die Tests ja mal selber laufen lassen. Wäre ohnehin interessant das noch mit anderen Compilern zu probieren ...

Ich weiß, Performance ist nicht in allen Anwendungen wichtig, aber das Ergebnis ist doch (leider) sehr eindeutig.

PS: Ich weiß, daß der Name des Blogs nicht sonderlich vertrauenerweckend ist, aber man kann die Tests ja, wie gesagt, selber laufen lassen und vergleichen.

[Namenloser]

Es mag schon stimmen, dass andere Compiler, vor allem im Bereich C/C++, besser und aufwändiger optimieren als Delphi. Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert. In kaum einer anderen Sprache kann man so schnell mal eben Code schreiben, kompilieren und testen wie in Delphi.

Daran sieht man eben, dass Delphi mehr auf RAD ausgelegt ist, als auf hohe Runtime-Performance.

Andererseits hängt die Geschwindigkeit natürlich auch immer sehr stark von der Implementierung ab, deshalb sind solche Tests auch immer so eine Sache...

Mir persönlich hat die Performance unter Delphi eigentlich immer gereicht. Performacekritische Funktionen optimiere ich eh von Hand.

[Lemmy]

Super dass es hier wieder weiter geht... Die Atom-Geschichte wird langsam langweilig...

Delphi lebt! Immerhin werden wieder neue Bücher veröffentlicht... http://blog.marcocantu.com/blog/delp...ry_jensen.html

Dennoch: Danke Asserbad für den Link...

[Assarbad]

Zitat:

Zitat von Lemmy (Beitrag 1091877)

Delphi lebt!

Sonst wäre die DP ja auch tot. Aber ich wollte deswegen auch kein neues Thema aufmachen und dieses hier paßte und war nicht zu alt ...

[Phoenix]

Zitat:

Zitat von NamenLozer (Beitrag 1091874)

Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert.

Nunja, Multipass-Compiler haben allerdings auch ihre Vorteile. So geniale Sachen wie partial classes lassen sich eben nur dann umsetzen, wenn der Compiler auch später (d.h. wenn er an einem anderen File ankommt) noch eine Klassendefinition anpassen kann, und den Code dann in einem zweiten Durchgang fertig kompiliert.

Gerade bei Delphi sollte das noch nichtmal so sehr auf die Performance niederschlagen, da sich der erste Durchgang auf die Interface- Sektion und der zweite auf die implementation-Sektion beschränken kann. Es wäre als in Summe tatsächlich nur ein Durchlauf, der aber zweigeteilt wäre.

[Robotiker]

Zitat:

Zitat von NamenLozer (Beitrag 1091874)

Es mag schon stimmen, dass andere Compiler, vor allem im Bereich C/C++, besser und aufwändiger optimieren als Delphi. Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert. In kaum einer anderen Sprache kann man so schnell mal eben Code schreiben, kompilieren und testen wie in Delphi.

Daran sieht man eben, dass Delphi mehr auf RAD ausgelegt ist, als auf hohe Runtime-Performance.

Ich hatte ja schon mal in einem anderen Thread geschrieben, es gab mal ein Borland Produkt, wo man den Unterschied schön sehen konnte. Der C++ BuilderX enthielt in den größeren Versionen den Compiler aus dem C++ Builder 6, den Intel Compiler und den MingW (GNU Compiler für Windows) und konnte den Compiler aus dem parallel installierten Visual Studio 2003 verwenden.

Man konnte also in einer IDE den gleichen Code mit vier Compilern übersetzen. Die Unterschiede bei der Übersetzungszeit waren teilweise dramatisch. Ich kann mich an ein Projekt erinnern, da brauchte der Borland 16 Sekunden und der GNU knapp 3 Minuten.

Die Geschwindigkeit des erzeugten Codes war praktisch immer in der Reihenfolge Intel, MS, GNU, Borland. Aber sehr abhängig von dem, was da gerechnet wurde. Bei numerischen Sachen konnte sich der Intel extrem absetzen, Borland fiel weit zurück. Bei Stringoperationen (z.B. XML) praktisch kaum ein Unterschied zwischen MS und Intel, GNU und Borland gemeinsam etwas abgeschlagen.

Grundsätzlich gilt das heute zwischen C++ Builder XE und Visual Studio 2010 immer noch, alles was viel rechnet, wirkt mit dem bcc32 übersetzt etwas träge.

[HeikoAdams]

Aus meiner Vergangenheit weiß ich, das der Sybase PowerBuilder das Problem relativ elegant gelöst hat: zum Entwickeln und testen gibt es ein schnelles Compilieren ("Build"), bei dem nur die Änderungen neu übersetzt werden und für Releases ein gründliches Compilieren ("Full rebuild"), bei dem der komplette Sourcecode neu übersetzt wird. Vielleicht wäre das in Verbindung mit einem hochperformanten Multipass-Compiler eine Option für Delphi.

[himitsu]

Zitat:

Zitat von HeikoAdams (Beitrag 1091905)

zum Entwickeln und testen gibt es ein schnelles Compilieren ("Build"), bei dem nur die Änderungen neu übersetzt werden und für Releases ein gründliches Compilieren ("Full rebuild"), bei dem der komplette Sourcecode neu übersetzt wird. Vielleicht wäre das in Verbindung mit einem hochperformanten Multipass-Compiler eine Option für Delphi.

Gibt es doch auch schon jetzt, bzw. schon sehr lange?

> Compilieren > nur neues/geändertes Compilieren
> Erzeugen > alles neu Compilieren

[mkinzler]

Aber nur auf Unitebene. Die Units mit Änderungen werden komplett neu kompiliert.

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1091937)

Aber nur auf Unitebene. Die Units mit Änderungen werden komplett neu kompiliert.

Was Delphi leider auch nicht mitbekommt,
wenn man über die Projektoptionen oder als Parameter an den CommandLineCompiler einen/mehrere Compilerschalter übergibt,
dann bekommt Delphi diese Änderung nicht mit, wenn diese Schalter in einer Unit verwendet werden (z.B. {$IFDEF} ).
Wurde eine unit also als unverändert erkannt, egal ob sich Compilerschalter und somit die Quellcodeauswertung verändert haben (der Quellcode selber blieb j unverändert), dann wird blöder weise nicht neu kompiliert. :wall:

Ebenso kann dieses bei Includedateien passieren.

[Namenloser]

Zitat:

Zitat von Phoenix (Beitrag 1091893)

Zitat:

Zitat von NamenLozer (Beitrag 1091874)

Das sind aber im Gegensatz zu Delphi praktisch immer Multipass-Compiler, mit dem Nachteil, dass der Kompiliervorgang auch deutlich länger dauert.

Nunja, Multipass-Compiler haben allerdings auch ihre Vorteile.

Dass sie viele Vorteile haben, liegt auf der Hand. Die längere Kompilierzeit ist eigentlich der einzige Nachteil, der mir einfällt...

[Assarbad]

Zitat:

Zitat von NamenLozer (Beitrag 1091953)

Dass sie viele Vorteile haben, liegt auf der Hand. Die längere Kompilierzeit ist eigentlich der einzige Nachteil, der mir einfällt...

Hmm, wenn du Make oder ähnliches benutzt, ist das Problem aber relativ klein. In diesem Fall werden ja nur die geänderten Dateien neu übersetzt. Mithin ist die längste Phase bei mir immernoch das Linken. Deswegen wurde bspw. gold entwickelt. Sprich: eigentlich wird der spürbare Nachteil eher kleiner je mehr sich Linker entwickeln und je schneller Rechner werden.

[HeikoAdams]

Letztendlich wird da wohl jeder seine eigene Kosten-Nutzen Rechnung machen müssen: Wenn man z.B. schnelle und gut optimierte Programmdateien damit "bezahlen" muss, dass das Compilieren und Linken der Quellcodes länger dauert, dann ist das wohl für die meisten akzeptabel. Oder nicht?

[Assarbad]

Zitat:

Zitat von HeikoAdams (Beitrag 1091963)

Letztendlich wird da wohl jeder seine eigene Kosten-Nutzen Rechnung machen müssen: Wenn man z.B. schnelle und gut optimierte Programmdateien damit "bezahlen" muss, dass das Compilieren und Linken der Quellcodes länger dauert, dann ist das wohl für die meisten akzeptabel. Oder nicht?

Stimmt. Übrigens gab es da mal ein Buch, leider entsinne ich mich nicht mehr welches es war, das die ethische Komponente des Programmierens beleuchtete. Da wurde dann u.a. so argumentiert, daß die schnelle (!) und unkomplizierte Programmausführung X (mit: X > AnzahlEntwickler) Leuten Zeit spart, während die Ersparnis bei der Entwicklung sich meist auf die Entwickler beschränkt. Ich finde diese Sichtweise ganz passend.

[mschaefer]

Eigentlich ist die Compilezeit für mich kaum ein Problem. Den großen Nachteil von Delphi sehe ich eher im Doppellernen der Bibliotheken für WebEntwicklung und lokaler Applikationsentwicklung. Wenn ich Pascalroutinen und VCL in Webseiten einbauen könnte, bräuchte man nicht noch etxtra PHP und Framework.

[mkinzler]

Dann schau dir mal IntraWeb (VCL for the Web) an

http://www.delphipraxis.net/showthre...ferrerid=16048

http://sourceforge.net/projects/dws/

[QuickAndDirty]

Zitat:

Zitat von mschaefer (Beitrag 1092048)

Eigentlich ist die Compilezeit für mich kaum ein Problem. Den großen Nachteil von Delphi sehe ich eher im Doppellernen der Bibliotheken für WebEntwicklung und lokaler Applikationsentwicklung. Wenn ich Pascalroutinen und VCL in Webseiten einbauen könnte, bräuchte man nicht noch etxtra PHP und Framework.

Oder

Morfik.com

das ist schon seit Jahren etabliert!

[Phoenix]

Zitat:

Zitat von mschaefer (Beitrag 1092048)

Eigentlich ist die Compilezeit für mich kaum ein Problem. Den großen Nachteil von Delphi sehe ich eher im Doppellernen der Bibliotheken für WebEntwicklung und lokaler Applikationsentwicklung. Wenn ich Pascalroutinen und VCL in Webseiten einbauen könnte, bräuchte man nicht noch etxtra PHP und Framework.

VCL jetzt nicht, aber mit ASP.NET und Delphi Prism ist das kein Aufwand mehr.

[mschaefer]

Wenn ich schon die Einarbeitung in NET habe, dann kann ich auch gleich C# nehemn, da hier die Stundensätzte schlicht besser sind.

Soweit ich das bie IntraWeb weiss, kann ich da derzeit nur ein Projekt pro Server laufen lassen und eigetnlich fehlt mir da noch eine ReferenzServerKonfiguration um da einen eigenen Server zu betreiben.

Grüße in die Runde

PS: Habe schon mal einen Delphi Interpreter als PHP-Ersatz gesehen, ist aber derzeit verschollen

[Phoenix]

Zitat:

Zitat von mschaefer (Beitrag 1092070)

Wenn ich schon die Einarbeitung in NET habe, dann kann ich auch gleich C# nehemn, da hier die Stundensätzte schlicht besser sind.

Also für Delphi Prism rechne ich mehr ab als für simples C#. Gibt ned so viele Prism-Entwickler *g* ;-)

[mschaefer]

Das hat meinen Respekt!

Wenn IntraWeb bei der Professional nicht das Sessionlimit häte und eine Referenzserver der mehrere Intrawebablikationen gleichzeitig laufen lassen kann zur Verfügung stehen würde, dann hätte ich auch da Projekte. Aber so ist das kein vernüngtiges Kosten/Nutzen-Verhältnis.

[fox67]

Dadurch dass embacaderro nicht wie borland personal editions herausgibt oder andere kostenloste versionen die halt ein wenig eingeschrengt sind, gibt es immer weniger nachwuchs delphi programmierer. den wozu so viel geld aus geben wenn es visual c++ kstenlos gib? an schulen wird delphi nur (fast) noch unterichtet wenn die schule noch ein personal editon hatt.(schulen haben für alles geld nur nicht für software bestes beispiel ich hab mein lehrerin gefragt warum es an unserer schule kein delphi gibt sie meinte es wäre zu teuer dabei wurde vor einer wochhe die 2 Jahre alte Computer komplett gegen nageneue ausgetauscht und in der eingangs halle ist ein riesig großer LCD Fehrnseher auf dem neuigkeiten stehen. ich hab nichts gegn neue computer doch delphi wäre ir lieber gewesen)

[himitsu]

Und obwohl es für Schulen recht günstige Preise gibt, wird da oftmals noch meit D3 bis D5 gearbeitet.

Aber mit der kostenloasen freien Version hast du schon recht.
Wobei ich ja gerne was gezahlt hätte, aber leider ist dieses komische Starter absolut nicht für eine extensiverere hobbymäßige Nutzung geeignet. :cry:

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1092687)

Wobei ich ja gerne was gezahlt hätte, aber leider ist dieses komische Starter absolut nicht für eine extensiverere bobbymäßige Nutzung geeignet. :cry:

Jap, gebt mir Class Completion und eine Klassen-/Variablen-Umbenennfunktion [edit]und den VCL-Quellcode[/edit], und es wär gekauft... :?

[himitsu]

Letzteres sollten auch mit DevExpress und/oder CnPack möglich sein.
VCL-QuellCodes wären auch nett.

[Florian Hämmerle]

Zitat:

Zitat von NamenLozer (Beitrag 1092689)

Zitat:

Zitat von himitsu (Beitrag 1092687)

Wobei ich ja gerne was gezahlt hätte, aber leider ist dieses komische Starter absolut nicht für eine extensiverere bobbymäßige Nutzung geeignet. :cry:

Jap, gebt mir Class Completion und eine Klassen-/Variablen-Umbenennfunktion [edit]und den VCL-Quellcode[/edit], und es wär gekauft... :?

Zahl etwa 1000€ mehr und du bekommst es...

[isilive]

Ich bin auch davon überzeugt, dass es für das fortbestehen von Delphi extremst wichtig wäre
- kostenlose Schulversionen anzubieten
- kostenlose Personal Editions anzubieten
mit denen die Leute hineinschnuppern können. Ich selbst bin über Turbo Delphi 2006 eingestiegen. Ohne diese kostenlose Version hätte ich das sicher nicht gemacht, denn ich wusste damals noch gar nicht ob mir Delphi "gefällt".
- und für Ambitioniertere Hobbyisten eine günstige Version.

Ich denke man muss konkurenzfähig bleiben, und wenn VS in der Express Edition gratis ist, dann muss ich das als Embarcadero ganz einfach auch bieten wenn ich mir den Nachwuchs halten will. :coder:

Hat hier irgendwer einen Draht zu Embarcadero und kann das denen verklickern?

So wie vielen hier gefällt mir der Pascal Quellcode einfach am besten, und allein schon deswegen sollte Delphi weiterleben :!: