Der anfang vom Ende von (Embarcadero-) Delphi

[mschnell]

.Net ist nachweislich ums zig fache langsamer als nativ erzeugte executables.

Hast Du das getestet ? (Ich auch nicht.) Glaube nur einer Statistik, die Du selbst gefälscht hast !Ws ich so gelesen habe, ist CLR Code "im Allgemeinen" halb so schnell bis nicht merklich langsamer. Aber es lassen sich sicherlich Beispiele finden wo CLR schneller oder auch viel langsamer ist als z.B. Lazarus.

Microsoft hatten immer schon ein fabel für interpreter das fing irgendwann mit Basic an und hört heute mit .net auf.

Man muss unterscheinden zwischen
- Script Interpreter (Java Script, einige Basics, ...)
- Byte code interpreter (Python, ander Basics, ...)
- Just in time Compiler (Java)
- Übersetzen beim Laden (CLR)
Hat alles unterschiedliche Einsatz-Gebiete und Performance-Eigenschaften.

Mono zieht mir einiger verzögerung nach. Die evrzögerung ist gross genug um 2/3 aller .net programme nicht auf Mono lauffähig zu haben.

Das betrifft nicht das CLR selber, sondern hauptsächlich die installierten - meist Plattform-abhängigen - Libraries (z.B. das, was der LCL entspricht und was man (obwohl das möglich ist) meist nicht mit ausliefert, eben weil es Plattform-abhängig ist). Wenn man Microsoft Tools zum Erzeugen seines "Assemblies" (CLR-"executable") verwendet, darf man sich nicht wundern, wenn es nur auf Windows läuft. Laut Remobjects ist es mit Oxygene (und demzufolge mit Prism) einfach, nur allgemein verfügbare Library-Calls zu verwenden.

Es ist natürlich richtig, dass Microsoft mit den bekannten Ordnungspolitisch fragwürdigen Methoden Marktmacht zu gewinnen versucht. Das heißt aber nicht, dass sie nicht einige gute und Zukunftsweisende Produkte entwickelt oder eingekauft haben. Word war - vor der Open Office Ära - sicher mit Recht das meist verwendete Schreibprogramm. MySQL hat lange gebraucht um an Microsoft SQL heranzukommen. CLR/C# ist maßgeblich vom von Borland Abgeworbenen Delphi-Chef-Entwickler erfunden worden.

Java ist doch soooo groooooß....

Java ist in keiner Weise tot und vermutlich so schnell auch nicht totzukriegen. Gerade die Plattform-Übergreifenden Eigenschaften werden sowohl mit Java-Script als auch mit Java-Bytecode überall in Browser-Applikationen verwendet. Eclipse ist (aus demselben Grund) in Java geschrieben und wurde vor einiger Zeit von den Linux-Kernel-Leuten als IDE für Linux-Programme empfohlen. Eclipse ist aber tatsächlich langsam und frisst unglaublich Ressourcen. Ich warte noch auf eine in CLR geschriebene Version von Eclipse .

-Michael

[mschnell]

Bitte die obige Aufzählung ergänzen!

http://en.wikipedia.org/wiki/Compiled_language" onclick="window.open(this.href);return false;

-Michael

[theo]

Hat alles unterschiedliche Einsatz-Gebiete und Performance-Eigenschaften.

Was mich daran stört, sind ja nicht die Systeme sondern dieser unsachliche Hype der damit immer verbunden ist.

- Wer Java nicht beherrscht, darf sich nicht Programmierer nennen.
- Java ist tot!
- Windows native ist tot, .NET ist die Zukunft.
- Wer das .NET Framework nicht auswendig kennt, kann einpacken.
- .NET ist Scheisse, Ruby ist die Zukunft.
- Pascal, gibt's das noch?

Ich habe alles mal ausprobiert und bleibe bei Object Pascal und PHP für's Web. PHP ist zwar technisch nicht sonderlich spannend, ist aber überall installiert und man findet alle Tricks auf dem Web.

Und dann immer dieses Produktiviätsgerede: Am Produktivsten ist man mit dem was man kennt.
Was nützen mir die fettesten Frameworks, wenn ich mich erst zwei Jahre einarbeiten muss. Davon ist die Arbeit auch nicht erledigt.
z.B. WebSphere http://de.wikipedia.org/wiki/WebSphere" onclick="window.open(this.href);return false;

[mschnell]

PHP für's Web.

Abgesehen davon, dass es vermutlich nicht so einfach ist ein Pascal-Programm als CGI auf dem Webserver zu installieren (hab ich aber schon auf einem "gemieteten" Server geschafft): Was ist der Vorteil von PHP gegenüber Pascal für CGI-Applikationen ? (Es gibt einige freie Libraries für GCI-Funktionen für Pascal und auch Lazarus hat eine (zumindest rudimentäre) Unterstützung).

-Michael

[ralli]

Theo spricht mir aus der Seele. Es spricht ja nichts dagegen, mal "fremd" zu gehen um auch ein bisschen mitreden zu können. Ich habe das QT Framework ausprobiert, auch eine grössere Anwendung damit geproggt, aber der Designer war mir nicht komfortabel genug. Da bin ich besseres gewohnt.
Dann habe ich einen grösseren Ausflug zu VB.NET gemacht, alles funktionierte sehr gut, aber ich hatte letztendlich das Gefühl, mit Kanonen auf Spatzen zu schiessen.Die IDE hat mir gefallen, aber da war Delphi seit 1997 schon wegweisend. ALso nicht wirklich Neues. Die Doku war gut, aber wenn ich stundenlang etwas suchen muss, dann geht die Produktivität und das eigentliche Ziel doch verloren. Und dann diese ewigen Glaubens- und Grabenkämpfe. Ich habe mich jetzt endgültig für Lazarus und Firebird entschieden. Läuft stabil und wird ausdrücklich für den Einsatz in Produktivumgebungen empfohlen. Für die Administration gibt es ja ibexpert Personal für den nichtkommerziellen Einsatz. Ausserdem ist flamerobin sehr gut. Als Berichtsgenerator ist dreport kostenlos für den nichtkommerziellen Einsatz. Es gibt für alles die richtigen Treiber und das Zusammenspiel klappt bestens. Also ich bleibe jetzt nach meinen Erfahrungen auch bei Objekt Pascal und Lazarus, weil ich da am schnellsten zu einem vorzeigbaren Ergebnis komme. Schuster bleib bei Deinem Leisten sagt der Volksmund, wie wahr.

[theo]

Abgesehen davon, dass es vermutlich nicht so einfach ist ein Pascal-Programm als CGI auf dem Webserver zu installieren (hab ich aber schon auf einem "gemieteten" Server geschafft): Was ist der Vorteil von PHP gegenüber Pascal für CGI-Applikationen ? (Es gibt einige freie Libraries für GCI-Funktionen für Pascal und auch Lazarus hat eine (zumindest rudimentäre) Unterstützung).

Dein Punkt 1 ist der eigentliche Killer für mich. Ich habe keinen Bock mit Sysadmins zu lamentieren.
"Nobody ever got fired for buying IBM." Bei Mainstream bei der Webtechnologie ist man nicht in Erklärungsnot.
Ausserdem finde ich Scriptsprachen schon praktisch für's Web, und zur Not kann auch ein anderer die Arbeit weiterführen oder einen Text ersetzen etc.

[_Bernd]

"Der Anfang vom Ende..."

Ich denke das war abzusehen. Ich selber bin bei Delphi 5 stehen geblieben. IDE und Compiler waren seinerzeit auf dem Stand der Technik (fand ich). Der Anschaffungspreis war moderat. Delphi 6 und 7 habe ich übersprungen, wobei ich wahrscheinlich Delphi 7 sogar heute noch für einen angemessenen Preis kaufen würde. Irgendwann später kam dann ein Update für mich nicht mehr in Frage, da eigentlich nur noch Hiobsbotschaften aus dem Hause Borland zu hören waren: Delphi 8 ziemlich schlecht, Delphi 2005 unbrauchbare IDE. Kurzzeitig dachte ich, daß man mit Turbo Delphi wieder an die alten Traditionen anknüpfen wollte: Stabil, schlank und schnell. Als ich dann feststellte, daß .NET vorausgesetzt wurde, habe ich nicht einmal mehr die freie Version getestet.

Ich denke der Abstieg begann schon Ende der 90er Jahre, als u. A. Hejlsberg und einige andere Schlüsselfiguren zu Microsoft gewechselt sind. Hejlsberg hat anschließend immerhin C# designed. Vermutlich waren diese Leute einfach nicht zu ersetzen.

Na ja, jedenfalls gab es dann noch die eine oder andere unschöne Nachricht über Software Activation, obskure Namensgebungen wie Delphi für PHP (jetzt Delphi Prism) und die Abkündigung von Kylix, was mich zwar nicht betraf aber doch meinen Eindruck von Borland/Codegear abrundete. Bleibt eigentlich nur zu hoffen, daß Codegear die Sprache Object Pascal nicht verstümmelt.

Ich würde mir wünschen, daß noch mehr Anwender Free Pascal/Lazarus verwenden. Vielleicht wird dann irgendwann mal eine kritische Masse überschritten, so daß Free Pascal/Lazarus die Standards (auch bezüglich der Sprache Object Pascal) setzen kann und nicht Codegear.

Gruß, Bernd.

[Christian]

Java ist in keiner Weise tot und vermutlich so schnell auch nicht totzukriegen. Gerade die Plattform-Übergreifenden Eigenschaften werden sowohl mit Java-Script als auch mit Java-Bytecode überall in Browser-Applikationen verwendet.

Tot ist natürlich immer ein sehr dehnbahrer begriff. Cobol ist auch nicht tot. Aber Java ist auf einem absteigenden Ast.

Ich hab hier schon mehrfach einen programmiersprachenbenchmark verlinkt. Dort werden glaub 10-15 verschiedene Programme getestet die evrschiedene Aufgaben erfüllen.
Ich hab den Link jetzt nicht merh zur hand aber dort sieht man sehr schön das .net eben nicht nur die hälfte langsamer ist als der vom fpc oder gcc erzeugte Code. Glaub war an die 15x so langsam.

@Bernd, Codegear hat Delphi verkauft gehört jetzt Embarcadero.
Ich profezeie mal das dies in nem Jahr an Schulzes Elektroladen in Hintermeierhofen verkaufen.

[creed steiger]

Ich hab hier schon mehrfach einen programmiersprachenbenchmark verlinkt. Dort werden glaub 10-15 verschiedene Programme getestet die evrschiedene Aufgaben erfüllen.

http://shootout.alioth.debian.org/" onclick="window.open(this.href);return false; ?

[mschnell]

Bleibt eigentlich nur zu hoffen, daß Codegear die Sprache Object Pascal nicht verstümmelt.

Meinst Du Embarcadero mit Prism/Oxygene ? die Oxygene-Sprache ist gegenüber der Delphi-Sprache bestimmt nicht "verstümmelt", aber doch in vielen Details deutlich anders.

-Michael

[mschnell]

Ich hab hier schon mehrfach einen programmiersprachenbenchmark verlinkt. Dort werden glaub 10-15 verschiedene Programme getestet die evrschiedene Aufgaben erfüllen.

Naja..... [ http://shootout.alioth.debian.org/gp4/b ... ng2=csharp" onclick="window.open(this.href);return false; ]

Free Pascal gegen C# auf Mono:

binary-trees 2.1
fannkuch 2.8
fasta 1.0
k-nucleotide 1.9
mandelbrot 1.2
n-body 1.7
nsieve 1.1
nsieve-bits 1.9
partial-sums 1.8
pidigits 1.1
recursive 2.2
reverse-complement 3.0
spectral-norm 1.6
sum-file 2.0
thread-ring 2.9

startup 70

Startup bewertet vermutlich die Lade-Zeit, die ist bei CLR natürlich viel höher. Da wird der CIL-Code ja in native-Code übersetzt. (Der Memory-Verbrauch ist natürlich auch entschieden größer bei CLR.)

Die Ablauf-Performance:
CLR ist bestenfalls gleich schnell, schlimmstenfalls 1/3 so schnell.
Der Durchschnitt scheint deutlich unter 2 zu liegen.

(Manche Javas sind übrigens etwa gleich schnell wie Free Pascal....)

-Michael

[theo]

Jetzt geht das wieder los...

[_Bernd]

(Manche Javas sind übrigens etwa gleich schnell wie Free Pascal....)

Bei den 64-Bit Maschinen sieht es dann gar nicht mehr so gut aus für Free Pascal:
http://shootout.alioth.debian.org/u64/b ... g2=fpascal" onclick="window.open(this.href);return false;
http://shootout.alioth.debian.org/u64q/ ... g2=fpascal" onclick="window.open(this.href);return false;

in beide Fällen 8 zu 3 für Java

Gruß, Bernd.

[theo]

Dafür ist der Memory Use fast immer besser bei FPC auch gegen GNU C, C++
http://shootout.alioth.debian.org/u64/b ... g2=fpascal" onclick="window.open(this.href);return false;
http://shootout.alioth.debian.org/u64/b ... g2=fpascal" onclick="window.open(this.href);return false;

Wahrscheinlich eine Optimierungs-/Gewichtungsfrage.

[creed steiger]

Jetzt geht das wieder los...

ich weiß ein bissl fruchtlos sind diese Vergleiche immer.
(Motto:Das passende Werkzeug für die passende Aufgabe)

Aber wenn die Entwickleranzahl/Finanzmittel anderer Projekte im Vergleich
zum FPC Team sehe,muß ich schon den Hut vor den
FPC Entwicklern ziehen.