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/