Delphi-Projekt-Argumentesammlung u.Vergleich

[D-User]

Ich weiss, ist nicht der erste Thread hier über solches oder ähnliches Thema (hoffe die Forumsmacher sind nicht zu genervt), aber wohl der Erste der im ersten Beitrag mal konkreter zusammenzufassen versucht mit Argumenten. Ich denke, auch vielen noch nicht aufgeführten Argumenten, um das mal etwas zu versachlichen.
Also, gerne ergänzen, weitergeben, weiterverwenden, Links (auch auf schon ähnliche solche, irgendwie immer wieder unvermeidliche Threads ), Beispiele und Erfahrungsberichte anfügen etc:
----------------------------------------------------------------------


Vorteile Delphi/ Object Pascal mit Vergleich Delphi/Java/C++

Sinngemäße Zusammenstellung aus div. Quellen und noch ein klein wenig eigene Erfahrung;
Sollte jeder Projektverantwortliche mal unter die Nase gerieben bekommen, und darf natürlich weiterverbreitet werden, also:



Kosten ]werden bestimmt durch Wartbarkeit, Eignung für das Einsatzgebiet und Nachhaltigkeit.
Unter Nachhaltigkeit in dem Zusammenhang versteht man den Aufwand für einen Versionswechsel der Entwicklungsumgebung, d.h., wieviel Kosten verursacht es, auf eine modernere Version des Entwicklungssystems umzusteigen; dies ist z.B. wesentlich beeinflußt durch Änderungen im Sprachkonstrukt und ob eine rahmengebende Institution hinter der Entwicklungsumgebung steht, die dafür sorgt dass die Dinge einheitlich und geordnet verlaufen.
Die Toolkosten selber, so sie im Bereich von Tausend oder wenigen Tausend Euro liegen, spielen im Vergleich mit obigen Faktoren i.A. eine untergeordnete Rolle.



Thematisches Einsatzgebiet Delphi:
-Alles bis auf Treiber, wo man am Besten direkt in Assembler oder C schreibt
-größeres Einsatzgebiet als Java, da direkt in Assembler innerhalb des Programms programmiert werden kann, also keine prinzipiellen Restriktionen hat, und mit Zeigern operiert werden kann und keine Sandbox-Einschränkungen existieren, die man, insbesondere wenn es komplexer wird und man schon viel investiert hat, bereuen könnte.
-Sehr einfache plattformübergreifende GUI-Erstellung
-Komponenten mit sehr guter Kapselung bis hin zum dll/Package-Level können in Delphi selber geschrieben werden, und die sogar in die IDE eingebunden werden können und graphisch ( Bausteinmodell ) verwendet und einzeln weiterverkauft werden können (z.B. im Gegensatz zu VB)
-Server- und Datenbankentwicklung schon seit Delphi 1 integriert und möglich.


Investitionssicherheit und Nachhaltigkeit:
-Wartbarkeit: Wesentlich klarerer und damit wartbarer Code als mit C/C++, siehe Vergleich unten und [1].
-Sehr grosse Anzahl freier und kommerzieller, einfach zu nutzender Komponenten.
-Stabile Plattformbasis, also nachhaltige Investition:
Ein kürzlich von Delphi1 geschriebenes größeres Projekt liess sich erstaunlich einfach und schnell auf Delphi 2010 hochziehen: Nachhaltigkeit.
-Via Free-Pascal / Lazarus existert ein Fallback auf fast allen verfügbaren Plattformen, zur Zeit wohl sogar eine größere Plattformbasis als Java.
-durch den einfach decompilierbaren Bytecode der Dot-Net-Sprachen und in Java exportiert jeder Verantwortliche, der Programm(Teile) in einer dieser Sprachen ausser Hauses gibt oder gelangen läßt, i.A. Firmengeheimnisse. Dies sollte er sich sicherheitshalber vorher schriftlich genehmigen und bestätigen lassen.
Da solche Firmengeheimnisse „kriegsentscheidend“ für eine Firma sind, kann tatsächlich das dann zufällig kurz danach auftauchende Konkurrenzprodukt aus chinesischer Produktion den Tod der Firma einleiten.
Diese Folgen waren dann vorhersehbar, der Verantwortliche sollte verantwortlich gemacht werden.
-Die in Dot-Net-Plattformen und Java erforderliche Laufzeitbibliothek verringert die Kontrolle über das Programm beim Endkunden, da in einer Laufzeitbibliothek mit Folgeversionen unerwünschte Veränderungen untergeschoben werden können. Auf Betriebsssstemebene ist von der Existenz solcher Mechanismen auszugehen, siehe Stichwort "Managed Code".
-Die in Dot-Net-Plattformen und Java erforderliche Laufzeitbibliothek ermöglicht Aussenstehenden Einfluss auf das Programm. Es kann z.B. ein Kontroll-Layer zwischen Programm und Laufzeitbibliothek geschoben werden, der das Programmverhalten analysiert bzw. verändert. Hier gibt es für den Programm-Ersteller keine wirklichen Kontrollmöglichkeiten, er wird aber i.A. verantwortlich gemacht für das Fehlverhalten, der schlimmstenfalls rechnerspezifische Nachweis der Unschuld kann teuer werden.
(Mit solch einem Layer könnten also durch die Konkurrenz Programmhersteller von Bytecode-Programmen womöglich schlimmstenfalls sogar systematisch bankrottiert werden )
-Durch den prinzipiell layerbaren zusätzlichen Zugriffslevel in Dot-Net-Plattformen und Java entsteht eine ebenso prinzipielle Sicherheitslücke, deren Tragbarkeit der Verantwortliche im Vorhinein rechtfertigen sollte!!
-Eine Plattform, im Gegensatz zu z.B. mehreren Main-Java-Plattformen wie Netbeans bzw.
Eclipse.

Sicherheit:
Die berühmten Speicherlecks in C++ - Programmen sind kein Zufall, und die in C++ dafür verantwortlichen Fehler-erleichternden Konstrukte sind ja in Java eliminiert worden



Ressourcen / Abstützung in der IT-Welt:
-riesige Mengen Source in Pascal, zudem die oben erwähnten Komponenten, man schaue sich das Projekt Jedi an
-auch auf andere Sourcen zugreifbar, siehe das Jedi-header conversion -Projekt [3]




Beispiel Vorteile gegenüber Java:
-Bessere Möglichkeiten, Know-How-Klau zu verhindern:
1. Non-Class-Functions verfügbar, sind u.a. im Compilat auch besser vor Reverse-Engeneering geschützt als Methoden.
2. Inline-Assembler, liefert gleichzeitig auch die Möglichkeit es auf die Spitze zu treiben, wenn das Programm mal besonders schnell/optimiert sein muss.
3. Variante Typen
4. Enums schon seit Anfang an, Grundkonzept
5. Keine Boxing-Krankheiten ( aber natürlich kann man so etwas wie Boxing auch in Delphi machen, wenn man denn will )
6. Da Java ziemlich C++-Like ist, kann man eigentlich auch direkt in C++ schreiben, man hat dann direkt mehr Handlungsmöglichkeiten. Allerdings dann auch mit den bekannten Nachteilen.
7. Information- Hiding, ein essentielles Grundkonzept in der Informatik, fundamental enthalten in Delphi/Pascal-Units, schon von Anfang an, via interface/implementation;
Erhöht Lesbarkeit/Wartbarkeit deutlich
So nicht vorgesehen in C++/Java
8. Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss. Man hat volle Kontrolle über Speicher-Belange, man kann sogar einen eigenen Speichermanager in Delphi selber schreiben und benutzen.
9. Wesentlich feinere Scopes als in Java, daher bessere Kontrolle darüber zusätzlich zu oben angeführten Information-Hiding-Aspekten.
Erhöht Wartbarkeit und senkt Fehleranfälligkeit.
10. Auch solche Dinge wie Operator Overloading vorhanden, die allerdings nur einen sehr fraglichen Sinn in Java machen würden, weil sich dieses dann langsam so C++ annähert dass es total verzichtbar wird.

Nicht zuletzt möchte ich dann da auch noch die Erfahrung in einem wirklich grossen Projekt mit einwerfen, das zuerst in Java versucht wurde, scheiterte und dann in Delphi gelang. Auch Skype in Delphi erstellt, ebenso sehr viele andere Projekte( google embarcadero Showcase delphi ).


Prinzipielle Unterschiede/Vergleich Pascal/C/C++ :
In C zu programmieren ist prinzipiell aufwändiger, fehleranfälliger und damit teurer, da man „näher am Assembler“ programmiert.
Zum Memory Management:
Zitat aus [1]: „Memory management is a nightmare in C++ because much of the allocation and deallocation is done automatically in C++'s libraries. These libraries are optimized for speed so that you can't step through them when you are trying to debug your inevitable memory problems.“
übersetzt:
„Memory Management ist ein Albtraum in C++ viel der Reservierung und Freigabe automatisch in C++-Bibliotheken abläuft. Diese Bibliotheken sind auf Geschwindigkeit optimiert, so dann man beim Debuggen nicht durchgehen kann wenn man auf die unvermeidlichen Speicherprobleme trifft.“
(Das erklärt dann auch die Never Ending Story der Speicherlecks in C++-Programmen, und unter [1] findet sich auch das berühmteZitat des Informatik-Gottes Hoare zu C )

Zitat aus [2]: „Die Geschichte von C ist, wie viele wissen, an die von UNIX gekoppelt. Die ersten Versionen von UNIX entstanden noch in Assembler. Kerningham und Ritchie arbeiteten damals mit der Sprache BCPL, einer Sprache, um systemnah zu programmieren. C entstand aus BCPL. (Es ist der nächste Buchstabe im Alphabet). Das Ziel war, dass man eine Sprache hatte, die Assembler für die Programmierung von Betriebssystemen und systemnahen Programmen ersetzen sollte.
C unterscheidet sich daher schon von der Konzeption von Pascal. Viele sehen es als einen Zwischenschritt zwischen Assembler und einer höheren Programmiersprache an, sehr oft stolpert man über den Begriff "Superassembler". Ich finde diesen sehr passend, denn wie in Assembler gibt es in C nur wenige nicht elementare Datentypen. Wie in Assembler verzeiht die Sprache keine Fehler und hat nur rudimentäre Prüfungen implementiert“
..........

„Anstatt C weiter zu entwickeln gibt es C++. C++ beinhaltet als Untermenge C. Darüber hinaus ist die Sprache sehr komplex, weil ihr Schöpfer Bjarne Stroustrup meint, dass eine Sprache leistungsfähig genug sein muss alle Anwendungsgebiete abzudecken. Die Tatsache das C als Untermenge enthalten ist macht die Bewertung schwierig. Zwar hat C++ für viele C Probleme Alternativen geboten - Templates als Ersatz für Makros, Referenzen als Ersatz für untypisierte Pointer bei der Übergabe und Objekte anstatt Zeiger auf Structs. Doch man muss sie nicht benutzen, weil C eben noch als Untermenge enthalten ist. Dementsprechend gibt es "C ähnliche" C++ Entwicklungssysteme und mehr "Java ähnliche" Entwicklungssysteme. Zum ersten gehört sicher Visual Studio, wo ohne unzählige Makros, vagabundierende Pointer auf GDI Objekte und Ressourcen man meint dass man C anstatt in C++ programmiert. Auf der anderen Seite gibt es Komponenten basierende Entwicklungsumgebungen wie den CBuilder, der mit Objekten, Eigenschaften und Methoden arbeitet. “




[1] Object Pascal beats C++
A down to Earth comparison between Object Pascal and C++
http://pascal-central.com/compare.html

[2] http://www.bernd-leitenberger.de/pascal-und-c.shtml

[3] http://www.delphi-jedi.org/

[Bernhard Geyer]

Ich stürz mich mal nur auf einen Teilbereich:

Zitat:

Beispiel Vorteile gegenüber Java:
-Bessere Möglichkeiten, Know-How-Klau zu verhindern:
1. Non-Class-Functions verfügbar, sind u.a. im Compilat auch besser vor Reverse-Engeneering geschützt als Methoden.
2. Inline-Assembler, liefert gleichzeitig auch die Möglichkeit es auf die Spitze zu treiben, wenn das Programm mal besonders schnell/optimiert sein muss.
3. Variante Typen
4. Enums schon seit Anfang an, Grundkonzept
5. Keine Boxing-Krankheiten ( aber natürlich kann man so etwas wie Boxing auch in Delphi machen, wenn man denn will )
6. Da Java ziemlich C++-Like ist, kann man eigentlich auch direkt in C++ schreiben, man hat dann direkt mehr Handlungsmöglichkeiten. Allerdings dann auch mit den bekannten Nachteilen.
7. Information- Hiding, ein essentielles Grundkonzept in der Informatik, fundamental enthalten in Delphi/Pascal-Units, schon von Anfang an, via interface/implementation;
Erhöht Lesbarkeit/Wartbarkeit deutlich
So nicht vorgesehen in C++/Java
8. Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss. Man hat volle Kontrolle über Speicher-Belange, man kann sogar einen eigenen Speichermanager in Delphi selber schreiben und benutzen.
9. Wesentlich feinere Scopes als in Java, daher bessere Kontrolle darüber zusätzlich zu oben angeführten Information-Hiding-Aspekten.
Erhöht Wartbarkeit und senkt Fehleranfälligkeit.
10. Auch solche Dinge wie Operator Overloading vorhanden, die allerdings nur einen sehr fraglichen Sinn in Java machen würden, weil sich dieses dann langsam so C++ annähert dass es total verzichtbar wird.

zu 1: Einfach Obfuscator drüber laufen lassen und du kann versuchen mit einer aaa.bbdeee-Methode denn Sinn zu erkennen

zu 2: Es gibt nur relativ wenige Bereich in diese Assembler-Support relevant wäre. Und dann hat ja Delphi mit der fehlende optimierten GPU-Unterstützung auch so seine Probleme

zu 3: Vermisse ich nicht. Und diese Konzept hat man mit AutoBoxing von Basistypen letztendlich fast auch.

zu 4: Geschichtliche Entwicklung interessiert nicht mehr. Java-Enums sind viele mächtiger und sparen uns bei der portierung einige Zeilen code und Helper-Funktionen

zu 5: Wenn man weiß was man vermeiden soll dann ist es keine Problem. In Delphi wäre diese "Boxing" die automatische Referenz-Zählung von Strings. Wenn mann sich auf diese verlässt und die Const-Angaben nicht macht bekommt man auch Performance-Probleme

zu 6: Absolutes Kontra! Ich habe keine Probleme mit java aber möchte mich nicht mehr mit C/C++ rumärgern.

zu 7: Das Information-Hiding ist in Java viel besser. Manche Kontepte gibt es selbst in neuesten Delphi-Versionen noch nicht.

zu 8: Ach wäre es schön wenn man diesen manchmal hätte ...
Zwangsbauen sind seit Jahren eigentlich kein Problem mehr. und deinen eigenen Speichermanager kannst du AFAIK auch in Java schreiben.

zu 9: Absolutes Kontro! Beschäftige dich mal ohne Vorurteile richtig mit Java.

Zitat:

Nicht zuletzt möchte ich dann da auch noch die Erfahrung in einem wirklich grossen Projekt mit einwerfen, das zuerst in Java versucht wurde, scheiterte und dann in Delphi gelang.

Diese meisten diese Projekte sind m.E. primär an den fehlenden Fähigkeiten/Knowhow der Entwickler/Projektleiter/Systemarchitekten gescheitert. Die Programmiersprache dürfte in den wenigesten Fällen ein Hauptgrund des Scheiterns gewesen sein.

[p80286]

lieber D-User,
nachdem ich jetzt weis wie toll Delphi ist, steige ich dann mal auf c/c++ um.

-Server- und Datenbankentwicklung schon seit Delphi 1 integriert und möglich. Das war der Grund sich von TP zu verabschieden und auf D4 umzusteigen.
Welch wunderbare Erkenntnis, daß man mindestens Prof. dafür braucht/brauchte um wenigstens rudimentär mit Datenbanken zu arbeiten. Gleichzeitig darf man dann noch zusätzliche Bibliotheken suchen/erwerben um richtig zu arbeiten. Ich verstehe unter "integriert" etwas anderes.

Gerne wird angeführt, daß durch die Zeigerlastigkeit c zu fehlern neigt. In Delphi sind Zeiger nicht so notwendig, aber wenn sie denn dann doch einmal verwendet werden, knallt es genauso häufig wie unter c.
Man muß sich nur einmal hier umsehen, wieviele unerklärliche Fehler durch falschen Umgang mit Zeigern verursacht werden.

Delphi/Pascal ist eine Sprache die mir liegt, und damit ist gut.
Diese seltsamen Überhöhungen kann man sich ruhig schenken.

Gruß
K-H

[Elvis]

Ich glaube kaum, dass du mit so einer Liste jemanden überzeugen kannst, der weiß, was er an Delphi und was er an C# hat.

Ich würde nicht im Traum daran denken ein neues Projekt mit Delphi anzufangen. Außer es gäbe einen ganz besonderen (technischen!) Grund, warum es nicht mit C# lösbar oder sinnvoll ist.

IMO grenzt das doch schon fast an vorsätzliche Geldvernichtung.

Delphi als Sprache mag vllt zugänglicher sein, als klassiches C++. Aber das ist schon sehr, sehr weit hergeholt.
Klassisches C++ ist ein ziemliches Extrem, IMO. Damit zu vergleichen bringt dir nicht wirklich etwas.
Verglichen mit sauber durchdachten Sprachen wie C# merkt man einfach ganz schnell was für ein furchtbarer Wildwuchs Delphi wirklich ist.
Pfft, man kann bei einem Methodenaufruf nicht einmal sehen ob es out- oder var-Parameter gibt. Man kann also selbst bei einzeiligen Funktionen nicht erkennen, ob sie "pure" sind. Und das ist noch einer der weniger schlimmen Patzer.

Mit dem VS und NuGet kann ich einfach an irgendeinem Rechner meinen Code auschecken und mir werden alle externen Abhängigkeiten sofort heruntergeladen und an die richtigen Stellen gepackt.
Kein Komponenteninstallieren, Suchpfade frickeln oder was-weiß-ich.

Wenn man seine großen bestehenden Projekte weiterpflegen muss dann macht es meistens natürlich keinen Sinn alles wegzuwerfen undneu zu beginnen, nur damit man eine neue Sprachen nutzen kann.
Aber heutzutage mit Delphi etwas anzufangen, was für über die nächsten Jahre wachsen soll und kritisch für die Firma werden soll, kann ich absolut nicht nachvollziehen.
Findet man überhaupt noch Nachwuchs, der sich mit Delphi zufrieden gibt? Oder wechseln die nicht bei der nächsten Gelegenheit in einen anderen Betrieb, der ihnen modernere Tools gibt?
Es gibt nichtmal richtige Mocking Frameworks für Delphi, wie zum Geier testet man denn seinen Code ohne wahnsinnig zu werden?

[Robotiker]

Zitat von p80286:

Diese seltsamen Überhöhungen kann man sich ruhig schenken.

Das sehe ich ganz ähnlich. Irgendwie haben diese Argumente alle einen pseudoreligiösen Charakter.

Ich habe mit Turbo Pascal 3 programmieren gelernt und arbeite seit Borland C++ 2 beruflich mit C++, und seit der Beta 1 der ersten Version mit C#, kenne also alle Sprachen ein wenig.

Die meisten von diesen "Argumenten" kann ich nicht nachvollziehen.

Meine Sprachen der Wahl sind eindeutig C++ und C#, je nach Anwendungsfall. Mit Delphi beschäftige ich mich höchstens aus nostalischen Gründen oder im Zusammenhang mit, den mittlerweile seltenen, C++ Builder Anwendungen.

[Robotiker]

Wirklich tolle Argumente

Zitat von D-User:

In C zu programmieren ist prinzipiell aufwändiger, fehleranfälliger und damit teurer, da man „näher am Assembler“ programmiert.

dagegen Delphi

Zitat von D-User:

-größeres Einsatzgebiet als Java, da direkt in Assembler innerhalb des Programms programmiert werden kann, also keine prinzipiellen Restriktionen hat, und mit Zeigern operiert werden kann und keine Sandbox-Einschränkungen existieren

[Furtbichler]

Such mal nach Delphi-Entwicklern. Das reicht mir mittlerweile, um mich entgültig von Delphi zu verabschieden.

Die Mittel der Wahl wären für mich: Java oder C#.

Ich verwende C#. Einfach so. Java wäre besser (wegen der Zahl der Entwickler), aber es geht auch so.

[Robotiker]

Ende September haben ein paar unbedeutende Firmen einen Verein gegründet, um die Weiterentwicklung ihrer wichtigsten Programmiersprache zu fördern:

http://isocpp.org/about

Hint: Delphi ist es nicht ...

[Phoenix]

Ich schnapp mir auch mal einen Block.. so viel Unsinn auf einem Haufen hab ich selten gelesen...

Zitat von D-User:

Investitionssicherheit und Nachhaltigkeit:
-Wartbarkeit: Wesentlich klarerer und damit wartbarer Code als mit C/C++, siehe Vergleich unten und [1].
-Sehr grosse Anzahl freier und kommerzieller, einfach zu nutzender Komponenten.
-Stabile Plattformbasis, also nachhaltige Investition:
Ein kürzlich von Delphi1 geschriebenes größeres Projekt liess sich erstaunlich einfach und schnell auf Delphi 2010 hochziehen: Nachhaltigkeit.
-Via Free-Pascal / Lazarus existert ein Fallback auf fast allen verfügbaren Plattformen, zur Zeit wohl sogar eine größere Plattformbasis als Java.
-durch den einfach decompilierbaren Bytecode der Dot-Net-Sprachen und in Java exportiert jeder Verantwortliche, der Programm(Teile) in einer dieser Sprachen ausser Hauses gibt oder gelangen läßt, i.A. Firmengeheimnisse. Dies sollte er sich sicherheitshalber vorher schriftlich genehmigen und bestätigen lassen.
Da solche Firmengeheimnisse „kriegsentscheidend“ für eine Firma sind, kann tatsächlich das dann zufällig kurz danach auftauchende Konkurrenzprodukt aus chinesischer Produktion den Tod der Firma einleiten.
Diese Folgen waren dann vorhersehbar, der Verantwortliche sollte verantwortlich gemacht werden.
-Die in Dot-Net-Plattformen und Java erforderliche Laufzeitbibliothek verringert die Kontrolle über das Programm beim Endkunden, da in einer Laufzeitbibliothek mit Folgeversionen unerwünschte Veränderungen untergeschoben werden können. Auf Betriebsssstemebene ist von der Existenz solcher Mechanismen auszugehen, siehe Stichwort "Managed Code".
-Die in Dot-Net-Plattformen und Java erforderliche Laufzeitbibliothek ermöglicht Aussenstehenden Einfluss auf das Programm. Es kann z.B. ein Kontroll-Layer zwischen Programm und Laufzeitbibliothek geschoben werden, der das Programmverhalten analysiert bzw. verändert. Hier gibt es für den Programm-Ersteller keine wirklichen Kontrollmöglichkeiten, er wird aber i.A. verantwortlich gemacht für das Fehlverhalten, der schlimmstenfalls rechnerspezifische Nachweis der Unschuld kann teuer werden.
(Mit solch einem Layer könnten also durch die Konkurrenz Programmhersteller von Bytecode-Programmen womöglich schlimmstenfalls sogar systematisch bankrottiert werden )
-Durch den prinzipiell layerbaren zusätzlichen Zugriffslevel in Dot-Net-Plattformen und Java entsteht eine ebenso prinzipielle Sicherheitslücke, deren Tragbarkeit der Verantwortliche im Vorhinein rechtfertigen sollte!!
-Eine Plattform, im Gegensatz zu z.B. mehreren Main-Java-Plattformen wie Netbeans bzw.
Eclipse.

Ressourcen / Abstützung in der IT-Welt:
-riesige Mengen Source in Pascal, zudem die oben erwähnten Komponenten, man schaue sich das Projekt Jedi an
-auch auf andere Sourcen zugreifbar, siehe das Jedi-header conversion -Projekt [3]

1.) Das hat Elvis schon gesagt. Ich mag Pascal als Sprache auch lieber als C++, aber C# ist deutlich strukturierter und auch sehr angenehm.

2.) 'Sehr groß' in Relation zu was? Ein paar hundert Delphi-Komponenten im Vergleich zu Hunderttausenden im Bereich Java und fast genausoviel für .NET?

3.) Java und .NET als Runtime sind genauso stabile Plattformen die lediglich erweitert werden.

4.) Mit dem Wechsel zu FreePascal und andere Plattformen verliert man die Abstraktionsschicht nach unten zum System hin. Das heisst man muss sich schon bei einfachen Filezugriffen verbiegen weil die Windows-Klassen auf Linux nicht funktionieren. Bei Java und .NET übernimmt die Runtime diese Abstraktion, und man kann mit massiv weniger Aufwand eine komplette Portierung durchführen.

Deswegen werden auch die meisten Spiele die auf iOS, Android und Windows Phone laufen mit C# und Unity erstellt. Unity basiert auf Windows Phone auf echtem .NET und auf iOS und Android auf Mono. Ich würde noch nichtmal im Traum daran denken, ein Spiel für ARM-Prozessoren und unterschiedliche Mobile Betriebssysteme in irgendwas nativem zu schreiben. Das wäre glatter Selbstmord.

5.) Für sowas gibt es unmengen an sogenannten Obfuscatoren. Gut obfuskierten .NET IL-Code zu lesen macht genauso viel Spass wie Assembler zu lesen: gar keinen. Da bekommt man heutzutage aus Delphi-Programmen mit den entsprechenden Tools noch mehr Betriebskritische Infos raus.

6.) Das ist der absolut größte Quatsch den ich je gelesen habe. Dadurch, das die Runtimes isoliert und genau definiert sind, hat man eine massiv höhere Kontrolle über das System als bei nativem Code.

Beispiel: Apple hat in iOS 6 eine Betriebssystemfunktion zwischen dem Gold Master und dem tatsächlichen Release geändert. Die Programme die Nativ geschrieben waren, liefen nach einem Update nicht mehr. Unity hat mit der Mono-Runtime eine Abstraktionsschicht dazwischen, die hier beim durchgreifen auf das OS die Rückgabe noch sanitized hat und die liefen weiter. Microsoft kann mit normalen Security-Patches im Betriebssystem genauso viel kaputt machen wie Apple (würden es vermutlich aber nicht). Da .NET und Java vor allem im Enterprise-Bereich eingesetzt wird und die Gefahr besteht, ungeheuer viel Kaputt zu machen wird auch hier ein massiver Aufwand betrieben, die Runtime abwärtskompatibel zu halten.

7.) Noch mehr Quatsch. Zumindest die .NET Runtime ist - wie schon gesagt - für Enterprise-Scale Applications ausgelegt und z.B. mit Code Access Security ausgestattet. Hierdurch ist sogar auf Klassen und Methodenebene möglich exakt zu kontrollieren, welcher Code ausgeführt werden darf und welcher nicht. Bei nativen Applikationen reicht es, eine dll zu injizieren und den aktuellen Methodenpointer zu verbiegen um beliebigen Schadcode im Applikationskontext auszuführen. Mit Code Access Security bekommt man zumindest bei .NET eine viel mächtigere Sicherheitsschicht frei Haus, die solche Angriffe zuverlässig verhindern kann.

8.) Siehe 7. Viele reguläre Angriffe auf nativen Code sind in einer managed Umgebung schlicht unmöglich. CAS erhöht die Sicherheit nochmal um etliche Stufen, ich kann z.B. sogar bestimmen, was eine bestimmte Fremdkomponente alles darf und was nicht. Das ist in nativen Anwendungen unmöglich.

9.) Das ist eher ein Nachteil. Ich kann zwischen MonoDevelop und Visual Studio wählen. Wahlmöglichkeiten sind gut, denn sie erlauben mir, das beste Tool für den aktuellen Use-Case zu wählen. Wenn die Delphi-IDE irgendwo schlecht ist hat man keine Alternative und muss damit leben. Über Jahre hinweg, weil Embarcadero das in aller Regel nicht so schnell fixt.

10.) Da wären wir wieder bei 2. Die Anzahl der verfügbaren Komponenten für Delphi ist verschwindend gering gegenüber Java und .NET. Vor allem im Bereich der OpenSource Komponenten für die es zusätzlich noch kommerziellen Support gibt - auf den man dann Zugreifen kann wenn man selber was nicht hinbekommt. Bei Opensource Delphi-Komponenten muss man selber Hand anlegen. Da hat man Einarbeitungsaufwand, kann die Seiteneffekte nicht genau abschätzen, man wird inkompatibel zur Quelle und muss patches manuell nachpflegen etc.. Bei kommerziellem Support zahle ich weniger (das Team kennt das Produkt, kann changes zuverlässig machen, hat die nötigen testsuiten etc.)

Noch fragen?

[bernhard_LA]

was mit in der gesamten Diskussion fehlt, ob JAVA/C++/C# oder Delphi wir reden hier immer über Objekt Orientierte Sprachen und die einzelnen Details sind vermutlich eher Geschmackssache des Anwenders als wirklich harte WISSENSCHAFTLICH belegbare Vorteile. Eigentlich müsste man doch RAD Studio XE vs. Visual Studio vs. Eclipse vergleichen, welches Tool ermöglicht es mir am besten ein gegebenes Problem in Source code zu gießen. Welches Tools unterstützen den Anwender bei der Erstellung (Source Code Dokumentation ......) und Wartung (refactoring) seines Codes.
Oder man vergleicht DELPHI vs. FREEPASCAL und bewertet mal die Vorteile von Delphi, ist damit der Kaufpreis gerechtfertigt ???

Wenn man sich noch überlegt für welche Anwendungsfälle man Programme erstellen kann dann wird sehr klar es kann keinen universellen Sieger geben. Delphi ist ein netter Allrounder mit langer Tradition (TP) und Schnittstellen in der Moderne (iOS), wer es mag kann es nutzen es gibt aber auch viele andere Optionen.