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/

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.

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

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.

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?

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

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.

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

Zitat von 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 ...

Vielen Dank für diesen Hinweis - wirklich sehenswertes Video.
Wünschte bloss, es gäbe ähnliche Entwicklungen und Diskusionen in Delphi.

Gruß
Jazzman

Zitat von Jazzman_Marburg:

Vielen Dank für diesen Hinweis - wirklich sehenswertes Video.

Die Aktivitäten da erklären sicher auch zum Teil die oben erwähnte "neue Liebe von Embarcadero zu C++".
Schliesslich war Borland mal Marktführer im PC Bereich, jetzt steht man ziemlich am Rande.

Aber es ist auch interessant, wer sich da alles zusammengetan hat, wenn man die Orgranisationen, wie HSA Foundation, auch noch in ihre Mitglieder aufdröselt, haben wir da Microsoft, Google, IBM, HP, Samsung, Intel, AMD, ARM, NVidia, Texas Instruments, usw. Alle finden sich mal eben diesen Sommer zusammen um etwas für C++ zu tun. Interessanter Zeitpunkt.

Zitat von Phoenix:

Die meisten Win8-Apps sind übrigens tatsächlich in C# geschrieben (ca. 65%), danach kommt JavaScript mit 20% und dann erst C++ mit 15%.

Von der Menge her wundert mich das nicht, ist schliesslich die am meisten unter Windows verwendete Programmiersprache. Und auch Microsoft empfiehlt es ja, siehe oben, wegen der höchsten Entwicklerproduktivität. Aber werden Apps mit komplizierter Logik, die man nicht offenlegen will, auch am meisten damit geschrieben ? Etwas wie ein PDF-Reader oder so.