Delphi-Projekt-Argumentesammlung u.Vergleich

[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

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